Перейти к содержанию
    

разработка по DO-254/КТ-254

Существует такой стандарт DO-254 (и его перевод с комментариями КТ-254), применяется при разработке авионики. Некоторые САПР это поддерживают, некоторые даже софт толкают для разработки под ПЛИС по этому стандарту. Читаю я это чудо, но вызывает отторжение нечеткость формулировок, отсутствие конкретики. Просто много красивых правильных слов. Мне такое не понятно.

 

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

 

P.S. Очень трудно было определить в какой раздел поместить тему...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это хитрый стандарт. Он не говорит что если вы по нему сделаете то это будет хорошо летать.

Он говорит что если вы по нему сделаете, то это будет максимально что вы могли сделать на текущий момент.

При этом если оно дрепнется и будет системная ошибка, они обещают добавить контроль за ней в стандарт...

 

Потом там много политеса, вас в итоге должны аттестовать, то есть это игра ради проверяющего.

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Имеется в виду, два устройства сделанных по одному ТЗ, но разными людьми и на разной элементной базе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Это не ошибка реализации, это ошибка требований или модели, а это уже не ДО-254 для конкретной железки.

 

Пока я вижу что этот стандарт по большей части бесполезен в качестве каких-то рекомендаций для более надежной продукции.

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

 

Когда работаете по ДО254 это означаете что вы прям реально запариваетесь и кто-то это проверяет, но никак не гарантирует что то что получилось будет супер надежным.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Когда работаете по ДО254 это означаете что вы прям реально запариваетесь и кто-то это проверяет, но никак не гарантирует что то что получилось будет супер надежным

Это понятно. Еще вопрос: говорят там надо иметь сертифицированные инструменты для верификации модулей. Вот допустим, если я имею лицензионный Modelsim, который имеет бумазейки подтверждающие этот инструмент для DO-254, но использую сторонний фрейморк (который через PLI общается с симулятором), то допустимо ли это? Не для аппаратуры класса А, но допустим класса B или C?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это понятно. Еще вопрос: говорят там надо иметь сертифицированные инструменты для верификации модулей. Вот допустим, если я имею лицензионный Modelsim, который имеет бумазейки подтверждающие этот инструмент для DO-254

Modelsim как утилита не может быть сертифицирован. Поддержка DO-254 c его стороны выражается в том, что верификация сделанная с помощью его инструментов формально сертифицируема.

Изменено пользователем lembrix

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Где гарантия, что разработка будет вестись разумным разработчиком или он что-то не упустит?

В общем, стандарт не предписывает тестировать тщательнее. Он предписывает каждое требование подтвердить тестами.

Весь процесс разработки должен быть разбит на этапы, каждый из которых подтверждается надзорными органами.

 

Это понятно. Еще вопрос: говорят там надо иметь сертифицированные инструменты для верификации модулей. Вот допустим, если я имею лицензионный Modelsim, который имеет бумазейки подтверждающие этот инструмент для DO-254, но использую сторонний фрейморк (который через PLI общается с симулятором), то допустимо ли это? Не для аппаратуры класса А, но допустим класса B или C?

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

Сторонний фреймворк, насколько помню, тоже должен быть квалифицирован. То есть подтверждена его безопасность.

Вот насчет классов аппаратуры идет отсылка к DO-178. Точно не скажу.

 

Когда-то делал документ DO254 для разработчика ПЛИС. Перевод из нескольких источников.

Он немного недоделан. Не хватает списка сокращений, глоссария и, наверное, чего-то еще.

Но возможно кому-то поможет дать общее представление.

DO_254_for_FPGA_Designer__ru_.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Modelsim как утилита не может быть сертифицирован. Поддержка DO-254 c его стороны выражается в том, что верификация сделанная с помощью его инструментов формально сертифицируема

Допустим сертифицируема. Если я буду использовать нечто поверх Modelsim (например cocotb/Python через механизм PLI), прокатит ли такой инструмент для сертификации железа класса B/C? Тут нет ограничений? Просто меня убеждали в обратном, теперь я несколько сомневаюсь в этом.

 

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

Сторонний фреймворк, насколько помню, тоже должен быть квалифицирован. То есть подтверждена его безопасность.

Спасибо, вот этот вопрос меня теребил. Стало бы и для класса B/C/D тоже должен быть подтвержден?

С одной стороны верно и правильно, с другой - немного печально.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Стало бы и для класса B/C/D тоже должен быть подтвержден?

Я уже все позабывал. Больше 5 лет прошло. Мог и напутать что-то.

И самое главное, в реальности я этот процесс никогда не проходил.

Тут важно мнение тех, кто реально на деле проходил этот путь и

знаком с российской спецификой.

 

Единственное, что я точно помню из общения с ЦЭСАТом, это то, что проектирование

по DO-178/DO-254 нужно начинать после контактов с ними, а не наоборот. Это с их слов.

Люди что-то делают, а потом пытаются выйти на сертификацию, а многое надо переделывать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Смотрите допустим у вас есть тестовые примеры, набор запросов и ответов.

Вы можете положить ответы в файл, и положить в другой файл ответы ваше системы. После этого запустить скрипт который сравнит эти файлы. В этом случае скрипт и среда должны быть квалифицированы.

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

И дальше 2 вопроса:

1. кто подпишется что он сравнивал файлы

2. поверять ли ему те кто вас проверяет что он так сделал.

 

В целом все это ДО это решение задачи по убеждению того кто ставит подпись что проверка проведена и она нормальная.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо, вот этот вопрос меня теребил. Стало бы и для класса B/C/D тоже должен быть подтвержден?

С одной стороны верно и правильно, с другой - немного печально.

Вычитал такое, если инструмент предназначен для верификации С и ниже, то его квалификация в полном объеме не требуется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В целом все это ДО это решение задачи по убеждению того кто ставит подпись что проверка проведена и она нормальная.

Согласно стандарту, должны быть установлены четкие критерии прохождения тестов.

Если такой подход и проканает, то вопреки DO.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Согласно стандарту, должны быть установлены четкие критерии прохождения тестов.

Если такой подход и проканает, то вопреки DO.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Субъективная составляющая может быть такая. Допустим сотрудник сертификационного органа человек ответственный. Посчитает он нормальной проверку глазами миллионов цифр?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...