"DO-178B level A" запрещает оптимизацию компиляторов?
Существует сертификация уровня A и уровня B DO-178B для бортовых систем. Запрещает ли использование оптимизирующих компиляторов?
Например, некоторые компиляторы переупорядочивают инструкции, чтобы повысить производительность. DO-178B lev.A или lev.B запрещает это изменение порядка?
В большинстве современных процессоров такое переупорядочение встроено в аппаратное обеспечение. Разрешено ли их использование в софтверных / аппаратных системах DO-178B lev.A?
4 ответа
Во-первых, и важно: для ответа на этот тип вопроса, если ответ имеет значение, вам необходимо получить официальное профессиональное мнение от того, кто компетентен предоставить его, или обсудить это с вашим органом по сертификации. На любой ответ, который вы получите здесь, не следует полагаться.
С учетом вышесказанного, я предполагаю, что вы спрашиваете с любопытства и не будете полагаться на ответ каким-либо значимым образом, и я попытаюсь ответить в том же духе. Я не профессионал, и это не профессиональный совет.
Наиболее оперативной документацией, которую я смог найти в Интернете с помощью быстрого поиска, был этот руководящий документ ФАУ по соответствующей теме: http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/media/cast-12.pdf. В этой статье описываются условия, при которых необходимо выполнить проверку сгенерированного объектного кода, а не исходного кода. В частности, он дает ряд примеров, которые будут встречаться даже в неоптимизированном коде - автоматическая инициализация переменных и обработка исключений - пара примеров. Что касается оптимизации компилятора, он отмечает:
Оптимизация компилятора является еще одной областью, рассматриваемой в разделе 4.4.2a документа DO-178B/ED-12B. Это включает в себя аналитическое определение того, что функции оптимизации не ставят под угрозу способность тестовых случаев демонстрировать основанное на требованиях тестирование и структурное покрытие в соответствии с уровнем программного обеспечения. Это отдельная проблема от проблем прослеживаемости и дополнительных проверок, рассмотренных в Разделе 4.4.2b. Это выходит за рамки данной статьи.
У меня нет копии DO-178B, удобной для чтения в разделе 4.4.2a, но я хотел бы отметить, что (a) существуют процедуры для обработки других случаев, когда объектный код не соответствует исходному коду в однозначном одним способом, и (b) это довольно сильно подразумевает, что оптимизация компилятора обсуждается, а не прямо запрещена.
Из ряда обсуждений в этой статье также ясно, что ответ "мы не можем проследить вещи между исходным кодом и объектным кодом" состоит в том, чтобы каким-то образом проверять объектный код - другими словами, есть решение, кроме запрещения таких вещей.
Таким образом, я бы пришел к выводу, что по крайней мере некоторые оптимизации компилятора должны быть разрешены.
В частности, вид переупорядочения, который вы описываете, вполне прослеживается, и мне кажется почти уверенным, что это будет разрешено.
DO-178B не является абсолютным и открыт для интерпретации. Если вы отключите оптимизацию, нет вопросов и объяснять нечего. Придерживаясь наиболее очевидной интерпретации, вы избегаете необходимости впоследствии продавать свою интерпретацию сертификационным органам и открывать себя для вопросов о том, как вы поступили.
Когда вы оптимизируете свой код, трудно сделать трассируемость источника до инструкции, которая требуется для уровня A. Кроме того, если вы используете Do-178B, получение дополнительных 5% от вашего программного обеспечения не является вашей главной задачей. Простота выполнения всех необходимых шагов сертификации должна быть вашей главной задачей, поскольку это то, что будет поглощать все ваше время.
Аппаратная часть вашего вопроса интересна. Для оптимизации программного обеспечения код не просто переупорядочен, но и изменен. Но для аппаратного обеспечения код не изменяется, чтобы получить более высокую скорость только в порядке выполнения. Я должен спросить вокруг, чтобы получить больше информации о том, что думают об этом.
У меня есть только поверхностные знания о DO-178B (я не работаю с ним ежедневно, но я создаю инструменты для людей, которые делают).
Стандарт очень серьезно относится к прослеживаемости. Требования высокого уровня снижаются до требований низкого уровня, которые реализуются исходным кодом, который компилируется компилятором. На каждом из этих этапов нужно уметь обосновывать то, что было сделано с точки зрения спецификаций, созданных на предыдущем этапе.
Для компилятора это означает, что нужно иметь возможность прочитать сборку и отследить одну конкретную инструкцию до оператора исходного кода, который вызвал создание этой инструкции.
Короче говоря, да, я думаю, что это запрещает большинство оптимизаций.
Что касается аппаратного обеспечения, на котором работает это программное обеспечение, оно проверяется по-разному (но я думаю, что так же строго). Соответствующим стандартом является DO-254, и я ничего о нем не знаю.
При оптимизации вам необходимо проверить сгенерированный код на уровне языка ассемблера объектов. Существуют наборы компиляторов и библиотеки для встроенной многозадачности в реальном времени, которые были ранее проверены в других проектах, что дает вам уровень комфорта, что их можно проверять снова - но вам все равно нужно проверить код, используемый в вашем приложении.
Чтобы избежать задержек и объяснений, просто отключите оптимизацию и кеширование. Это делает код детерминированным. Также постарайтесь не использовать GCC, если это возможно, и выберите квалифицированный компилятор, такой как IAR, DDCI или Irvine Compilers или что-то в этом роде. Вместо того, чтобы пытаться ударить винт причудливым молотком, возьмите отвертку, которая работает для винта. Потому что, когда этот самолет разбивается с 200 людьми на борту, с матерями, отцами и детьми, и они обнаруживают, что компилятор переупорядочил код, и это вызвало сбой, вы захотите, чтобы у вас была только правильная отвертка.