1891ВМ12Я 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Существует такой стандарт DO-254 (и его перевод с комментариями КТ-254), применяется при разработке авионики. Некоторые САПР это поддерживают, некоторые даже софт толкают для разработки под ПЛИС по этому стандарту. Читаю я это чудо, но вызывает отторжение нечеткость формулировок, отсутствие конкретики. Просто много красивых правильных слов. Мне такое не понятно. Есть ли у кого опыт работы по этому стандарту (процессам)? Есть ли статьи на эту тему, пусть даже англоязычные, где был бы разобран пример разработки какого-либо простого блока, с демонстрацией процесса, верификации, документирование и т.д.? P.S. Очень трудно было определить в какой раздел поместить тему... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Это хитрый стандарт. Он не говорит что если вы по нему сделаете то это будет хорошо летать. Он говорит что если вы по нему сделаете, то это будет максимально что вы могли сделать на текущий момент. При этом если оно дрепнется и будет системная ошибка, они обещают добавить контроль за ней в стандарт... Потом там много политеса, вас в итоге должны аттестовать, то есть это игра ради проверяющего. к примеру вот есть устройство класса А. А теперь берем 2 таких устройства делаем в разных местах, и ставим работать в параллель, теперь можно им дать класс В, а то и С, потому что ошибка в одном не вызовет катастрофы, а одинаковая ошибка практически невероятное событие. И второй вариант аттестуют гораздо легче. так что в итоге надо плотно работать с теми кто вам печатьку будет ставить, какие практики им нравятся, как они привыкли видеть результаты и отчеты. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
1891ВМ12Я 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба к примеру вот есть устройство класса А. А теперь берем 2 таких устройства делаем в разных местах, и ставим работать в параллель, теперь можно им дать класс В, а то и С, потому что ошибка в одном не вызовет катастрофы, а одинаковая ошибка практически невероятное событие. И второй вариант аттестуют гораздо легче Два одинаковых устройства на одинаковое воздействие могут одинаково ошибочно сработать, дублирование тут не спасает, хотя может с точки зрения кого-то это будет выглядеть надежнее. Пока я вижу что этот стандарт по большей части бесполезен в качестве каких-то рекомендаций для более надежной продукции. Скорее "делай coverage, тестируй тщательнее, предусмотри последствия отказа" и тому подобные банальности, которые и без них очевидны для разумного разработчика. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lembrix 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Два одинаковых устройства на одинаковое воздействие могут одинаково ошибочно сработать, дублирование тут не спасает, хотя может с точки зрения кого-то это будет выглядеть надежнее. Имеется в виду, два устройства сделанных по одному ТЗ, но разными людьми и на разной элементной базе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Два одинаковых устройства на одинаковое воздействие могут одинаково ошибочно сработать, дублирование тут не спасает, хотя может с точки зрения кого-то это будет выглядеть надежнее. Это не ошибка реализации, это ошибка требований или модели, а это уже не ДО-254 для конкретной железки. Пока я вижу что этот стандарт по большей части бесполезен в качестве каких-то рекомендаций для более надежной продукции. В целом да. Он не имеет рецептов как сделать хорошо. К примеру там написано что должны быть правила кодирования, но какие они должны быть не сказано. То есть можно написать что мы все имена начинаем с большой буквы и это единственное правило и все вы в стандарте по данному пункту. Когда работаете по ДО254 это означаете что вы прям реально запариваетесь и кто-то это проверяет, но никак не гарантирует что то что получилось будет супер надежным. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
1891ВМ12Я 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Когда работаете по ДО254 это означаете что вы прям реально запариваетесь и кто-то это проверяет, но никак не гарантирует что то что получилось будет супер надежным Это понятно. Еще вопрос: говорят там надо иметь сертифицированные инструменты для верификации модулей. Вот допустим, если я имею лицензионный Modelsim, который имеет бумазейки подтверждающие этот инструмент для DO-254, но использую сторонний фрейморк (который через PLI общается с симулятором), то допустимо ли это? Не для аппаратуры класса А, но допустим класса B или C? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lembrix 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 (изменено) · Жалоба Это понятно. Еще вопрос: говорят там надо иметь сертифицированные инструменты для верификации модулей. Вот допустим, если я имею лицензионный Modelsim, который имеет бумазейки подтверждающие этот инструмент для DO-254 Modelsim как утилита не может быть сертифицирован. Поддержка DO-254 c его стороны выражается в том, что верификация сделанная с помощью его инструментов формально сертифицируема. Изменено 19 апреля, 2017 пользователем lembrix Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Пока я вижу что этот стандарт по большей части бесполезен в качестве каких-то рекомендаций для более надежной продукции. Скорее "делай coverage, тестируй тщательнее, предусмотри последствия отказа" и тому подобные банальности, которые и без них очевидны для разумного разработчика. Где гарантия, что разработка будет вестись разумным разработчиком или он что-то не упустит? В общем, стандарт не предписывает тестировать тщательнее. Он предписывает каждое требование подтвердить тестами. Весь процесс разработки должен быть разбит на этапы, каждый из которых подтверждается надзорными органами. Это понятно. Еще вопрос: говорят там надо иметь сертифицированные инструменты для верификации модулей. Вот допустим, если я имею лицензионный Modelsim, который имеет бумазейки подтверждающие этот инструмент для DO-254, но использую сторонний фрейморк (который через PLI общается с симулятором), то допустимо ли это? Не для аппаратуры класса А, но допустим класса B или C? Не только для верификации, но и для компиляции основного кода необходимо использовать квалифицированные инструменты. Сторонний фреймворк, насколько помню, тоже должен быть квалифицирован. То есть подтверждена его безопасность. Вот насчет классов аппаратуры идет отсылка к DO-178. Точно не скажу. Когда-то делал документ DO254 для разработчика ПЛИС. Перевод из нескольких источников. Он немного недоделан. Не хватает списка сокращений, глоссария и, наверное, чего-то еще. Но возможно кому-то поможет дать общее представление. DO_254_for_FPGA_Designer__ru_.pdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
1891ВМ12Я 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Modelsim как утилита не может быть сертифицирован. Поддержка DO-254 c его стороны выражается в том, что верификация сделанная с помощью его инструментов формально сертифицируема Допустим сертифицируема. Если я буду использовать нечто поверх Modelsim (например cocotb/Python через механизм PLI), прокатит ли такой инструмент для сертификации железа класса B/C? Тут нет ограничений? Просто меня убеждали в обратном, теперь я несколько сомневаюсь в этом. Не только для верификации, но и для компиляции основного кода необходимо использовать квалифицированные инструменты. Сторонний фреймворк, насколько помню, тоже должен быть квалифицирован. То есть подтверждена его безопасность. Спасибо, вот этот вопрос меня теребил. Стало бы и для класса B/C/D тоже должен быть подтвержден? С одной стороны верно и правильно, с другой - немного печально. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Стало бы и для класса B/C/D тоже должен быть подтвержден? Я уже все позабывал. Больше 5 лет прошло. Мог и напутать что-то. И самое главное, в реальности я этот процесс никогда не проходил. Тут важно мнение тех, кто реально на деле проходил этот путь и знаком с российской спецификой. Единственное, что я точно помню из общения с ЦЭСАТом, это то, что проектирование по DO-178/DO-254 нужно начинать после контактов с ними, а не наоборот. Это с их слов. Люди что-то делают, а потом пытаются выйти на сертификацию, а многое надо переделывать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Смотрите допустим у вас есть тестовые примеры, набор запросов и ответов. Вы можете положить ответы в файл, и положить в другой файл ответы ваше системы. После этого запустить скрипт который сравнит эти файлы. В этом случае скрипт и среда должны быть квалифицированы. С другой стороны вы можете сказать что вы проглядели оба файла глазами и сравнили каждое значение, в этом случае вам ничего квалифицировать не нужно. И дальше 2 вопроса: 1. кто подпишется что он сравнивал файлы 2. поверять ли ему те кто вас проверяет что он так сделал. В целом все это ДО это решение задачи по убеждению того кто ставит подпись что проверка проведена и она нормальная. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lembrix 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Спасибо, вот этот вопрос меня теребил. Стало бы и для класса B/C/D тоже должен быть подтвержден? С одной стороны верно и правильно, с другой - немного печально. Вычитал такое, если инструмент предназначен для верификации С и ниже, то его квалификация в полном объеме не требуется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба В целом все это ДО это решение задачи по убеждению того кто ставит подпись что проверка проведена и она нормальная. Согласно стандарту, должны быть установлены четкие критерии прохождения тестов. Если такой подход и проканает, то вопреки DO. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Согласно стандарту, должны быть установлены четкие критерии прохождения тестов. Если такой подход и проканает, то вопреки DO. должны быть установлены, но сами критерии не обозначены. И вот тут всегда есть субъективная составляющая. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lembrix 0 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Субъективная составляющая может быть такая. Допустим сотрудник сертификационного органа человек ответственный. Посчитает он нормальной проверку глазами миллионов цифр? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться