[Промышленное программирование] Квалификация инструментов для разработки встраиваемого ПО
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, хабр! В этой статье я хочу максимально просто и доступно рассказать про то, как доказывается, что ваши средства разработки и верификации подходят для создания систем повышенной надежности. Это очень важный и далеко не самый простой вопрос, и моя цель — ответить на него как можно более понятным языком. В самой статье я обобщил указания из отраслевых стандартов, таких как КТ-178 или Р-331 (встраиваемое ПО в авиации), ГОСТ Р ИСО 26262-8 (встраиваемое ПО в автомобилестроении). Так что добро пожаловать под кат
Квалификация – зачем она?
Отраслевые стандарты, такие как КТ-178 или ИСО 26262, описывают процессы создания ПО повышенной надежности. Если следовать этим описаниям, то создание такого ПО превратится в бюрократический ад, который будет длиться вечно. Но существует программное обеспечение, которое позволяет автоматизировать значительную часть этих процессов. Такое ПО называется инструментом. И если вы применяете инструмент, то он должен быть надежным (ИСО 26262 даже вводит термин «уверенность в инструменте»). Для подтверждения надежности инструмента проводится его квалификация.
Квалификация — теория
В отраслевых стандартах есть понятие уровня безопасности. В разных стандартах они называются по-разному: Уровень ПО в КТ-178, Уровни Полноты Безопасности автомобиля в ИСО 26262. А для средств разработки применяются уровни квалификации инструментов (КТ-178) или уровни классификации инструментов (ИСО 26262). Эти уровни назначаются по критичности инструментов – чем больше влияния оказывает инструмент на разработку, тем более высокий уровень квалификации будет ему назначен. При этом одним из главных критериев по определению влияния инструмента является мера его влияния на результирующее ПО.
В качестве примера можно рассмотреть генератор исходного кода и статический анализатор кода. Сгенерированный код попадает в прошивку устройства, которое будет установлено на борт самолета или автомобиля. Таким образом, генератор кода оказывает непосредственное влияние на результирующее ПО. Так как генератор кода – сложная штука, и может генерировать код с ошибками, то к качеству этого генератора кода предъявляются строгие требования и уровень его квалификации будет максимальным. Другое дело – статический анализатор, результат работы которого не попадает в бортовое ПО и степень его влияния минимальна. Поэтому для статического анализатора уровень квалификации будет ниже, чем для генератора кода.
А еще уровень квалификации напрямую влияет на трудозатраты: так, для авиации, для квалификации инструмента по наивысшему уровню КТ-178С, требуется выполнение 76 контрольных мероприятий, а по низшему – только 14.
Еще один важный момент – квалификация инструментов проводится не разработчиком инструмента, а непосредственно разработчиком ПО, причем квалификация должна проводиться для каждого проекта!
Квалификация – заметки по практике
Как было сказано в теоретической части, квалификация инструментов – это затратный процесс, однако он упрощается несколькими способами:
- Поддержка процесса квалификации производителями инструментов (вендоров)
- Указания по квалификации инструментов из стандартов
Рассмотрим их по порядку. В первую очередь, сами вендоры поставляют пакеты поддержки квалификации инструментов. Во вторую – отраслевые стандарты содержат указания по квалификации инструментов, которые могут сократить объем работ.
Хотелось бы остановиться на втором пункте. Опять будем рассматривать генератор кода. Сгенерированный с его помощью код все равно должен тестироваться, будет собираться покрытие кода, проводится его анализ, т. е. верифицироваться.
Отраслевые стандарты говорят нам о том, что если мы будем квалифицировать инструменты, которые отвечают за верификацию кода, то квалификация самого генератора кода будет не нужна. Таким образом, сами стандарты содержат указания, следуя которым вы можете значительно сократить затраты на квалификацию.
Для квалификации инструментов верификации стандарты предписывают демонстрацию их поведения в нормальных условиях. На практике это выглядит следующим образом:
- Вендор поставляет набор шаблонов документов, нормативных документов и опорных тестов для инструмента и их эталонные результаты.
- Вы заполняете шаблоны документов и запускаете предоставленные тесты в своем окружении.
- Результаты тестов, запущенных вами, сравниваются с эталонами, и при расхождении результатов вы устраняете расхождение.
Стоит заметить, что описанный процесс тоже занимает достаточно много времени и, как и вся разработка, выполняется при взаимодействии с сертифицирующими органами.
Инструменты MathWorks и их квалификация
Такие инструменты как Simulink, DSP Toolbox, Control System Toolbox – это стандарт индустрии для разработки систем управления, цифровой обработки сигналов. Неудивительно, что их применяют в авиации, автомобилестроении и прочих отраслях. Из разработанных моделей генерируется C/C++ код, который ездит и летает. Естественно, что перед разработчиками встает вопрос квалификации инструментов. И квалификация инструментов MathWorks для КТ-178С осуществляется для инструментов верификации моделей и кода:
- Simulink Check
- Simulink Coverage
- Simulink Requirements
- Simulink Design Verifier
- Simulink Test
- Simulink Report Generator
- Polyspace Bug Finder
- Polyspace Code Prover
- Simulink Code Inspector
А для ISO 26262 поставляются сертификаты для:
- Simulink Check
- Simulink Coverage
- Simulink Requirements
- Simulink Design Verifier
- Simulink Test
- Simulink Report Generator
- Polyspace Bug Finder
- Polyspace Code Prover
- Embedded Coder
- HDL Coder
- PLC Coder
В зависимости от отрасли предоставляются пакеты поддержки квалификации инструментов DO Qualification Kit для авиации или IEC Certification Kit для автомобильной, железнодорожной и других отраслей.
Вместо выводов
В данной статье был дан обобщенный обзор процесса квалификации инструментов в соответствии с отраслевыми стандартами. В ходе написания данной статьи, я руководствовался следующими источниками:
- Р-330, «Руководство по квалификации программных инструментов», в частности:
- п. 2.0 Назначение квалификации инструмента
- п. 3.1. Уровни квалификации
- Справочные материалы D, вопрос D7
- ГОСТ Р ИСО 26262-8, Глава 11, «Уверенность в использовании инструментального программного обеспечения»
Если вам интересно как создаются системы повышенной надежности, то напишите в комментариях, что требуется рассмотреть в следующих статьях.
===========
Источник:
habr.com
===========
Похожие новости:
- [Тестирование IT-систем, Программирование, Java, IT-стандарты, Промышленное программирование] Принцип слоеного теста
- [Программирование, IT-инфраструктура, Виртуализация, Промышленное программирование, Управление разработкой] Цифровая индустрия: непрерывная оптимизация процессов
- [Управление проектами] Сдал экзамен PMP — как это было
- [Разработка робототехники, Мультикоптеры, DIY или Сделай сам, Транспорт, Будущее здесь] «Летающая табуретка» или идеальный квадрокоптер для перевозки пиццы
- [Робототехника, История IT, Научно-популярное, Транспорт] Сто лет истории беспилотных автомобилей (перевод)
- [Информационная безопасность, Антивирусная защита, Автомобильные гаджеты] Как взламывают подключенные автомобили и что с этим делать
- [Промышленное программирование, SCADA] WinCC OA Workshop. Часть 7. Навигация: Создание интерфейса АРМ
- [Тестирование IT-систем, Анализ и проектирование систем, Прототипирование, Научно-популярное] Путеводитель по созданию стендов полунатурного моделирования (HIL) оборудования самолётов
- [Транспорт] Uber продала подразделение робомобилей за $4 миллиарда стартапу Aurora
- [Управление проектами] Подготовка к PMP по шагам
Теги для поиска: #_promyshlennoe_programmirovanie (Промышленное программирование), #_iso_26262, #_do178, #_sertifikatsija (сертификация), #_vstraivaemye_sistemy (встраиваемые системы), #_aviatsija (авиация), #_avtomobili (автомобили), #_blog_kompanii_tsitm_eksponenta (
Блог компании ЦИТМ Экспонента
), #_promyshlennoe_programmirovanie (
Промышленное программирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 09:53
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Привет, хабр! В этой статье я хочу максимально просто и доступно рассказать про то, как доказывается, что ваши средства разработки и верификации подходят для создания систем повышенной надежности. Это очень важный и далеко не самый простой вопрос, и моя цель — ответить на него как можно более понятным языком. В самой статье я обобщил указания из отраслевых стандартов, таких как КТ-178 или Р-331 (встраиваемое ПО в авиации), ГОСТ Р ИСО 26262-8 (встраиваемое ПО в автомобилестроении). Так что добро пожаловать под кат Квалификация – зачем она? Отраслевые стандарты, такие как КТ-178 или ИСО 26262, описывают процессы создания ПО повышенной надежности. Если следовать этим описаниям, то создание такого ПО превратится в бюрократический ад, который будет длиться вечно. Но существует программное обеспечение, которое позволяет автоматизировать значительную часть этих процессов. Такое ПО называется инструментом. И если вы применяете инструмент, то он должен быть надежным (ИСО 26262 даже вводит термин «уверенность в инструменте»). Для подтверждения надежности инструмента проводится его квалификация. Квалификация — теория В отраслевых стандартах есть понятие уровня безопасности. В разных стандартах они называются по-разному: Уровень ПО в КТ-178, Уровни Полноты Безопасности автомобиля в ИСО 26262. А для средств разработки применяются уровни квалификации инструментов (КТ-178) или уровни классификации инструментов (ИСО 26262). Эти уровни назначаются по критичности инструментов – чем больше влияния оказывает инструмент на разработку, тем более высокий уровень квалификации будет ему назначен. При этом одним из главных критериев по определению влияния инструмента является мера его влияния на результирующее ПО. В качестве примера можно рассмотреть генератор исходного кода и статический анализатор кода. Сгенерированный код попадает в прошивку устройства, которое будет установлено на борт самолета или автомобиля. Таким образом, генератор кода оказывает непосредственное влияние на результирующее ПО. Так как генератор кода – сложная штука, и может генерировать код с ошибками, то к качеству этого генератора кода предъявляются строгие требования и уровень его квалификации будет максимальным. Другое дело – статический анализатор, результат работы которого не попадает в бортовое ПО и степень его влияния минимальна. Поэтому для статического анализатора уровень квалификации будет ниже, чем для генератора кода. А еще уровень квалификации напрямую влияет на трудозатраты: так, для авиации, для квалификации инструмента по наивысшему уровню КТ-178С, требуется выполнение 76 контрольных мероприятий, а по низшему – только 14. Еще один важный момент – квалификация инструментов проводится не разработчиком инструмента, а непосредственно разработчиком ПО, причем квалификация должна проводиться для каждого проекта! Квалификация – заметки по практике Как было сказано в теоретической части, квалификация инструментов – это затратный процесс, однако он упрощается несколькими способами:
Рассмотрим их по порядку. В первую очередь, сами вендоры поставляют пакеты поддержки квалификации инструментов. Во вторую – отраслевые стандарты содержат указания по квалификации инструментов, которые могут сократить объем работ. Хотелось бы остановиться на втором пункте. Опять будем рассматривать генератор кода. Сгенерированный с его помощью код все равно должен тестироваться, будет собираться покрытие кода, проводится его анализ, т. е. верифицироваться. Отраслевые стандарты говорят нам о том, что если мы будем квалифицировать инструменты, которые отвечают за верификацию кода, то квалификация самого генератора кода будет не нужна. Таким образом, сами стандарты содержат указания, следуя которым вы можете значительно сократить затраты на квалификацию. Для квалификации инструментов верификации стандарты предписывают демонстрацию их поведения в нормальных условиях. На практике это выглядит следующим образом:
Стоит заметить, что описанный процесс тоже занимает достаточно много времени и, как и вся разработка, выполняется при взаимодействии с сертифицирующими органами. Инструменты MathWorks и их квалификация Такие инструменты как Simulink, DSP Toolbox, Control System Toolbox – это стандарт индустрии для разработки систем управления, цифровой обработки сигналов. Неудивительно, что их применяют в авиации, автомобилестроении и прочих отраслях. Из разработанных моделей генерируется C/C++ код, который ездит и летает. Естественно, что перед разработчиками встает вопрос квалификации инструментов. И квалификация инструментов MathWorks для КТ-178С осуществляется для инструментов верификации моделей и кода:
А для ISO 26262 поставляются сертификаты для:
В зависимости от отрасли предоставляются пакеты поддержки квалификации инструментов DO Qualification Kit для авиации или IEC Certification Kit для автомобильной, железнодорожной и других отраслей. Вместо выводов В данной статье был дан обобщенный обзор процесса квалификации инструментов в соответствии с отраслевыми стандартами. В ходе написания данной статьи, я руководствовался следующими источниками:
Если вам интересно как создаются системы повышенной надежности, то напишите в комментариях, что требуется рассмотреть в следующих статьях. =========== Источник: habr.com =========== Похожие новости:
Блог компании ЦИТМ Экспонента ), #_promyshlennoe_programmirovanie ( Промышленное программирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 09:53
Часовой пояс: UTC + 5