DRAKON.SU

Текущее время: Среда, 20 Июнь, 2018 23:39

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 22 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Среда, 04 Март, 2015 11:19 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3702
Откуда: Москва
https://metadeus.wordpress.com/2012/09/ ... %BF%D0%B0/

Цитата:
Как у нас пишут ПО для космических аппаратов

Posted on Сентябрь 18, 2012

Хотелось бы рассказать вам немного о разработке ПО для космических аппаратов «у нас», в отличие о того, что мы наблюдаем «у них«.

Для начала немного о себе: я работал в этой отрасли несколько лет и занимался непосредственно созданием бортового ПО и наземного обслуживающего ПО. В круг мои задач входили системы из контура управления и контроля аппарата, системной частью я не занимался, но взаимодействовать приходилось с ней достаточно плотно, т.к. реализуемые задачи были наиболее ответственными и ресурсоёмкими.

В общем, мой код уже летает в составе 2 модулей МКС, ещё один готовится улететь, а так же в составе нескольких спутников. Я не являюсь профессиональным инженером космических систем, но являюсь профессиональным программистом, поэтому и оценивать могу только часть касающуюся разработки ПО.

Все мои наблюдения оформлю в виде небольших тезисов.

Большая часть ПО написана не профессиональными программистами.
В основном функциональные системы написаны либо людьми имеющими инженерное образование связанное с летательными и космическими аппаратами, либо физиками и математиками, которым в силу необходимости пришлось научиться перекладывать свои знания на абстракции низкоуровневых языков программирования (типа C).

Соответственно и на результаты такого написания кода без слёз взглянуть сложно.
При написании бортовой части ПО используются технологии 20-30 летней давности.

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

Для управления версионностью ПО не используются соответствующие программные продукты (Subversion, Git и т.п.).

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

«Незаменимые» люди существуют.
Существуют люди без которых разработка встает на месте. Чаще всего это связано с тем, что такой «незаменимый» держит в голове некие тайные знания на протяжении десятков лет и активно сопротивляется их формализации и оформлению в виде документации.

Это может доходить до такого состояния, что с уходом «незаменимого» человека пропадают исходные тексты программ и целые пласты знаний, из-за чего приходится переписывать объемные системы с нуля.

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

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

Бесконечные как по времени, так и по количеству совещания.
Любое, даже самое мелкое действие для своей реализации может потребовать сбора совещания из 10-20 человек на срок 1,5-2 часа. Таких совещаний проводится 1-2 в день.

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

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

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

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

Единственное, что спасает (далеко не всегда) ПО от багов это длительная многостадийная отработка.

Зачастую при поступлении ПО на заключительную стадию тестирования в первые же несколько дней находят сотни ошибок.

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

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

Даже простейшие системы контроля параметров попадающих на борт внедрялись с большим трудом под предлогами «оптимизации» или недопустимости изменения интерфейса существующих функций используемых десятком разработчиков.

Преждевременные псевдооптимизации при явной пессимизации.

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

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

Вместе с тем при компилировании релизной бортовой версии могут быть сознательно выключены все оптимизации компилятора и линковщика для обеспечения какой-нибудь редкоиспользуемой низкоуровневой функции (например: реализации бинарных патчей). Что в конечном счете приводит к тому, что бортовой код становится медленным как черепаха и выходит за такт жесткого реалтайма, и в свою очередь вызывает новую волну дебильных микрооптимизаций по включению тела функций в места их вызова и замены нормальных вычислений сдвигами и т.п.

Системная текучка кадров. Текучка кадров встроена в систему — такого слоя специалистов как грамотные опытные разработчики не пред пенсионного возраста практически нет. Есть два лагеря: профессионалы старой школы сопротивляющиеся всему новому и держащиеся за свои рабочие места (про них говорят: «Эти люди не читают книг — они их пишут»), и бывшие студенты ещё ничему не научившиеся и зачастую просто «отсиживающиеся» от призыва в армию.

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


Ниже статьи приведены комментарии и ответы автора.

В комментариях участвуют, в частности, Илья Ермаков и TAU (Андрей Александрович Тюгашев)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 08 Март, 2015 14:52 
Аватара пользователя

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 46
Откуда: Tel-Aviv
Печально всё это.

Как-то писали, что бортовое ПО написано на Модула-2. Получается, на Модуле-2 давно не пишут, а на языке Си?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Март, 2015 12:16 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 11
Откуда: Нижний Новгород
Роман М. писал(а):
Печально всё это.

Как-то писали, что бортовое ПО написано на Модула-2. Получается, на Модуле-2 давно не пишут, а на языке Си?

Проблема не в языке. Если заменить Си на Модулу-2, то ничего не изменится.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Март, 2015 19:36 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 336
Роман М. писал(а):
Печально всё это.
Как-то писали, что бортовое ПО написано на Модула-2. Получается, на Модуле-2 давно не пишут, а на языке Си?

Откуда получается?

Не читайте перед обедом советских газет (С), а тем более - малограмотных публикаций в Интернете. Автор делает необоснованные обобщения и далеко идущие выводы на основе субъективных впечатлений.

В АО "ИСС" давно и успешно, и в настоящее время, пишут бортовое ПО на Модуле-2. Впрочем, не только на ней. И ничего "печального" сказать об их технологии не могу, равно как и о технологии МОКБ "Марс". Скорее, они "впереди планеты всей". В НПЦ АП внедрены специальные проблемно-ориентированные языки, используется успешно визуальный ДРАКОН, обеспечивающий "программирование без программистов".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 14 Октябрь, 2015 13:56 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 733
http://www.mars-mokb.ru/contacts.php
Цитата:
Новости 06.10.2015

12–14 октября 2015 г. МОКБ "Марс" проводит III Всероссийскую научно-техническую конференцию "Системы управления беспилотными космическими и атмосферными летательными аппаратами".


http://www.mars-mokb.ru/programma2015.pdf
Цитата:
III Всероссийской научно-технической конференции,
посвященной 60-летию МОКБ «Марс»
«Системы управления беспилотными космическими и
атмосферными летательными аппаратами»
Москва, 12–14 октября 2015 г.

Доклад
Цитата:
8. Петухов В.Н.
Разработка надежного ПО для критических систем.
SimInTech – среда визуальной разработки ПО систем управления

http://simintech.ru/?p=28
Сайт среды SimInTech.

http://rosatom-cipk.ru/wp-content/uploads/2013/12/13_31.pdf
Цитата:
Проектирование алгоритмов управления АЭС

Возможности среды SimInTech для проектирования алгоритмов
АЭС и создания систем АСУ ТП

Авторы: Козлов О.С., Тимофеев К.А., Петухов В.Н., Паршиков И.А.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Октябрь, 2015 07:59 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 733
Продолжение.

http://simintech.ru/?page_id=15
SimInTech
ГЕНЕРАЦИЯ КОДА обеспечивает:
Цитата:
• автоматическое создание кода на языке Си для одной или в массовом режиме для
нескольких целевых систем, по набранным в SimInTech схемам алгоритмов;
• сборку расчетного модуля, загрузку его на целевую систему, отладку выполнения модуля
(алгоритма) на внешней целевой системе;
• автоматизированную организацию межприборного обмена, в случае программирования
нескольких приборов одновременно.

Изображение


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Октябрь, 2015 08:23 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3702
Откуда: Москва
Гост Р МЭК 60880-2010, сертифицированный для систем контроля и управления, важных для безопасности АЭС, отстал от жизни.

Нельзя писать алгоритмы на языке Си. Такой алгоритм скрывает ошибки, делает их незаметными.

Авторы Госта должны знать, что алгоритмы для ответственных (критических) систем следует писать на языке ДРАКОН.

=======================

Вопрос к Дмитрию Дагаеву. Почему атомщики пишут алгоритмы на языке Си?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Октябрь, 2015 17:04 
Аватара пользователя

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 46
Откуда: Tel-Aviv
Владимир Паронджанов писал(а):
Нельзя писать алгоритмы на языке Си. Такой алгоритм скрывает ошибки, делает их незаметными.
Я так понял, что с помощью SimInTech происходит автоматическая генерация целевого кода на язык Си. Программисты на Си не ишут. SimInTech создаёт код, который затем компилируется Си компиляторами на целевую архитектуру. SimInTech лишь звено в Toolchain.
Интересно знать, а какими Си компиляторами там пользуются?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Октябрь, 2015 00:57 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 336
Я был на этой конференции и слушал в том числе этот доклад. И сам выступал.
Не могу сказать, что он на меня произвел самое глубокое впечатление... Были и более непосредственно относящиеся к проблемам космической отрасли доклады.

Хотя ребята заявляют громогласно, что на некоторые АЭС перестали выезжать программисты для правки ПО, что ранее происходило постоянно.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Сентябрь, 2017 08:36 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 733
https://cyberleninka.ru/article/n/podhod-k-obespecheniyu-otkazoustoychivosti-kosmicheskih-apparatov-na-osnove-avtomatizatsii-proektirovaniya-intellektualnyh-bortovyh-1
Цитата:
Подход к обеспечению отказоустойчивости космических аппаратов на основе автоматизации проектирования интеллектуальных бортовых программных средств / А. А. Тюгашев // Надежность и качество сложных систем. - 2016. - № 4 (16). - С. 106-112. БО! 10.21685/2307-4205-2016-4-15.


Изображение


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Сентябрь, 2017 09:36 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3702
Откуда: Москва
Дискуссия с профессором А.А. Тюгашевым

профессор А.А. Тюгашев писал(а):
Исходно нотация основана на классических блок-схемах алгоритмов и программ, однако во многом учтены идеи В. Д. Паронджанова [12], обеспечивающие наглядность, ясность быстроту и целостность восприятия схем. В частности, пересечения линий строго запрещены.
Согласен

профессор А.А. Тюгашев писал(а):
При использовании графического примитива, соответствующего условию, ветвь «Да» всегда идет по вертикали вниз, «Нет» - направо.
Не согласен.
Вижу три недостатка.
1. Приходится вводить лишние (ненужные) инверсии.
2. Приходится отступать от от естественных форм языка в пользу вычурных оборотов речи.
3. Увеличивается вероятность двойных отрицаний

              Цитата:
              «Если это возможно, избегайте отрицаний в булевых выражениях.
              Представляется, что их понимание представляет трудность для многих программистов».
                          Эдвард Йодан

профессор А.А. Тюгашев писал(а):
Самый «наихудший» или «редкий» случай отображается как можно правее.
Согласен

профессор А.А. Тюгашев писал(а):
Макропрограмма представляет собой группу правил, отображаемую неким аналогом схемы «силуэт» Паронджанова. «Силуэт» состоит из вертикальных ветвей. В каждой ветви при использовании разработанной совместно с представителями Заказчика визуальной нотации фигурирует одно условие (имеющее как правило сложный характер и соответствующее частному вектору состояния СТК), в случае истинности которого выполняются расположенные ниже действия.
Не согласен.
"имеющее как правило сложный характер" это плохо, ибо затрудняет понимание.
Надо использовать каноническую форму логических выражений, принятую в языке ДРАКОН. (См. мою книгу "Учись...").

профессор А.А. Тюгашев писал(а):
В связи с тем, что в структуре макропрограмм существуют команды для перехода к анализу другого правила, был также разработан визуализатор связей. Макропрограмма представляется графом, в котором множество ребер отражает связи между группами правил (рис. 2).

Группа 00 "1ПЩС0317) Группа 03 ) ( Гр\ггпа 04

чЛПГЮ(С100б) рШПЮ(С1006) ' ЛПГ03(С1ОО5) С Группа 13 1С гР>тта^

01(С1003} ¡ТПГОО^бЗТ) уТШПХЩ'ЛШ)

Группа 01 ии(С'1иОЗ). .'ШГОЦОООЗ). ЛПГ»2<С1003)

ППГ0б(К5б45)\ ——-^ЖЕГОбСК-^ЗТ)

Группа 07 ) \лПГ0б(КЗ-11б) ( Группа 05

\ЛПГ00(К3416)

Группа 09

\ЛПО(С1050), ТПКС1050)

Группа 02 1 ( Группа 08

.ТШГОО(СМЮ) / \Ш1Г^2(СЮ135)\Ш1П)1<С1121). ЛПГ02(С1121) /тПГ01(С1121> .ГШГ01(К341й). ЛПГ02СК44Ш /лППЮ<С0310) (Группа 12 ТГруппа 11

,ЯПГ00(С0310) \ I ^ШГОО(СОт). ЛПГ0О(СО31О), ЛПГОО(СОЗЮ)

Группа 10

Рис. 2. Экран визуализации связей между группами правил
Не согласен.
Сплошные сокращения утаивают смысл и затрудняют понимание.

КиберЛенинка: https://cyberleninka.ru/article/n/podho ... bortovyh-1


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Сентябрь, 2017 02:27 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 336
Владимир Паронджанов писал(а):
Дискуссия с профессором А.А. Тюгашевым

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Сентябрь, 2017 13:43 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 465
Вопросы по визуализации связей между группами правил:
1. Связи обнаруживаются автоматически или нужно их создавать вручную?
2. Диаграмма связей генерируется автоматически или рисуется вручную?
3. Что такое "группа правил"? Это такой как бы силуэтик, как на предыдущей картинке?
Вложение:
6.png
6.png [ 37.81 КБ | Просмотров: 4487 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Сентябрь, 2017 22:52 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 336
Степан Митькин писал(а):
Вопросы по визуализации связей между группами правил:
1. Связи обнаруживаются автоматически или нужно их создавать вручную?
2. Диаграмма связей генерируется автоматически или рисуется вручную?
3. Что такое "группа правил"? Это такой как бы силуэтик, как на предыдущей картинке?
Вложение:
6.png

1. Связи задаются проектировщиком с помощью специального программного модуля СИПР МП (не имеющего графической природы).
2. Диаграмма рисуется автоматически по заданным связям в другой подсистеме - подсистеме визуализации.
3. Во-первых, приведенная выше картинка - не силуэтик. Во-вторых, именно та, коя здесь приведена, имеет к Дракону вообще слабое отношение, как и к изображению связей между группами. Понятие существует более строго не "группа правил" на самом деле, а "группа логических последовательностей". При этом под "логической последовательностью" понимается аналог ветки силуэта Дракона, а "группа" - действительно некий аналог "силуэта". Однако, это не Дракон, просто похоже. Например, каждая "логическая последовательность" группы включает ровно одно условие, как правило - сложное, со многими И, ИЛИ, НЕ, и действия, предпринимаемые, если условие выполняется. В противном случае в "ветке" ничего не предпринимается вообще.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Октябрь, 2017 18:12 

Зарегистрирован: Среда, 27 Февраль, 2008 19:32
Сообщения: 16
27-28 сентября проходила ежегодная конференция по информационным технологиям в ракетно-космической отрасли «ИТ РКО-2017»

Я на ней делал доклад на тему «Устройство многоканальной обработки быстро меняющихся параметров на борту ЛА, выполненное на ПЛИС, в виде системы на одном кристалле».

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

Весь интерес состоит в том, что данная сложная телеметрическая система была полностью разработана на языках: Дракон и InteloGraf. Схемы набирались в САПР «IntelGraf», разработанной мною. Затем переводились в VHDL код встроенным кодогенератором.

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

Сенюгин Николай.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Октябрь, 2017 20:16 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 151
NickSen писал(а):
Весь интерес состоит в том, что данная сложная телеметрическая система была полностью разработана на языках: Дракон и InteloGraf. Схемы набирались в САПР «IntelGraf», разработанной мною. Затем переводились в VHDL код встроенным кодогенератором.

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


Поделитесь как вы тестировали программу?
Допустим, сделали алгоритм. Как проверить, что он вообще работает?
Или так: нашлась ошибка. Исправили. Как убедиться, что в будущем она не "добавится вновь"?

Не верится, что "программа сразу пишется без единой ошибки".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Октябрь, 2017 21:10 

Зарегистрирован: Среда, 27 Февраль, 2008 19:32
Сообщения: 16
Ошибки конечно бывают, но это в основном ошибки «невнимательности» и синтаксические, которые сразу же выявляются на этапе компиляции. Здесь главное состоит в том, чтобы ошибки исправлять не в тексте, а в схеме, с последующей повторной автоматической генерацией кода. Ошибки грубые, стратегические при этом возникают достаточно редко.
Очень часто удаётся разработать проект который начинает работать правильно сразу.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Октябрь, 2017 22:35 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 151
NickSen писал(а):
Ошибки конечно бывают, но это в основном ошибки «невнимательности» и синтаксические, которые сразу же выявляются на этапе компиляции. Здесь главное состоит в том, чтобы ошибки исправлять не в тексте, а в схеме, с последующей повторной автоматической генерацией кода. Ошибки грубые, стратегические при этом возникают достаточно редко.
Очень часто удаётся разработать проект который начинает работать правильно сразу.

А какой объём проекта?
Конечно, если проект на 5-6 строк VHDL кода, то может и получиться "сразу без ошибок".

Наверняка слышали про ошибку Pentium FDIV?
Возможно, слышали про TSX bug. Да постоянно такие ошибки сейчас обнаруживаются.
А вы говорите "проект сразу работает правильно". Вот никак не верится.

Вот пример, где тестируют микропроцессоры. Как раз на предмет того, правильно ли они отрабатывают входные команды.
http://2016.secr.ru/program/submitted-p ... le-of-mips
Они по-вашему ерундой занимаются? Чего это они не могут с первого раза сделать процессор, который бы работал правильно? Чудные люди, зачем-то занимаются тестированием.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Октябрь, 2017 08:13 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 733
Владимир, у Вас неадекватные ожидания от Дракона.

Дракон (Дружественный Русский Алгоритмический язык Который Обеспечивает Наглядность) обеспечивает наглядную запись алгоритма.

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

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

Вы задаетесь вопросами:
Цитата:
Они по-вашему ерундой занимаются?
Они обмениваются знаниями об ошибках или особенностях элементов.

Цитата:
А какой объём проекта?
Конечно, если проект на 5-6 строк VHDL кода, то может и получиться "сразу без ошибок".
Наглядность Дракон-алгоритма уменьшает вероятность ошибок сделанных разработчиком в проекте большого объема, позволяет специалистам в предметной области указать на имеющиеся в проекте ошибки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Октябрь, 2017 10:10 

Зарегистрирован: Среда, 27 Февраль, 2008 19:32
Сообщения: 16
Вопрос о тестировании устройства является конечно не праздным, тем более когда речь идёт о бортовом оборудовании.

Но в данном случае проблема была в другом. Было бы что тестировать!

Аналогичное устройство у нас безуспешно пытался создать целый отдел возглавляемый д.т.н. Специалисты прекрасно знающие предметную область. Они «пахали» будь здоров, без выходных и проходных. Что то у них не сложилось. Да и в нашем отделе этим тоже занимались несколько человек.

И только используя языки InteloGraf и Дракон мне удалось наконец достичь цели. Конечно немаловажную роль сыграла здесь и среда разработки «IntelGraf», которая также должна удовлетворять когнитивным и эргономическим требованиям!

По поводу объема полученного кода. Я точно не считал, но уверен, что больше 10 тысяч строк.

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 22 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2018, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB