Стандарт Misra для встраиваемого ПО

Я использую PC Lint для статического анализа кода C и C++. Его можно настроить для отображения того, какие правила MISRA были нарушены, и он имеет интерфейс командной строки.

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

Я бы поддержал рекомендацию Грега для PC Lint, но стоит также взглянуть на Splint с открытым исходным кодом, хотя между ними (и системой предупреждений компилятора), я полагаю, вы все равно сможете охватить только 80% правил Misra. - остальное, вероятно, потребуется проверить вручную.

Я также очень рекомендую PC-Lint. Если вы собираете свой код с помощью Visual Studio, я рекомендую подключаемый модуль Visual Lint от Riverblade. Если вы не можете скомпилировать код в Visual Studio, вы все равно можете запустить PC-Lint из командной строки, чтобы добиться хороших результатов.

Некоторые компиляторы встроенных систем предоставляют тестирование на соответствие MISRA в виде предупреждений компилятора. Я использую компилятор IAR для разработки Arm7 / Arm9. Он предоставляет простой в настройке контрольный список соответствия MISRA прямо в настройке компилятора.

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

Приблизительная оценка:
2-3 дня, чтобы научиться пользоваться PC-Lint. Первоначальный этап приведения существующего кода в соответствие с MISRA: от 10 до 25 процентов времени, затрачиваемого на написание кода в первую очередь. Обеспечение соответствия кода MISRA: от 5 до 10 процентов добавлено к разработке кода. Половина этих затрат - это изменение привычек ваших программистов, чтобы они следовали «методу MISRA». Другая половина - это дополнительные расходы на тестирование и проверку кода для обеспечения соответствия MISRA.

Я использовал коммерческий инструмент под названием QAC. Инструмент может применять MISRA

Он имеет интерфейс командной строки, поэтому вы можете настроить его для запуска из среды автоматической сборки. Применяемые правила можно настраивать, но ожидайте, что кто-то потратит некоторое время на их настройку. U. Применение MISRA довольно простое и работает достаточно хорошо. Мне сказали (и это всего лишь третья сторона), что это один из инструментов, который некоторые агентства (например, FDA) используют для оценки кода. Как и в большинстве инструментов статического анализа, необходимо иметь дело с шумом (ложными срабатываниями). В последний раз, когда я использовал его, у него не было хороших средств для того, чтобы пометить / остановить ложное срабатывание от повторения (без изменения кода, на который он жаловался).

Я подозреваю, что младшему инженеру потребуется до недели (4-5 дней), чтобы настроить его (при условии, что он настроен заставить его работать так, как вы хотите).

Кстати, другие коммерческие инструменты статического анализа, вероятно, также имеют принудительное применение MISRA. Как сообщается (согласно их торговому представителю), Klocwork делает.

У нас была аналогичная проблема с модификацией правил Misra. У нас были некоторые проблемы с качеством кода в большом проекте, и мы решили использовать MISRA для улучшения качества кода.

Мы используем компилятор Green Hills, который поддерживает правила MISRA C. Также доступны автономные шашки. В зависимости от того, что вы хотите сделать, это может немного перебить переключение на все правила. Мы включали по одному правилу за раз, чтобы дать людям время исправить ограниченное количество похожих проблем, иначе вы будете полностью ошеломлены количеством ошибок.

Поскольку наши предупреждения были созданы компилятором, а не отдельным инструментом, вы видите ошибки по мере разработки, а не только при запуске программы проверки. По мере того, как мы продолжали разработку, мы добились того, чтобы наш код был совместим, и не сразу. Это также предотвратит испорченность нового кода старыми привычками, из-за чего вам придется снова переделывать код позже.

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

Я понимаю, что это старый вопрос, но для пользы любых других археологов (или исследователей) важно помнить, что MISRA предоставляет руководящие указания, которому не всегда следует слепо следовать.

Я рекомендую писать новый код с учетом MISRA; следовательно, будет намного легче соблюдать требования.

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

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