Форум Новости Космонавтики

Весьма интересно выделенное, как мне кажется...

https://www.iss-reshetnev.ru/media/newspaper/newspaper-2016/newspaper-410.pdf

ЦитироватьСпутники, создаваемые решетнёвцами, из поколения в поколение становятся всё более многофункциональными, растёт спектр решаемых ими задач. Соответственно, для их бортовых компьютеров спутникостроителям приходится писать всё более сложные и объёмные программы. Для обработки существенно возросших потоков информации требуется соответствующее аппаратное обеспечение. И сегодня специалисты отдела проектирования и испытаний аппаратуры бортового комплекса управления как раз заняты наземной экспериментальной отработкой бортового компьютера нового поколения, разработанного и изготовленного Ижевским радиозаводом по техническому заданию Решетнёвской фирмы. Бортовой цифровой вычислительный комплекс С-32М1 имеет характеристики, превышающие возможности предшественников по отдельным показателям до 2-5 раз... применены новые технические решения, такие как центральный процессор архитектуры SPARC V8, память магниторезистивного типа, при котором запоминающее устройство хранит записанную информацию с помощью магнитных моментов при отсутствии внешнего электропитания. Внутренние связи компьютера организованы на основе перспективного интерфейса SpaceWire... был подобран радиационно-стойкий процессор разработки КНР, который в перспективе будет заменён на разрабатывающийся отечественный аналог. При растущем мозговом ресурсе космический бортовой компьютер всё больше теряет в весе и габаритах... Созданный прибор имеет массу всего 5 кг... 
В решении этой важной для предприятия задачи активно задействован и отдел системного программирования. Его специалисты занимаются созданием средств разработки программ для компьютера нового поколения и операционной системы, сохраняющей интерфейсы, традиционные для бортового программного обеспечения АО «ИСС»

Все же БОС самописная лучше, как показывает практика...

ЦитироватьTAU пишет:
с помощью магнитных моментов при отсутствии внешнего электропитания

Магниторезистивная память. Ничего сверхестественного.

ЦитироватьTAU пишет:
Внутренние связи компьютера организованы на основе перспективного интерфейса SpaceWire

Позволяет реализовать модульный принцип.

ЦитироватьTAU пишет:
созданием средств разработки программ для компьютера нового поколения и операционной системы , сохраняющей интерфейсы

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

Цитироватьthunder26 пишет: На предыдущих машинах это уже существует. В связи со сменой архитектуры процессора необходима разработка новых.

Потроллить прибежал, литератор? ;) Ну тогда расскажите нам, какая связь между архитектурой процессора, и интерфейсами к подсистемам, что так необходимы новые?

Творческая переработка?

ЦитироватьLEON (https://ru.wikipedia.org/wiki/LEON), 32-битная однопоточная реализация SPARC V8, разработанная исключительно для использования в космосе. Исходный код написан на VHDL (https://ru.wikipedia.org/wiki/VHDL) и лицензирован под GPL (https://ru.wikipedia.org/wiki/GPL).

ЦитироватьNot пишет:
Потроллить прибежал, литератор?

Кто кто, простите?
Кого потроллить?

ЦитироватьZOOR пишет:
Творческая переработка?

ЦитироватьLEON (https://ru.wikipedia.org/wiki/LEON) , 32-битная однопоточная реализация SPARC V8, разработанная исключительно для использования в космосе. Исходный код написан на VHDL (https://ru.wikipedia.org/wiki/VHDL) и лицензирован под GPL (https://ru.wikipedia.org/wiki/GPL) .

Переработка чего?
SPARC v8 - система команд. Какую-то систему команд нужно использовать, так лучше с чем-нить совместимую: имеющийся софт использовать... хотя б средства разработки.

Я понимаю, команде Мультиклета делать было нечего: их идеи можно было реализовать только написав с нуля компиляторы и весь тулчейн. Я понимаю товарищей с Эльбрусом: у них ситуация даже хуже, только хуже.
Но если разрабатывается обычный RISC-проц, то лучше брать что-то стандартное или по крайней мере имеющееся - пусть со своими расширениями, но чтоб хотя бы gcc был.

ЦитироватьNot пишет:

Цитироватьthunder26 пишет: На предыдущих машинах это уже существует. В связи со сменой архитектуры процессора необходима разработка новых.

Потроллить прибежал, литератор?  ;)  Ну тогда расскажите нам, какая связь между архитектурой процессора, и интерфейсами к подсистемам, что так необходимы новые?

Вам слово "драйвера" известно, чудо в перьях?

ЦитироватьSGS_67 пишет:

ЦитироватьNot пишет:

Цитироватьthunder26 пишет: На предыдущих машинах это уже существует. В связи со сменой архитектуры процессора необходима разработка новых.

Потроллить прибежал, литератор?  ;)  Ну тогда расскажите нам, какая связь между архитектурой процессора, и интерфейсами к подсистемам, что так необходимы новые?

Вам слово "драйвера" известно, чудо в перьях?

Ну, на чистом ассемблере драйвера писать сейчас тоже любителей мало...

ЦитироватьТатарин пишет:

ЦитироватьZOOR пишет:
Творческая переработка?

ЦитироватьLEON (https://ru.wikipedia.org/wiki/LEON) , 32-битная однопоточная реализация SPARC V8, разработанная исключительно для использования в космосе. Исходный код написан на VHDL (https://ru.wikipedia.org/wiki/VHDL) и лицензирован под GPL (https://ru.wikipedia.org/wiki/GPL) .

Переработка чего?
SPARC v8 - система команд. Какую-то систему команд нужно использовать, так лучше с чем-нить совместимую: имеющийся софт использовать... хотя б средства разработки.

Со средствами разработки для Леона как раз жуткая засада.
Единственным его достоинством является условно-бесплатное ядро.
Программистам головняк на ближайшие лет 5 гарантирован.
Если это полукетайское чудо не помрет естественной смертью раньше.  :(  

ЦитироватьНо если разрабатывается обычный RISC-проц, то лучше брать что-то стандартное или по крайней мере имеющееся - пусть со своими расширениями, но чтоб хотя бы gcc был.

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

ЦитироватьТатарин пишет:
Ну, на чистом ассемблере драйвера писать сейчас тоже любителей мало...

Как бы не пришлось...

ЦитироватьSGS_67 пишет:

ЦитироватьТатарин пишет:
Ну, на чистом ассемблере драйвера писать сейчас тоже любителей мало...

Как бы не пришлось...

Зато какой оптимальный код получить можно ....
И вообще этим ООП уже все что можно загадили, даже где не надо  8)

ЦитироватьSGS_67 пишет: 

ЦитироватьНо если разрабатывается обычный RISC-проц, то лучше брать что-то стандартное или по крайней мере имеющееся - пусть со своими расширениями, но чтоб хотя бы gcc был.

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

Есть как минимум gcc.
Это уже нефигово в сравнении с новой архитектурой.

Имея gcc уже можно плясать. А вот своё с нуля...

Интересно другое.
Почему решетневцам не удалось приобрести у "китайских союзников" процессоры нового поколения (а у них такие имеются)?
Для которых есть вполне приличные бесплатные средства разработки, библиотеки, приложения, операционные системы и т.д. 
Собственно, вопрос риторический.  :(


Видимо, дела совсем там плохи, раз готовы брать такое г...

ЦитироватьZOOR пишет:

ЦитироватьSGS_67 пишет:

ЦитироватьТатарин пишет:
Ну, на чистом ассемблере драйвера писать сейчас тоже любителей мало...

Как бы не пришлось...

Зато какой оптимальный код получить можно ....
И вообще этим ООП уже все что можно загадили, даже где не надо  8)

"Можно" вовсе не значит, что он будет получен.

Миф об "оптимальности ассемблерного кода" очень популярен среди тех, кто не писал на ассемблере достаточно сложные вещи. Про попытки соревноваться с современными оптимизирующими компиляторами я уж и вовсе молчу - тут требуется не "умение писать на ассемблере", чем многие хвастаются, а доскональное знание целевой архитектуры. 
Таких людей реально очень мало. Большинство довольствуется пониманием мнемоник и отсутствием судорог при виде документации.
Причём, сильная трудоёмкость кодинга и отсутствие нормальных библиотек сделают банальную балансировку дерева по хешу изысканным удовольствием на долгие дни вместо трёх минут работы. И выливается это в "дануегонафиг!" с соответствующей экономией трёх копеек на стековых операциях и просёре тыщи рублей на алгоритмах.


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

ООП в драйверах не нужно. "С" вполне достаточно. Зато не нужно закат солнца вручную устраивать.

ЦитироватьТатарин пишет:
"Можно" вовсе не значит, что он будет получен.
..................
ООП в драйверах не нужно. "С" вполне достаточно. Зато не нужно закат солнца вручную устраивать.

Мне показалось, что ув. ZOOR просто стебается.
Ежели нет, тады ой... :(

ЦитироватьТатарин пишет:
Есть как минимум gcc.
Это уже нефигово в сравнении с новой архитектурой.

Имея gcc уже можно плясать. А вот своё с нуля...

Простите за вопрос, но Вы работали когда-нить с gcc для Леона?

Для новых архитектур (тех же Cortex A, к примеру) есть стабильные ОС, драйвера и куча бесплатных тулзов, которые реально можно пользовать. Сертифицировать - не проблема, ибо большинство в исходниках.
А вот для Леона - на поклон к Гайслеру. Который не только дерёт деньги за сопровождение (оченно кривое, кстати), но и может обрубить его в любой момент. Потому, как существует фактор "санкций".

Так что флаг в руки ИСС... и пожелание скорее закопать эту мертворожденную дитятю.
Хотя, альтернативу с ходу предложить нелегко...
:(

ЦитироватьSGS_67 пишет:

ЦитироватьNot пишет:

Цитироватьthunder26 пишет: На предыдущих машинах это уже существует. В связи со сменой архитектуры процессора необходима разработка новых.

Потроллить прибежал, литератор?  ;)  Ну тогда расскажите нам, какая связь между архитектурой процессора, и интерфейсами к подсистемам, что так необходимы новые?

Вам слово "драйвера" известно, чудо в перьях?

Вы разницу между драйвером и интерфейсом видите, чюдо краснозадое? ;)

ЦитироватьSGS_67 пишет:

ЦитироватьТатарин пишет:
"Можно" вовсе не значит, что он будет получен.
..................
ООП в драйверах не нужно. "С" вполне достаточно. Зато не нужно закат солнца вручную устраивать.

Мне показалось, что ув. ZOOR просто стебается.

Он прав. К слову говоря, ПО Кьюриоситу (марсианской лаборатории) написано на С, с последующим формальным анализом кода.

ЦитироватьNot пишет:

ЦитироватьSGS_67 пишет:

ЦитироватьNot пишет:

Цитироватьthunder26 пишет: На предыдущих машинах это уже существует. В связи со сменой архитектуры процессора необходима разработка новых.

Потроллить прибежал, литератор?  ;)  Ну тогда расскажите нам, какая связь между архитектурой процессора, и интерфейсами к подсистемам, что так необходимы новые?

Вам слово "драйвера" известно, чудо в перьях?

Вы разницу между драйвером и интерфейсом видите, чюдо краснозадое?  ;)  

Я-то? Ессно, вижу.
Ибо второе не может работать без первого.
А первое завязано на архитектуру. О которой подобные вам дятелы не имеет и малого представления.

ЦитироватьNot пишет:

ЦитироватьМне показалось, что ув. ZOOR просто стебается.

Он прав.

Прав, что стебается над такими лоботрясами, как вы, или что действительно так думает?

Цитировать К слову говоря, ПО Кьюриоситу (марсианской лаборатории) написано на С, с последующим формальным анализом кода.

И что из того?
Ув. Татарин обозначил основные моменты. Можно было бы дополнить, только сыпать бисер смысла пока нет.

ЦитироватьSGS_67 пишет:

ЦитироватьВы разницу между драйвером и интерфейсом видите, чюдо краснозадое?  ;)  

Я-то? Ессно, вижу.
Ибо второе не может работать без первого.
А первое завязано на архитектуру.

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

ЦитироватьNot пишет:

ЦитироватьSGS_67 пишет:

ЦитироватьВы разницу между драйвером и интерфейсом видите, чюдо краснозадое?  ;)  

Я-то? Ессно, вижу.
Ибо второе не может работать без первого.
А первое завязано на архитектуру.

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

Не... точно болван...
В КАЖДОЙ микропроцессорной/контроллерной архитектуре якобы стандартные внешне интерфейсы имеет различную аппаратную реализацию.
И у каждой реализации есть свои глюки. И каждая требует свой собственный драйвер и программную поддержку.
О чём и написал thunder26, пусть и не слишком доходчиво.

ЦитироватьSGS_67 пишет:

ЦитироватьNot пишет:

ЦитироватьSGS_67 пишет:

ЦитироватьВы разницу между драйвером и интерфейсом видите, чюдо краснозадое?  ;)  

Я-то? Ессно, вижу.
Ибо второе не может работать без первого.
А первое завязано на архитектуру.

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

Не... точно болван...
В КАЖДОЙ микропроцессорной/контроллерной архитектуре якобы стандартные внешне интерфейсы имеет различную аппаратную реализацию.

Вот тогда и пишите о реализации, а собственно интерфейс обязан быть аппаратно-независимым. Это не Вы тут виноваты, виновата каша в Вашей голове.

ЦитироватьNot пишет:
Вот тогда и пишите о реализации, а собственно интерфейс обязан быть аппаратно-независимым.

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

Или вы до сих пор не знаете, что контроллеры интерфейсов сейчас принято реализовать "на борту"?


Впрочем, я опять сыплю бисер...

ЦитироватьSGS_67 пишет:

ЦитироватьNot пишет:
Вот тогда и пишите о реализации, а собственно интерфейс обязан быть аппаратно-независимым.

Снаружи. Хоть это и не всегда так.

Всегда. Посмотрите в словаре определение термина "интерфейс" и не морочьте другим голову.

ЦитироватьSGS_67 пишет:
А здесь разговор об архитектуре процессора. Что и было обозначено в первом же посте.

- А здесь разговор о программных интерфейсах:

ЦитироватьTAU пишет:
Его специалисты занимаются созданием средств разработки программ для компьютера нового поколения и операционной системы, сохраняющей интерфейсы, традиционные для бортового программного обеспечения АО «ИСС»

ЦитироватьSGS_67 пишет:
Впрочем, я опять

- бредите, как обычно.

ЦитироватьSGS_67 пишет:

ЦитироватьТатарин пишет:
Есть как минимум gcc.
Это уже нефигово в сравнении с новой архитектурой.

Имея gcc уже можно плясать. А вот своё с нуля...

Простите за вопрос, но Вы работали когда-нить с gcc для Леона?

Для новых архитектур (тех же Cortex A, к примеру) есть стабильные ОС, драйвера и куча бесплатных тулзов, которые реально можно пользовать. Сертифицировать - не проблема, ибо большинство в исходниках.
А вот для Леона - на поклон к Гайслеру. Который не только дерёт деньги за сопровождение (оченно кривое, кстати), но и может обрубить его в любой момент. Потому, как существует фактор "санкций".

Так что флаг в руки ИСС... и пожелание скорее закопать эту мертворожденную дитятю.
Хотя, альтернативу с ходу предложить нелегко...
 :(

Не. Тут я чисто теоретизирую. 

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

ЦитироватьNot пишет: 
Всегда. Посмотрите в словаре определение термина "интерфейс" и не морочьте другим голову.

Чел, если бы случилось невероятное, и вы бы стали разрабатывать систему с кучей связей, вас бы стали драть за то, что "ничо не работает" не по словарю с термином, а прямо в лузу и с протяжкой.
Объясняйтесь потом с дохтуром, а здесь перечитайте всё сначала, и ужаснитесь от собственной писанины.

ЦитироватьТатарин пишет:
Не. Тут я чисто теоретизирую.

Вопрос был без подколки, самогО мимо этого добра как-то пронесло, хоть и ветерком подуло.

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

Это общая беда отечественной микроэлектроники.
Гигантский разрыв между производителем и пользователем.
Вроде, и есть элементная база, пусть и без распальцовок, но юзать, казалось бы, можно.
А на деле - так её почти что нет. Именно по причине отсутствия какой-либо поддержки железа в интересах пользователя.
О причинах можно распространяться много и долго, только делу это не поможет, потому как у производителей другие интересы, обусловленные спецификой отечественного уложения дел в данной области.

ЦитироватьТатарин пишет:
Я, конечно, верю, что под эту хрень писать плохо, но хотя бы есть уверенность, что это возможно, что этот квест до тебя уже прошли.

Угу.
Ежли не Гайслер, то недо- гсс, кетайская документация, и с криками "ура" в рукопашную...

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

ЦитироватьSGS_67 пишет:

ЦитироватьNot пишет:
Всегда. Посмотрите в словаре определение термина "интерфейс" и не морочьте другим голову.

Чел, если бы случилось невероятное, и вы бы стали разрабатывать систему с кучей связей, вас бы стали драть за то, что "ничо не работает" не по словарю с термином, а прямо в лузу и с протяжкой.
Объясняйтесь потом с дохтуром, а здесь перечитайте всё сначала, и ужаснитесь от собственной писанины.

Давайте без луз, протяжек и писанины, литератор.

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

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

Господа, я не понимаю сути вашей полемики.
В информационном сообщении вроде все понятно написано:

ЦитироватьЕго специалисты занимаются созданием средств разработки программ для компьютера нового поколения и операционной системы, сохраняющей интерфейсы, традиционные для бортового программного обеспечения АО «ИСС»

Есть среда разработки БПО, реализованная на Модула-2. Под разные типы машин необходимо создание своей кросс-системы программирования. Для того, чтобы не переписывать каждый раз БПО под новый процессор, необходимо сохранить интерфейс этого БПО.
http://novosti-kosmonavtiki.ru/forum/messages/forum12/topic11063/message1534083/#message1534083

ЦитироватьБлагодаря использованию языка МОДУЛА-2, удалось создать унифицированный программный интерфейс среды программного функционирования, который воспроизводится в каждой операционной системе для каждой вычислительной платформы. Это позволяет заимствовать программы, созданные для одной вычислительной платформы, и без доработки использовать их для другой, тем самым, существенно сокращая сроки разработки БПО и повышая его надёжность. 

Ни о каких интерфейсах подсистем речи не идет.

По поводу закупки или бесплатного использования существующих ОС и всего необходимого. Стоит подумать, насколько это допустимо для использования в составе КА в целом и в КА АО "ИСС" в частности.

Цитироватьthunder26 пишет: 
По поводу закупки или бесплатного использования существующих ОС и всего необходимого. Стоит подумать, насколько это допустимо для использования в составе КА в целом и в КА АО "ИСС" в частности.

У TAS, Airbus, OHB до сих пор универсального ответа нет, то свои, то покупные ОС пользуют.

ЦитироватьNot пишет:
Итак, у нас есть многомодульная система, причем каждый модуль соединяется с ней стандартным для фирмы интерфейсом. Стандартизованность интерфейсов позволяет взаимозаменять модули, откладывая испытания до готовности.

Это всё понятно и всё правильно. Но только в теории.
В каждом новом чипе существует куча ошибок, значительная часть которых связана именно с несоответствием периферии стандартам, или некими особенностями, не отражёнными в стандартах.
Всё это железо надо запускать, для чего нужна грамотная команда, хорошая документация, средства разработки, отладки и т.д., да, ещё ВРЕМЯ, а ежели неполучаецца - требовать от производителя ревизии чипа.
У нас с последним не просто плохо, а вообще никак, ну и с кетайцами вряд ли будет сильно лучше.

Цитироватьthunder26 пишет:
Ни о каких интерфейсах подсистем речи не идет.

Там же, написано:

ЦитироватьВнутренние связи компьютера организованы на основе перспективного интерфейса SpaceWire...

Которому нужна соотв. программная поддержка.

ЦитироватьПо поводу закупки или бесплатного использования существующих ОС и всего необходимого. Стоит подумать, насколько это допустимо для использования в составе КА в целом и в КА АО "ИСС" в частности.

Дак ПО с открытым исходным кодом отчего бы не использовать, после прохождения необходимых тестов и рихтовки?

ЦитироватьЕсть среда разработки БПО, реализованная на Модула-2. Под разные типы машин необходимо создание своей кросс-системы программирования.

А имеются ли оценки, сколько времени и ресурсов потребует разработка такой среды для Леона?
Насколько мне известно, её придётся создавать с нуля.

Да ещё вопрос: какие именно платформы использует к настоящему времени ИСС?
Имеется в виду архитектура процессоров.

ЦитироватьSGS_67 пишет:
Там же, написано:

ЦитироватьВнутренние связи компьютера организованы на основе перспективного интерфейса SpaceWire ...

Которому нужна соотв. программная поддержка.

В любом случае, отношения к интерфейсам подсистем это не имеет

ЦитироватьSGS_67 пишет:
Дак ПО с открытым исходным кодом отчего бы не использовать, после прохождения необходимых тестов и рихтовки?

На все воля Заказчика. 

ЦитироватьSGS_67 пишет:

Да ещё вопрос: какие именно платформы использует к настоящему времени ИСС?
Имеется в виду архитектура процессоров.

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

Цитироватьthunder26 пишет:
В любом случае, отношения к интерфейсам подсистем это не имеет

Как не имеет, если там вся бортовая сеть на нём?

Про интерфейс программный понятно, но мы тут большей частью не об этом.

ЦитироватьНа все воля Заказчика.

Ясно.
Как и то, что "Боливар не вынесет двоих".

Цитировать

ЦитироватьSGS_67 пишет:
Да ещё вопрос: какие именно платформы использует к настоящему времени ИСС?
Имеется в виду архитектура процессоров.

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

Может, кто другой подскажет, если это не секрет?

Впрочем, какие секреты могут быть после Леона... :(

ЦитироватьSGS_67 пишет: 
Может, кто другой подскажет, если это не секрет?

Ну почему же секрет) Есть открытые публикации, прежде всего А.А. Колташева. Да вот хотя бы
https://www.iss-reshetnev.ru/media/newspaper/newspaper-2016/%E2%84%9611(405).pdf

Очень интересна книга В.Д. Анисимова. Поэма!

Раньше применяли Салют-4. Потом Салют-32 (архитектура VAX-11/750). И БИВК-М (MIPS-III).
ИСС работает и на международный рынок - использовалась платформа OBC-1750 (MIL-STD-1750A).

Большое спасибо.
Получается, что ИСС для каждой платформы заказывает "на стороне" разработку кросс-системы для языка Модула-2, что занимает в среднем 3 года и хз сколько средств. Плюс к тому, двойная компиляция даёт, мягко говоря, не слишком оптимальный исполняемый код для целевого устройства.
Честно говоря, мне такой подход не слишком понятен.
Унификация - унификацией, но чистить зубы через задний проход-то зачем? :(

ЦитироватьSGS_67 пишет:
Получается, что ИСС для каждой платформы заказывает "на стороне" разработку кросс-системы для языка Модула-2,

ЦитироватьВ решении этой важной для предприятия задачи активно задействован и отдел системного программирования

ЦитироватьSGS_67 пишет:
Плюс к тому, двойная компиляция даёт, мягко говоря, не слишком оптимальный исполняемый код для целевого устройства.
Честно говоря, мне такой подход не слишком понятен.
Унификация - унификацией, но чистить зубы через задний проход-то зачем?

Учитывая характер высказываний, извольте похвастаться своими достижениями в области разработки БПО, ОС и средств разработки.

Цитироватьthunder26 пишет: В решении этой важной для предприятия задачи активно задействован и отдел системного программирования

Это вполне естественно, однако, я сужу по информации, навроде этой:
http://www.iis.nsk.su/history/iss-reshetnev

ЦитироватьУчитывая характер высказываний, извольте похвастаться своими достижениями в области разработки БПО, ОС и средств разработки.

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

ЦитироватьSGS_67 пишет:
Большое спасибо.
Получается, что ИСС для каждой платформы заказывает "на стороне" разработку кросс-системы для языка Модула-2, что занимает в среднем 3 года и хз сколько средств.

Все что нужно - кодогенератор из пи-кода в машкод.

ЦитироватьSGS_67 пишет:
Плюс к тому, двойная компиляция даёт, мягко говоря, не слишком оптимальный исполняемый код для целевого устройства.

Где вы увидели двойную компиляцию?

ЦитироватьSGS_67 пишет:
Честно говоря, мне такой подход не слишком понятен.

Так спросите, вам разжуют, если не будете навязывать свои методы:

ЦитироватьSGS_67 пишет:
но чистить зубы через задний проход-то зачем?  :(  

ЦитироватьNot пишет:

ЦитироватьSGS_67 пишет:
Большое спасибо.
Получается, что ИСС для каждой платформы заказывает "на стороне" разработку кросс-системы для языка Модула-2, что занимает в среднем 3 года и хз сколько средств.

Все что нужно - кодогенератор из пи-кода в машкод.

Нефиг делать, верно?
А расширения языка, специфические для данной архитектуры, а оптимизация исполняемого кода, а средства отладки, а библиотеки?
Батенька, вы о кодогенераторах хоть какое-нибудь представление имеете?

Цитировать

ЦитироватьSGS_67 пишет: 
Плюс к тому, двойная компиляция даёт, мягко говоря, не слишком оптимальный исполняемый код для целевого устройства.

Где вы увидели двойную компиляцию? 

Не просто дятел, но ещё и слепой...
Вот, например:

Цитировать5. Договор №109, 2000 – 2002, март 2003. Кросс-система программирования на языке Модула-2 для OBC-1750 (с участием ООО "Эксельсиор"  ;)  
Договор выполнен на 110% – по доп. соглашению в работы был включен этап, в рамках которого в целях использования в международных проектах система сделана полностью двуязычной.
Главное  достижение – в короткие сроки создана кросс-система программирования на Модуле-2 через ANSI Си для немецкой БЦВМ OBC-1750, полностью сохраняющая пользовательские и программные интерфейсы КСП-CAMV.

Нормальные люди для данной БЦВМ пишут на С, а не изобретают кросс-системы на Модуле-2.

Цитировать

ЦитироватьSGS_67 пишет: 
Честно говоря, мне такой подход не слишком понятен.

Так спросите, вам разжуют, если не будете навязывать свои методы:

ЦитироватьSGS_67 пишет: 
но чистить зубы через задний проход-то зачем?    :(     

Так это же про вас, и ваши методы написано.  :)

ЦитироватьSGS_67 пишет:

ЦитироватьNot пишет:

ЦитироватьSGS_67 пишет:
Большое спасибо.
Получается, что ИСС для каждой платформы заказывает "на стороне" разработку кросс-системы для языка Модула-2, что занимает в среднем 3 года и хз сколько средств.

Все что нужно - кодогенератор из пи-кода в машкод.

Нефиг делать, верно?
А расширения языка, специфические для данной архитектуры, а оптимизация исполняемого кода, а средства отладки, а библиотеки?
Батенька, вы о кодогенераторах хоть какое-нибудь представление имеете?

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

О кодогенераторах имею самое непосредственное представление, спрашивайте.

ЦитироватьSGS_67 пишет:
Нормальные люди для данной БЦВМ пишут на С, а не изобретают кросс-системы на Модуле-2.

Нормальные люди один раз делают кросс-систему, а не переписывают все БПО на Си

-

ЦитироватьSGS_67 пишет: что занимает в среднем 3 года и хз сколько средств

Если бы вы внимательнее почитали открытые источники, на которые вам давали наводку, как раз бы прочли в них, что передовые технологии разработки БПО в АО "ИСС" (а это не только Модула-2) позволяют создавать полностью БПО для новых аппаратов в кратчайшие сроки (один-два года).

Между прочим, использовать С/С++ (видимо, они скрываются под "стандартными инструментами") для написания критически важных приложений - то, что вы, видимо, считаете правильным ("нормальным") - как раз использование зубной щетки в ненадлежащем месте. Причины этой ситуации скорее исторические, да, подобное применение С/С++ обычно. Но - ненормально.

ЦитироватьSGS_67 пишет:
Батенька, вы о кодогенераторах хоть какое-нибудь представление имеете?
Нормальные люди для данной БЦВМ пишут на С, а не изобретают кросс-системы на Модуле-2.

Процитирую Анисимова:

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

И вообще. Поверьте, при создании критически важного ПО роль технологии (организации процесса, документации, кстати и кодогенераторов, отладочных комплексов с полной имитационной моделью КА, между прочим, и прочая, и прочая) столь велика, и этому на протяжении ряда лет уделялось столько внимания, что это у них вам бы поучиться - я говорю о программистах ИСС - а не выдавать на весь свет безапелляционные суждения о "нормальности".

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

ЦитироватьNot пишет:

ЦитироватьSGS_67 пишет:

ЦитироватьNot пишет:

ЦитироватьSGS_67 пишет:
Большое спасибо.
Получается, что ИСС для каждой платформы заказывает "на стороне" разработку кросс-системы для языка Модула-2, что занимает в среднем 3 года и хз сколько средств.

Все что нужно - кодогенератор из пи-кода в машкод.

Нефиг делать, верно?
А расширения языка, специфические для данной архитектуры, а оптимизация исполняемого кода, а средства отладки, а библиотеки?
Батенька, вы о кодогенераторах хоть какое-нибудь представление имеете?

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

Можноб много распространяться об особенностях архитектуры вычислительных систем, не имеющих поддержки стандартными средствами ЯВУ, однакож, в данной теме не считаю это нужным, ибо не в коня корм.
Предлагаю почитать про что-нить навроде NEON/ММХ/SSE/AVX, а потом уж задавать глупые вопросы.

ЦитироватьО кодогенераторах имею самое непосредственное представление, спрашивайте.

Как при помощи стандартных средств любого ЯВУ выполнить вычисления в фиксированной точке, не через задний проход, а с помощью заточенной под это нативной структуры процессора?

Цитироватьthunder26 пишет:

ЦитироватьSGS_67 пишет:
Нормальные люди для данной БЦВМ пишут на С, а не изобретают кросс-системы на Модуле-2.

Нормальные люди один раз делают кросс-систему, а не переписывают все БПО на Си

Это всё равно придётся делать, рано или поздно, но чем раньше, тем лучше.

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

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет: что занимает в среднем 3 года и хз сколько средств

Если бы вы внимательнее почитали открытые источники, на которые вам давали наводку, как раз бы прочли в них, что передовые технологии разработки БПО в АО "ИСС" (а это не только Модула-2) позволяют создавать полностью БПО для новых аппаратов в кратчайшие сроки ( один-два года).

Скажите, какие это передовые технологии, и я посыплю голову пеплом.

Кстати, этот вопрос уже задавал ранее.

ЦитироватьМежду прочим, использовать С/С++ (видимо, они скрываются под "стандартными инструментами"   ;)   для написания критически важных приложений - то, что вы, видимо, считаете правильным ("нормальным"   ;)   - как раз использование зубной щетки в ненадлежащем месте. Причины этой ситуации скорее исторические, да, подобное применение С/С++ обычно . Но - ненормально .

Вполне нормально, и не через задний проход.
Потому, как развитием (бесплатных!) средств проектирования на основе С, да и вообще, GNU,  для разнообразных платформ занимаются крупные международные сообщества, а не отдельные конторы, хотя и производители железа тоже выкатывают средства разработки, тулзы, библы либо бесплатно, либо по сходной цене. Вот, например, я год назад решил поюзать Тегру X1 от Нвидиа, и там у них:
https://developer.nvidia.com/embedded/downloads#?tx=$product,jetson_tx1

Плюс форум, где решаются вопросы, хоть и далеко не все, однако, там стараюцца.
https://devtalk.nvidia.com/default/board/164/jetson-tx1/

Скажите, для кетайского Леона будет что-нибудь подобное?

ЦитироватьTAU пишет:
И вообще. Поверьте, при создании критически важного ПО роль технологии (организации процесса, документации, кстати и кодогенераторов, отладочных комплексов с полной имитационной моделью КА, между прочим, и прочая, и прочая) столь велика, и этому на протяжении ряда лет уделялось столько внимания, что это у них вам бы поучиться - я говорю о программистах ИСС - а не выдавать на весь свет безапелляционные суждения о "нормальности".

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

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

Ошибаетесь.
Даже в Вашем или моём планшете или смартфоне напихано технологий столько, что ИСС и не снилось.
И это всё как-то работает.

ЦитироватьSGS_67 пишет:

Цитироватьthunder26 пишет:

ЦитироватьSGS_67 пишет:
Нормальные люди для данной БЦВМ пишут на С, а не изобретают кросс-системы на Модуле-2.

Нормальные люди один раз делают кросс-систему, а не переписывают все БПО на Си

Это всё равно придётся делать, рано или поздно, но чем раньше, тем лучше.

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

То что вы сидя на диване лучше всех разбираетесь в БПО и средствах его разработки - никто не сомневается.

В конце-концов выбор языка - вопрос вкусовщины. Если в ИСС есть программисты на Модуле, то зачем заставлять всех переходить на Си? Есть традиции, школа. В конце-концов язык программирования - это просто "пассатижи", которыми решается задача. И какого года выпуска эти пассатижи - в конечном счете никого не волнует. Оптимизация когда и прочее, безусловно важное, вообще особо не имеет значения на КА. Даже при использовании процессоров 10-15 летней давности работа всего БПО наверняка занимает не больше 3-4 процентов процессорного времени. А производительность эта, заметьте, постоянно увеличивается.

Другое дело, если взять сейчас и создавать что-то с нуля. Т.е совсем с нуля. Если представить такую гипотетическую ситуацию, что всех программистов на ИСС уволили, а потом сотрудников набрали по объявлению заново в другом городе. Именно в этом случае (когда с нуля) Си будет выглядеть более предпочтительным языком для БПО. :-) Но никак не в условиях того, что имеется сейчас на предприятии.

Предлагаю срочно все писать на Java и не мучаться :)

Не БПО, но все-же.
Видел мытарства одной конторы, которая под ДОСом пыталась разграничить права доступа (выбор комплекта доступного СПО) путем запароливания БИОС и выбором там загрузочного диска с предустановленным комплектом СПО именно для данного пользователя в данном конкретном случае.

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

ЦитироватьZOOR пишет:
Предлагаю срочно все писать на Java

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

ЦитироватьEchidna пишет:
Даже при использовании процессоров 10-15 летней давности работа всего БПО наверняка занимает не больше 3-4 процентов процессорного времени

15-30%, на тех 6 разных весьма аппаратах, с которыми работал последние годы.
Что не мешает "вылезать" за пределы реального времени изредка, в ситуациях не протестированных в реалистичных условиях. Но это проблема разработки конкретного ПО, более-менее реальные проблемы по ресурсам вылезают редко  (могу припомнить только ATV и Bepi) и они все же решаемы тоже. 

ЦитироватьEchidna пишет:
В конце-концов выбор языка - вопрос вкусовщины. Если в ИСС есть программисты на Модуле, то зачем заставлять всех переходить на Си? Есть традиции, школа. В конце-концов язык программирования - это просто "пассатижи", которыми решается задача. И какого года выпуска эти пассатижи - в конечном счете никого не волнует.

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

Цитировать Оптимизация когда и прочее, безусловно важное, вообще особо не имеет значения на КА. Даже при использовании процессоров 10-15 летней давности работа всего БПО наверняка занимает не больше 3-4 процентов процессорного времени. А производительность эта, заметьте, постоянно увеличивается.

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

ЦитироватьДругое дело, если взять сейчас и создавать что-то с нуля. Т.е совсем с нуля. Если представить такую гипотетическую ситуацию, что всех программистов на ИСС уволили, а потом сотрудников набрали по объявлению заново в другом городе. Именно в этом случае (когда с нуля) Си будет выглядеть более предпочтительным языком для БПО. :-) Но никак не в условиях того, что имеется сейчас на предприятии.

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

ЦитироватьSGS_67 пишет: Иначе ИСС рискует стать мировым лидером в создании аццки унифицированной кросс-системы Модула-2 для любых процессоров, 

Цитировать1) кроме них нафуй никому не нужной, 

Цитировать2) не поддерживаемой никаким сообществом, 

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

По пунктам:
1) ИСС занимается достаточно серьезным делом (напомню, 2/3 спутников России), чтобы ценность представляла разработка, применяемая даже только на их собственном предприятии.

2) Если брать кросс-систему программирования (КСП) с использованием Модулы-2 - она создана при активном участии ученых СО РАН из Новосибирска, непосредственно ООО "Эксцельсиор".

3) Затраты представляются лично Вам "огромными", и на самом деле люди, конечно, действительно много и плодотворно творчески поработали. Но!!! При использовании "традиционных" подходов трудоемкость процесса была бы больше вследствие его менее высокого уровня качества - соответственно, скорее общие трудозатраты значительно сократилась. Советую перечитать вдумчиво в приведенных источниках "истории успеха" о переносе без существенных изменений 90% наработанного БПО на другие вычислительные платформы и об одном-двух годах, затрачиваемых на полное создание БПО нового спутника.

ЦитироватьSGS_67 пишет: 
Скажите, какие это передовые технологии, и я посыплю голову пеплом.

Посыпайте. У них в реальную промышленную практику внедрены, например:

1) Система автоматизации испытаний БПО на основе мощного наземного отладочного комплекса (НОК) с полной программной имитацией изделия, включая БКУ и все остальные системы и автоматизацией проектирования циклограмм испытаний на основе проблемно-ориентированных языков.

2)  Автоматизированная система сопровождения программ, изделий и документов БПО, она же - система управления задачами и проблемами АСПИД.

3) Бортовые интерпретаторы СЕАНС и ДКД, фактически являющиеся бортовым "искусственным интеллектом" с оперативным изменением правил поведения в случае необходимости по радиоканалу (до трети правил закладывается в процессе эксплуатации).

4) Применение для средств интегрального автономного управления спутником проблемно-ориентированных языков, не требующих знания программирования. Что позволяет проектантам и специалистам по бортовым системам непосредственно задавать логику управления аппаратом без привлечения дорогостоящего многостадийного процесса перепроектирования/кодирования/отладки программ и устранения эффекта "испорченного телефона" в проектной команде (система программирования РЕАЛ).

5) Для ИСС обновление БПО серийных аппаратов ("перепрошивка" ), находящихся на орбите (десятки ГЛОНАССов, например) - рутинная процедура, выполнявшаяся успешно многократно.

6) Автоматический анализ степени покрытия программ БПО модульными тестами с выделением непокрытых операторов.

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

Рекомендую познакомиться с презентацией (http://www.slideshare.net/IosifItkin/automated-software-development-and-verification-technologies-in-the-aerospace-industry#14233077108191&fbinitialized). 

Ну и ИСС не "почивает на лаврах", а постоянно совершенствует свои технологии разработки БПО.  Я бы отнес их процессы к высшему, "оптимизирующему" уровню зрелости по модели CMM.

ЦитироватьSGS_67 пишет:
развитием (бесплатных!) средств проектирования на основе С, да и вообще, GNU, для разнообразных платформ занимаются крупные международные сообщества, а не отдельные конторы

Ага. И уровень поддержки (сопровождения), к сожалению, продуктов этих "сообществ" зачастую оставляет желать лучшего. А в космосе, ежели чего - "у каждой ошибки есть имя и фамилия" - с кого спрашивать?
Не годится, в общем, по большому счету использовать инструменты без конкретной поддерживающей "конторы".

ЦитироватьДаже в Вашем или моём планшете или смартфоне напихано технологий столько, что ИСС и не снилось.
И это всё как-то работает

Во-первых, мне снилось. Во-вторых, вот именно что как-то.

ЦитироватьTAU пишет: 
По пунктам:
1) ИСС занимается достаточно серьезным делом (напомню, 2/3 спутников России), чтобы ценность представляла разработка, применяемая даже только на их собственном предприятии.

2) Если брать кросс-систему программирования (КСП) с использованием Модулы-2 - она создана при активном участии ученых СО РАН из Новосибирска, непосредственно ООО "Эксцельсиор".

3) Затраты представляются лично Вам "огромными", и на самом деле люди, конечно, действительно много и плодотворно творчески поработали.

1. Именно поэтому меня данная тема и заинтересовала.

2. Да, мне это известно, даже ссылку приводил.

3. В том-то всё и дело, что с каждой сменой аппаратной платформы требуется большая творческая работа для обеспечения средств проектирования для неё.
-----------------------------------
Ещё раз: речь не о том, что система проектирования ИСС на основе Модула-2 архаичной, плохой, и т.д.
А о том, что она ортогональна сложившемуся подходу к проектированию ПО в мире.
Посему, несёт издержки своего особого пути.
ПМСМ, ненужные.

Цитировать Но!!! При использовании "традиционных" подходов трудоемкость процесса была бы больше вследствие его менее высокого уровня качества - соответственно, скорее общие трудозатраты значительно сократилась.

:o
Что за чушь!?
Традиционные подходы как раз и обеспечивают наивысший уровень качества при меньшей трудоёмкости, поскольку:
а) имеют развитые средства проектирования, отладки, поддержки.
б) многократно выверены, протестированы и обезглючены большим сообществом потребителей.
в) имеют многократно больший потенциал привлечения грамотных специалистов, или даже студентов, которых не придётся переучивать на непривычную среду.

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

Так что вот ещё нагрузка: под систему ИСС готовить спецов "с нуля", которые потом могут запросто отвалить на вольные хлеба.
С кем рискуете в конце-концов остаться? И не только вы?

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет:
развитием (бесплатных!) средств проектирования на основе С, да и вообще, GNU, для разнообразных платформ занимаются крупные международные сообщества, а не отдельные конторы

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

Приведите пример такого непотребства.
Именно ваш Леон как раз под него подходит, но это стрела, летящая в вашу же сторону.
Поскольку он поддерживается Гайслером, и более никем, по причине более чем ограниченной востребованности.
Но даже для него gcc и набор драйверов для бесплатных IP корок существует.
А вот хотя бы компилятор Модула-2 - увы.  :(  
Придётся ипатиться, как бы снова не через "ANSI C", то бишь, через корму.

Цитировать А в космосе, ежели чего - "у каждой ошибки есть имя и фамилия" - с кого спрашивать?
Не годится, в общем, по большому счету использовать инструменты без конкретной поддерживающей "конторы".

Да я как раз не против этого, а за.
Но только позу рак при этом принимать не обязательно.
Ни вам, ни поддержке.

ЗЫ. Если Вы ещё не поняли: современные средства разработки, приложения, библиотеки, драйвера сейчас можно найти в ИСХОДНИКАХ.
Тестировать, править и сопровождать самостоятельно, или с привлечением поддерживающих организаций, никто не запрещает.

Цитировать

ЦитироватьДаже в Вашем или моём планшете или смартфоне напихано технологий столько, что ИСС и не снилось. 
И это всё как-то работает

Во-первых, мне снилось. Во-вторых, вот именно что как-то .

Я с ходу могу назвать пару, которая не снилась ни ИСС, ни даже Вам. :)

А как работает... вот у меня смартфон тайваньской HTC более, чем 5-летней давности.
Сбоя, зависания, или ещё какого-нибудь глюка не было ни разу, при весьма интенсивном использовании не только в качестве телефона.
При том, что сложность ПО там никак не меньше сложности ПО ИСС.

ЦитироватьSOE пишет:

ЦитироватьEchidna пишет:
Даже при использовании процессоров 10-15 летней давности работа всего БПО наверняка занимает не больше 3-4 процентов процессорного времени

15-30%, на тех 6 разных весьма аппаратах, с которыми работал последние годы.
Что не мешает "вылезать" за пределы реального времени изредка, в ситуациях не протестированных в реалистичных условиях. Но это проблема разработки конкретного ПО, более-менее реальные проблемы по ресурсам вылезают редко (могу припомнить только ATV и Bepi) и они все же решаемы тоже.

30% уже конечно многовато. ЕМНИП, для систем с ОСРВ не более 10% должно быть. Ну на худой конец 15%. :-) На тех трех аппаратах для которых я делал ПО, мы не вылазили за 10% в самых нагруженных режимах. Но тут, конечно, все от задач зависит, которые возложены на БЦВМ.

ЦитироватьSGS_67 пишет:

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет:
развитием (бесплатных!) средств проектирования на основе С, да и вообще, GNU, для разнообразных платформ занимаются крупные международные сообщества, а не отдельные конторы

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

Приведите пример такого непотребства.

OpenSSH Heart Bleed.

ЦитироватьSGS_67 пишет:
ЗЫ. Если Вы ещё не поняли: современные средства разработки, приложения, библиотеки, драйвера сейчас можно найти в ИСХОДНИКАХ.
Тестировать, править и сопровождать самостоятельно, или с привлечением поддерживающих организаций, никто не запрещает.

Можно, только что вы будете делать с этими миллионами строк кода?

ЦитироватьSGS_67 пишет:
А как работает... вот у меня смартфон тайваньской HTC более, чем 5-летней давности.

Еще один мечтатель со смартфоном.

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

Добавлю свои пять копеек, почему подход ИСС по крайней мере разумен. При наличии в конторе сложившейся методологии разработки и тестирования (в данном случае на Модула-2) гораздо проще, надежнее и дешевле при переходе на новую аппаратную базу перерабатывать toolchain и адаптировать его к новым платформам, чем переписывать код. Тут ещё вот какой момент - если твои миллионы (как указано выше) строк кода покрыты программными (понятно, что в случае ИСС еще на платформе гоняют) тестами - то и критерий успешности перехода очень простой - проходят ли эти тесты или нет (при смене языка нужно и тесты скорее всего перерабатывать - и нет гарантии, что тут не наложатся ошибки), в общем случае другие ошибки в том же компиляторе уже не критичны. Приведу пару примеров из похожих ситуаций

• Математические расчеты. Большая часть кода в библиотеках (а он по прежнему тут вне конкуренции) написан на древнем как дерьмо мамонта Фортране IV/66. Если кто не в теме - это когда текст набивался на перфокартах шириной то ли в 40, то ли в 80 символов, комментарий начинался с буковки С, а о процедурном программировании мало кто слышал. Поддерживать такой код по нынешним временам невозможно - только его авторы могли разобраться в этих "макаронинах", но многие из них уже попросту умерли. Было несколько попыток автоматического трасформирования в тот же С - и все без толку. В моем понимании - garbage in - garbage out, если код на фортране нечитаем, то и полученный код на С (да и хоть на Java) таким же и останется. Но это не является проблемой - все нынешние компиляторы Фортрана без проблем поддерживают древние стандарты, с оптимизацией кода едва ли затруднения есть - для парсера нет разницы, удобен ли исходный текст для человека, все-равно все преобразуется в промежуточный формат AST. Сколько раз компиляторщики переходили (точнее, делали кодогенераторы) на новые платформы - страшно и подумать. И я так понимаю, каждый раз они просто прогоняли тесты на регрессии, и это вполне работало.
• Когда Facebook только начинался, писали его по быстрому на PHP. Опять-таки - если кто не в теме - язык ну ни разу не предназначенный для высоконагруженных систем. И они не стали переписывать все с нуля - а наняли очень толковых компиляторщиков (с их деньгами это было сделать легко), которые сделали им вначале HipHop-транслятор PHP->C++, а потом  и полноценный HipHop JIT компилятор. И тут они не сильно заморачивались общей поддержкой PHP, было достаточно, что работает на их собственной кодовой базе.
• Исторически JavaScript был простым скриптовым языком, созданным на заре интернета Netscape буквально на коленке, и не счесть попыток замены его на что-то более приличное. Но в итоге в 2008 году Google сделал JIT компилятор V8, быстро после этого подтянулись Mozilla, Microsoft и Apple. То бишь снова оказалось проще toolchain улучшить.
  

Собственно, ровно то же самое сделал ИСС в 2000-2003 году (как уже Not упоминал в рамках договора  №109, (кросс-система программирования на языке Модула-2 для OBC-1750 (с участием ООО "Эксельсиор" )) , да и где гарантия, что они потом просто не прикрутили к GCC кодогенератор для OBC-1750 и перешли на GNU Modula-2? Кстати в этом случае спор совсем становится схоластическим, это просто дискуссия gcc vs GCC.

И еще замечание про кросс-компиляцию. Если транслятор Modula-2->Ansi C дает код, что удовлетворяет требованиям на скорость исполнения в Real-Time - то ИСС можно было дальше и не улучшать ничего. Опять-таки, такие трансляции не так уж и безнадежны, транслятор С->Asm.js по оценкам Мозиллы работает всего в два раза медленнее родного кода - а тут ведь пусть и подмножество, но все-равно JavaScript.

ЦитироватьNot пишет:
OpenSSH Heart Bleed.

Очень хороший пример того, какие баги могут всплыть в НЕПОДДЕРЖИВАЕМОМ проекте. Ну и OpenSSL, а не OpenSSH...  На момент появления бага в кодовой базе, в проекте было всего 2 человека на полной занятости, да и то, они занимались не развитием кода, а зарабатыванием денег на поддержание инфраструктуры. Ревью пулреквестов не делалось, и банальная непроверка входных параметров, пропущенная студентом (без шуток, код был написан студентом), привела к компрометированию многих серверов.

Не соглашусь с теми, кто говорит, что ИСС поступает верно, оставаясь на модуле. Я не в курсе полной ситуации на рынке ПО для спутников, но то, что я видел/слышал/щупал/писал - это С. Если ИСС останется единственным, кто будет использовать Модулу и ее инфраструктуру, то они рискую вляпаться в неприятные ситуации. Например когда все знающие уйдут, а новые, посмотрев на код, не захотят работать. Или когда ошибки будут возникать из ниоткуда (просто когда никому в голову не приходит, что что-то может пойти по-другому). Еще и скорость разработки и качество машинного кода будут падать по сравнению с конкурентами. Ведь мир С не стоит на месте, а вот ИСС замерло.
Теперь к примерам от dmitryskey (http://novosti-kosmonavtiki.ru/forum/user/18268/). Тут не совсем верна интерпретация.
Про мат либы. Тут самая обычная проблема легаси кода. Есть много библиотек, много людей, которые с ними работали. Чтобы переписать это все на С, нужно очень много времени, потом нужно избавиться от детских болезней, заняться оптимизацией алгоритмов, написать кучу документации, переобучить народ. Поэтому это все идет, но очень медленно. Опять же тут играет роль еще и фактор смены вычислительной платформы (ГПУ и ускорители типа Xeon Phi). Так что со временем все либы на фортране вымрут.
Про фейсбук. Ситуация была такой. Сайт "выстрелил". В этот момент нужно иметь возможность очень быстро скалировать производительной горизонтально (больше серверов). Если в этот момент начать все переписывать - то проще закрыть проект сразу. Поэтому написание HipHop в данных условия выглядит абсолютно разумно. Ну и пхп не стоит на месте. В 7ой версии он уже не вызывает рвотных рефлексов.
Про JavaScript. Тут в корне не верно толкование. Изначально язык создался за несколько часов (кроме шуток, на самом деле), чтобы не допустить внедрения VisualBasic в качестве стандартного языка для скриптов на страницах. Много позже, когда страницы уже не были статическим текстом, возникла потребность заменить интерпретируемые скрипты на что-нить более быстрое. Это можно было сделать через внешнюю зависимость (Java Applets) или внутреннюю, когда скрипты компилировались браузером (V  8)  , тогда привычный язык программирования можно не заменять. Второй вариант вышел победителем.

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

По поводу умирания Фортрана забавная история есть. У бывшей начальницы в LA муж Фред работал программистом предпенсионного возраста на Фортране в HP. Лет десять назад им сказали примерно так - давайте мы вас уволим с золотым парашютом. Тут дело в том, что просто просидев в конторе много лет, деды эти охрененно большую зарплату получали просто за счет выслуги лет. Фред подумал и согласился - а где-то через полгода ему позвонили и предложили тем же самым снова заниматься - но по контракту. А Фреду что за беда - мед.страховка у жены его покрывала, да и дело шло к пенсии и Medicaid, ипотека выплачена - т.е. ему от преимуществ постоянного трудоустройства ни холодно, ни жарко, а золотой парашют остался.

С Фортраном вот еще что нужно иметь в виду. CUDA/OpenCL/Phi требуют высокой параллельности алгоритмов, коих не так много, и явно соответствующие вещи были давно уже были переписаны с древнего Фортрана еще на многопотоковые библиотеки типа MPI для запуска на тех же суперкомпьютерах. Не параллелизуемые вещи так себе и сидят в старом коде - и я не представляю себе, кто и зачем будет это переписывать.

ЦитироватьRubbiroid пишет:

Про мат либы. Тут самая обычная проблема легаси кода. Есть много библиотек, много людей, которые с ними работали. Чтобы переписать это все на С, нужно очень много времени, потом нужно избавиться от детских болезней, заняться оптимизацией алгоритмов, написать кучу документации, переобучить народ. Поэтому это все идет, но очень медленно. Опять же тут играет роль еще и фактор смены вычислительной платформы (ГПУ и ускорители типа Xeon Phi). Так что со временем все либы на фортране вымрут.

Вы про Фортран-2015 слышали?

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

Фортранщики могут поправить, но насколько я знаю, строго говоря для Фортрана гораздо лучше работает автовекторизация - на чем в свое время и взлетел Cray-1, они выдали векторную машину с очень приличной обычной производительностью и Cray Fortran, что делал эффективную автовекторизацию. Т.е. всякие ядерщики просто перекомпилировали свои библиотеки и немедленно получали прирост производительности. Для распараллеливания вроде бы MPI так и используется (понятно, что в более или менее современных диалектах).

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

По поводу С - по крайнем мере мой опыт с AVX не позволяет полагаться на автовекторизацию, приходится ручками пользоваться векторными расширениями gcc/clang. Удовольствия в этом, прям скажем, мало.

ЦитироватьRubbiroid пишет:
Не соглашусь с теми, кто говорит, что ИСС поступает верно, оставаясь на модуле. Я не в курсе полной ситуации на рынке ПО для спутников, но то, что я видел/слышал/щупал/писал - это С. Если ИСС останется единственным, кто будет использовать Модулу и ее инфраструктуру, то они рискую вляпаться в неприятные ситуации. Например когда все знающие уйдут, а новые, посмотрев на код, не захотят работать. Или когда ошибки будут возникать из ниоткуда (просто когда никому в голову не приходит, что что-то может пойти по-другому). Еще и скорость разработки и качество машинного кода будут падать по сравнению с конкурентами. Ведь мир С не стоит на месте, а вот ИСС замерло.

1. Иногда бывает, что один прав, а большинство - заблуждается. По сути, гораздо правильнее использовать Модулу-2, нежели Си, при создании критически важных приложений. Весь мир "не стоит на месте", возможно, по пути к пропасти? ) 

2. "Все знающие уйдут" и подобные рассуждения от SGS. Все же Вы не в темевполне осознаете специфику. Технология создания бортового программного обеспечения - предмет, далеко не сводящийся к используемому языку программирования. В том же ИСС используется огромное число специфических инструментов для поддержки различных сторон их технологии. То есть приходящему на работу (кстати, не следует также забывать, что Железногорск - ЗАТО, и вопросы трудоустройства/переездов носят специфический характер) в любом случае приходится очень много чего нового изучать.

3. Повторю. Ничего, повторение - мать учения. Особенности разработанной и тщательно выверенной технологии создания БПО позволили ИСС повысить скорость разработки. А качество БПО такого, что ни разу ни на одном из десятков аппаратов не было критического отказа по причине БПО. Более того - особенности организации БПО позволяли неоднократно компенсировать иные виды отказов и сохранять работоспособность дорогостоящих и важных для обороноспособности страны изделий.

Да, и кстати. Я лично в ИСС не работаю  ;)

На днях с одним приятелем пересеклись. Вернулся на днях из Нью-Йорка. Рассказал интересную историю

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

Так что идеология ИСС в области автономности ПО от мейнстрима процветает и на Западе ;)

Цитироватьsychbird пишет:
Так что идеология ИСС в области автономности ПО от мейнстрима процветает и на Западе  ;)

Еще как процветает. Кобол времен динозавров исключительно востребован. Более того, старые отлаженные пакеты весьма ценятся по одной простой причине - переписать с той же функциональностью в США обойдется очень дорого, в Индии получится не слишком надежно. Если учесть, что вышеупомянутые приложения работают на мейнфреймах, в которых в отличие от писюков обеспечивается обратная совместимость на десятки лет назад (собственно одна из причин почему они настолько живучи), то никому и в голову не приходит их переделывать. Сопровождать (править ошибки, дорабатывать) - безусловно. 

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

Могу про нашу контору рассказать. Самое первое клиент-серверное приложение в 90-их вначале писалось на FoxPro, потом в GUI на Дельфи - т.е. пусть на бестолковом, но вполне себе кузене Модулы-2. Потихоньку приложение поддерживается, пару лет назад был большой в плане тестирования проект по переходу с BDE на FireDAC для поддержки современных баз данных. Так тестировщикам он больше текущей версии понравилось, работает быстро, функционала даже больше.

Так вот, недавно с изумлением узнал, что Гугл (наш давний клиент) именно это версию используют. HR народ консервативный, я так думаю, им просто сделали виртуальную машину, они и работают как им удобно.

Кстати, SpaceX тоже наш клиент, но, само собой, на платформе SaaS, они просто позже Гугла возникли

ЦитироватьNot пишет:
Фортран распараллеливается значительно лучше чем С

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

ЦитироватьTAU пишет:
По сути, гораздо правильнее использовать Модулу-2, нежели Си, при создании критически важных приложений.

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

По пункту 2. Каким образом закрытость города, особенность технологий и прочие факты способствуют притоку свежих кадров? А если нет притока/приемствеености кадров - то рано или поздно проект погибнет.

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

Ни разу не было != гарантированно не будет. Я вот тоже ни разу не попадал под машину, когда переходил дорогу. Ведь я смотрю по сторонам. Вот только никто не говорит, что со мной такого никогда не случится. И в моем понимании "закрытость" технологии только способствует такому. Ну и общий вопрос. Каким образом "качество ПО" может повлиять на возможность парирования ошибок других систем? Я вот думаю, что хорошие и гибкие алгоритмы могут. А на каком языке они записаны - так это не играет никакой роли.

Цитироватьsychbird пишет:
Заказчики из банковской и биржевой среды. Для них тоже крайне важна надежность ПО. Программы под НР за десятилетия отлажены иработают и никто их не собирается переписывать.

Банковская система США в данном случаи очень плохой пример, ибо она технологически отсталая в сравнении в российской или европейской. Когда не нужно ничего менять, то дешевле поддерживать старое, чем переписывать на что-то новое.

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

На самом деле, в мало-мальски разумной конторе всегда играются с технологиями, у нас, к примеру, и на Go активно пишут, и микросервисы на NodeJS, и MongoDB крутится наравне с основной реляционной базой данных. И я охотно верю, что какой-нибудь UI для наземных испытаний на том же NodeJS может быть написан, Модула-2 едва ли хорошие библиотеки для современного GUI и веба имеет. Нужно просто различать mission-critical components и всякие побочные вещи.

Как пример. Исторически были у нас некие скрипты выкладки и обновления, написанные на Batch+VBS. Надоело до смерти - поддерживать тяжело очень, полгода назад плюнули и переписали на Python (ну и где очень специфические вещи типа установки сертификатов под Windows - на PowerShell). В итоге расшили узкое место - теперь читаются и правятся легко скрипты всеми членами команды. Но есть два момента - админы и люди, отвечающие за билды, кричали, что им это и даром не нать - пришлось ткнуть в корпоративную Policy по переходу на OSS. Второе - это не само приложение, с ним никто бы не позволил технологию менять.

По поводу новых вещей типа Rust, Go да и Swift (он теперь не только на iOS доступен). Нужно задаться вопросом - если есть универсальные комбайны С++, Java да и C# с новой политикой MS - для чего Mozilla изобрела Rust, Google Go и Apple Swift. И как ни странно - это еще один аргумент в копилку ИСС с его Modula-2. Все это внутренние средства разработки компаний, выпущенные в OpenSource и заточенные под внутренние цели. Вся разница, что ИСС не стала придумывать новый язык. Про Go скажу вполне уверенно - его ниша - это сетевые утилиты и микросервисы, как универсальному языку ему не хватает библиотек. Гугл делает в первую очередь то, что ему нужно, а брать левые библиотеки с непонятным качеством и поддержкой для production ну никак не стоит.

ЦитироватьRubbiroid пишет:  Ну и общий вопрос. Каким образом "качество ПО" может повлиять на возможность парирования ошибок других систем? Я вот думаю, что хорошие и гибкие алгоритмы могут. А на каком языке они записаны - так это не играет никакой роли

Когда я говорю о "качестве БПО", я имею в виду в целом, как оно спроектировано (тщательно и специально с учетом возможности при необходимости парирования отказов аппаратуры), и, естественно, программно-алгоритмическое обеспечение. И еще раз - технология разработки БПО в ИСС - отнюдь не одна отдельно взятая Модула.

Вообще, в космической области есть некоторая тенденция отделения алгоритмов от текстов программ. Сами алгоритмы при этом можно описывать, например, графическим языком. Можно посмотреть те же технологии ГРАФИТ-ФЛОКС, SCADE, TASTE, Grafet или МОКБ "Марс"...

Кстати, подумалось. Вот делают ИСС спутники, используя русский язык, Thales - явно французский, про китайцев и подумать страшно со всеми их диалектами, друг-другу то непонятными :-). Явно языки не mainstream - ибо не английский. И что - качество работы этим определяется?

Все языки, что мы упоминали - полные по Тьюрингу и эквивалентные Тьюринговой машине :-)

ЦитироватьEchidna пишет:
30% уже конечно многовато. ЕМНИП, для систем с ОСРВ не более 10% должно быть. Ну на худой конец 15%.

Это не так.
Как раз ОСРВ и нужны для того, чтобы производительность платформы использовать по максимуму, без падений и подвисаний.
МСМ, 70-80%, загрузки - вполне нормальный показатель, при условии достаточной квалификации создателей ПО под ОСРВ.
Другое дело, что при его достижении вполне стоит подумать о разработке железа с бОльшими ресурсами по части быстродействия.

ЦитироватьRubbiroid пишет:

ЦитироватьNot пишет:
Фортран распараллеливается значительно лучше чем С

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

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

ЦитироватьNot пишет:

ЦитироватьSGS_67 пишет:

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет:
развитием (бесплатных!) средств проектирования на основе С, да и вообще, GNU, для разнообразных платформ занимаются крупные международные сообщества, а не отдельные конторы

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

Приведите пример такого непотребства.

OpenSSH Heart Bleed.

:o  
Какое отношение имеет Heartbleed к OpenSSH?
И, в особенности, какое он имеет отношение к средствам проектирования ПО??
Уважаемый, прежде, чем написать следующую бредятину, хорошо подумайте о жизни и о своём месте в ней.

Цитировать

ЦитироватьSGS_67 пишет: 
ЗЫ. Если Вы ещё не поняли: современные средства разработки, приложения, библиотеки, драйвера сейчас можно найти в ИСХОДНИКАХ.
Тестировать, править и сопровождать самостоятельно, или с привлечением поддерживающих организаций, никто не запрещает.

Можно, только что вы будете делать с этими миллионами строк кода? 

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

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

Совершенно пересекающиеся.
(Тоскливо глядя на ПО Фобосов, в т.ч.,и Грунта).
Прежде, чем судить о надёжности, попробуйте её обеспечить хотя бы в своём курятнике, а дотоле не суйте нос туда, где вы ни ухом, ни рылом.

Цитироватьdmitryskey пишет:
Добавлю свои пять копеек, почему подход ИСС по крайней мере разумен. При наличии в конторе сложившейся методологии разработки и тестирования (в данном случае на Модула-2) гораздо проще, надежнее и дешевле при переходе на новую аппаратную базу перерабатывать toolchain и адаптировать его к новым платформам, чем переписывать код.

Попробуйте поставить себя на место специалиста ИСС, и ответить на простой вопрос: где брать ОС для новой платформы, типа Леона, и как её поддерживать при помощи Модулы-2 ?

Цитироватьdmitryskey пишет:
 Математические расчеты. Большая часть кода в библиотеках (а он по прежнему тут вне конкуренции) написан на древнем как дерьмо мамонта Фортране IV/66...

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

ЦитироватьИсторически JavaScript был простым скриптовым языком, созданным на заре интернета Netscape буквально на коленке, и не счесть попыток замены его на что-то более приличное. Но в итоге в 2008 году Google сделал JIT компилятор V8, быстро после этого подтянулись Mozilla, Microsoft и Apple. То бишь снова оказалось проще toolchain улучшить...

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

ЦитироватьСобственно, ровно то же самое сделал ИСС в 2000-2003 году (как уже Not упоминал в рамках договора №109, (кросс-система программирования на языке Модула-2 для OBC-1750 (с участием ООО "Эксельсиор" )) , да и где гарантия, что они потом просто не прикрутили к GCC кодогенератор для OBC-1750 и перешли на GNU Modula-2?

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

ЦитироватьИ еще замечание про кросс-компиляцию. Если транслятор Modula-2->Ansi C дает код, что удовлетворяет требованиям на скорость исполнения в Real-Time - то ИСС можно было дальше и не улучшать ничего.

В таком случае, почему бы им не перетащить на ANSI C все свои исходники, чтобы потом не мучаться с созданием кросс-систем для каждой новой аппаратной платформы?

ЦитироватьTAU пишет: 
1. Иногда бывает, что один прав, а большинство - заблуждается. По сути, гораздо правильнее использовать Модулу-2, нежели Си, при создании критически важных приложений. Весь мир "не стоит на месте", возможно, по пути к пропасти? )

Ну, так саблю наголо, и с криками "банзай" - вперёд.
Вопрос только: за чей счёт банкет?
Спутники нужны не только ИСС, а оплачивать издержки таких джедайских методов из гос. кармана согласны далеко не все, кто своим трудом его наполняет.

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

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

ЦитироватьВ том же ИСС используется огромное число специфических инструментов для поддержки различных сторон их технологии.

Коль скоро Вы в теме, опишите, пожалуйста, в двух словах хоть парочку специфических именно для ИСС инструментов поддержки их неповторимой технологии создания ПО.

Цитировать То есть приходящему на работу (кстати, не следует также забывать, что Железногорск - ЗАТО, и вопросы трудоустройства/переездов носят специфический характер) в любом случае приходится очень много чего нового изучать. 

Иными словами, приходящему в ИСС предлагают подписать договор о продаже души и тела без возможности его расторжения, верно?

Цитировать3. Повторю. Ничего, повторение - мать учения. Особенности разработанной и тщательно выверенной технологии создания БПО позволили ИСС повысить скорость разработки.

Нда?
А вот мне, судя по контрактам, показалось, что только на создание кросс-системы для каждой новой платформы уходит в среднем 3 года.
Разубедите, пожалуйста, или скажите тогда, что Вы понимаете под "повышением скорости разработки"?

ЦитироватьSGS_67 пишет:

ЦитироватьEchidna пишет:
30% уже конечно многовато. ЕМНИП, для систем с ОСРВ не более 10% должно быть. Ну на худой конец 15%.

Это не так.
Как раз ОСРВ и нужны для того, чтобы производительность платформы использовать по максимуму, без падений и подвисаний.
МСМ, 70-80%, загрузки - вполне нормальный показатель, при условии достаточной квалификации создателей ПО под ОСРВ.
Другое дело, что при его достижении вполне стоит подумать о разработке железа с бОльшими ресурсами по части быстродействия.

Не совсем корректное утверждение. ОСРВ не дает максимальной производительности в среднем - а гарантирует время отклика. Условно говоря, если исполняющий механизм на реакторе или двигателе отрабатывает за 10мс в силу чисто механических ограничений, это дает верхнюю оценку времени реакции софта. Выходит за нее ни в коем случае нельзя во избежании условного Чернобыля (по этой причине стандартные ОС просто нельзя использовать в таких условиях), сильно быстрее делать смысла большого нет. Но на практике даже на ОСРВ программное обеспечение уровня user-space стараются писать с загрузкой вроде вышеуказанной - береженого Бог бережет, да и зачастую очень сложно и дорого прорисовать граф исполнения и сделать максимальные оценки. Или же эти оценки дают в сумме больше 50% загрузки CPU (что при реальном исполнении не происходит), вот и делают все с запасом.

Чисто технологически, по крайней мере классические ОСРВ вроде QNX, VxWorks или Minix делаются на основе микроядра и наборов сервисов в слое user-space. Постоянный обмен сообщениями приводит к потерям в 15-35% при системных вызовах за из-за неизбежно возникающего overhead при проверках форматов и проч. Ну и до кучи читаем классическую переписку Грозного-Курбского в виде дискуссии Танембаума и Торвальда. Linux вполне себе монолитное ядро, уж точно не заточенное на гарантированное время отклика. Есть расширения типа RTLinux - про него не знаю, также как и не знаю, как SpaceX решает эту задачу. Зная их подход - они вполне могли и просто делать запас по ресурсам системы - а не бодаться с жестким Real-Time, это дело дорогое.

Изначально микроядерные Windows NT и Mac OS X достаточно быстро промутировали в т.н. гибридные ядра - когда есть микроядро - на над ним много монолитного кода. В основном, это связано с тем, что больше половины кода ядра состоит из драйверов и их реально тяжело разбить на сравнительно мелкие сервисы в духе Minix. Linux просто не заморачивается в силу доступности исходников - ядро одним кусков собирается (плюс компилируются подгружаемые модули)

Цитироватьdmitryskey пишет:

ЦитироватьSGS_67 пишет:
Это не так.
Как раз ОСРВ и нужны для того, чтобы производительность платформы использовать по максимуму, без падений и подвисаний.

Не совсем корректное утверждение. ОСРВ не дает максимальной производительности в среднем - а гарантирует время отклика.

Ключевые слова выделил.

А так, конечно, ОСРВ имеет бОльшие накладные расходы, чем, скажем, "кооперативная" ОС, зато гарантирует стабильное исполнение критически значимых процессов, даже при наличии ошибок в остальных секциях кода.

ЦитироватьНо на практике даже на ОСРВ программное обеспечение уровня user-space стараются писать с загрузкой вроде вышеуказанной - береженого Бог бережет, да и зачастую очень сложно и дорого прорисовать граф исполнения и сделать максимальные оценки. Или же эти оценки дают в сумме больше 50% загрузки CPU (что при реальном исполнении не происходит), вот и делают все с запасом.

Это может говорить лишь о невысокой культуре создания ПО.

В целом, написание софта под ОСРВ требует чёткого понимания её функционирования, и владения приёмами создания "хороших" алгоритмов обработки данных. Т.е., достаточно высокой квалификации программиста.
При соблюдении этих условий, никаких особых "запасов" не требуется.

ЗЫ. Так что насчёт ОС для Леона?

Врать не буду, просто не знаю. Разумеется, при выборе процессора желательна поддержка тем же Линуксом.

Мы, кстати, много обсуждали разработки на Модуле-2. А какая операционка в аппаратах ИСС используется? Или код просто напрямую прошивается и запускается из bios/monitor/etc.

И может, кто просветит, что на сей счет американская военщина использует на том же F-35?

P.S. Википедия, конечно, это моветон, железячники должны авторитетно рассказать. Но по поводу Леона все выглядит очень прилично - разработан ESA, ISA Sparc-V8 (а по нему компетенции очень неплохие в России - давно уже рабочие станции делают на МЦСТ R-500/1000 c Spark-V9, причем частью процессоры в России производятся), лицензия хоть GPL, хоть коммерческая

LEON is a 32-bit CPU microprocessor core, based on the SPARC-V8 RISC architecture and instruction set. It was originally designed by the European Space Research and Technology Centre (ESTEC), part of the European Space Agency (ESA), and after that by Gaisler Research. It is described in synthesizable VHDL. LEON has a dual license model: An LGPL/GPL FLOSS license that can be used without licensing fee, or a proprietary license that can be purchased for integration in a proprietary product. The core is configurable through VHDL generics, and is used in system-on-a-chip (SOC) designs both in research and commercial settings.


Как обычный Sparс поддерживается кучей OC, включая Real-Time

The Real-time operating systems that support the LEON core are currently RTLinux, PikeOS, eCos, RTEMS, Nucleus, ThreadX, OpenComRTOS, VxWorks (as per a port by Gaisler Research), LynxOS (also per a port by Gaisler Research), POK (a free ARINC653 implementation released under the BSD licence) and ORK+ an open-source real-time kernel for high-integrity real-time applications with the Ravenscar Profile.

ЦитироватьSGS_67 пишет:
Попробуйте поставить себя на место специалиста ИСС, и ответить на простой вопрос: где брать ОС для новой платформы, типа Леона, и как её поддерживать при помощи Модулы-2 ?

Я может что то пропустил, но почему ИСС что то должно сделать для Леона?

Цитироватьthunder26 пишет:
Я может что то пропустил, но почему ИСС что то должно сделать для Леона?

Действительно, корректнее вместо "типа Леона" употреблять сочетание "процессор с архитектурой SPARC V8"; это было сделано ради краткости.
Итак, где предполагается брать ОС для данного процессора, и каким образом осуществлять её поддержку?

Цитироватьdmitryskey пишет:
Врать не буду, просто не знаю. Разумеется, при выборе процессора желательна поддержка тем же Линуксом.

Мы, кстати, много обсуждали разработки на Модуле-2. А какая операционка в аппаратах ИСС используется? Или код просто напрямую прошивается и запускается из bios/monitor/etc.

Чего-чего?
К Вам аналогичный вопрос: предложите ОС для Леона, которую можно было бы поддерживать при помощи Модулы-2.

ЦитироватьSGS_67 пишет:
Итак, где предполагается брать ОС для данного процессора, и каким образом осуществлять её поддержку?

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

Я, право, несколько смущен и запутан. Modula-2 НЕ является языком системного программирования, т.е. с таким же успехом можно спросить, где мы собираемся брать и поддерживать ОС при разработке на Java или, прости Господи, JS/NodeJS.

Помимо перечисленных выше ОСРВ (кои применимы к именно к ситуации ИСС), Sparc V8 (это 32-битная архитектура, для embedded systems 64-битные архитектуры избыточны) поддерживаются (навскидку) следующими ОС

[/li]
• Solaris
• Linux
• FreeBSD
• OpenBSD
• NetBSD
  

В качестве средств разработки для Solaris идут компиляторы С от Oracle, Linux & NetBSD/OpenBSD GNU/gcc, FreeBSD LLVM/clang или GNU/gcc.

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

ЦитироватьNot пишет:
Ну, распараллелить можно только алгоритм, а не язык,

ЦитироватьNot пишет:
Анализировать фортрановскую программу значительно проще

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

Ну все-таки не стоит смешивать векторизацию и параллелизм (кому интересно, почитайте историю взаимоотношений CDC 8600 и Cray-1). Векторизация - это применение одной и той же операции к вектору данных, параллелизм - исполнение кода (вообще говоря, необязательно разного) в несколько потоков. Есть языки, хорошо приспособленные к автовекторизации вроде Фортрана, "чистые" функциональные языки по крайней мере в теории легко допускают параллельное исполнение (правда, накладные расходы на вызовы функций, передачу данных и запредельная сложность программирования именно численных расчетов выводит их за рамки нашей дискуссии).

В векторных расширениях gcc/clang и OpenCL, безусловно, помечаешь данные как векторные (или используешь предопределенные - пишешь что-то вроде int 8)  - и потом применяешь одну операцию. Но инициализация векторов и чтение из них данных пишется достаточно специфическим образом, код зависит уже от расширения. В общем - простого покрытие атрибутами в С не происходит. 

Цитироватьdmitryskey пишет:


И может, кто просветит, что на сей счет американская военщина использует на том же F-35?

У них своя кухня.
http://www.ghs.com/AerospaceDefense.html

Цитироватьbsdv пишет:

Цитироватьdmitryskey пишет:


И может, кто просветит, что на сей счет американская военщина использует на том же F-35?

У них своя кухня, очень специфичная...
 http://www.ghs.com/AerospaceDefense.html
http://www.ddci.com/products_deos/

И на Аде пишут, и С не брезгуют...
Но там все завязано на сертификацию летной годности. Естесственно никакого опен сорс....

Цитироватьthunder26 пишет:

ЦитироватьSGS_67 пишет:
Итак, где предполагается брать ОС для данного процессора, и каким образом осуществлять её поддержку?

Вроде в первом сообщении темы написано, не?

Писать врукопашную на Модуле, чтоль??

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

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

Цитироватьdmitryskey пишет:
Я, право, несколько смущен и запутан. Modula-2 НЕ является языком системного программирования, т.е. с таким же успехом можно спросить, где мы собираемся брать и поддерживать ОС при разработке на Java или, прости Господи, JS/NodeJS.

Вот именно.
Тогда поясните, какой средой должны, по Вашему разумению, пользоваться системные программисты ИСС?

ЦитироватьПомимо перечисленных выше ОСРВ (кои применимы к именно к ситуации ИСС), Sparc V8 (это 32-битная архитектура, для embedded systems 64-битные архитектуры избыточны) поддерживаются (навскидку) следующими ОС

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

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

Мне, например, понятно, почему Леон (а, с вероятностью, близкой к 100%, речь идёт именно о нём) может представлять интерес для ИСС.
А с Вашей точки зрения, почему выбор устаревшей SPARC-based архитектуры является очень разумным подходом?

Цитироватьbsdv пишет:

Цитироватьbsdv пишет:

Цитироватьdmitryskey пишет:


И может, кто просветит, что на сей счет американская военщина использует на том же F-35?

У них своя кухня, очень специфичная...
 http://www.ghs.com/AerospaceDefense.html
 http://www.ddci.com/products_deos/

И на Аде пишут, и С не брезгуют...
Но там все завязано на сертификацию летной годности. Естесственно никакого опен сорс....

Спасибо большое, очень занятно! Интересно, как регламентируется использование Ады, все-таки больше 30 лет просто с того знаменитого конкурса Минобороны. Да и с тех времён язык очень сильно вперёд ушёл.

ЦитироватьSGS_67 пишет:

Цитироватьdmitryskey пишет:
Я, право, несколько смущен и запутан. Modula-2 НЕ является языком системного программирования, т.е. с таким же успехом можно спросить, где мы собираемся брать и поддерживать ОС при разработке на Java или, прости Господи, JS/NodeJS.

Вот именно.
Тогда поясните, какой средой должны, по Вашему разумению, пользоваться системные программисты ИСС?

ЦитироватьПомимо перечисленных выше ОСРВ (кои применимы к именно к ситуации ИСС), Sparc V8 (это 32-битная архитектура, для embedded systems 64-битные архитектуры избыточны) поддерживаются (навскидку) следующими ОС

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

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

Мне, например, понятно, почему Леон (а, с вероятностью, близкой к 100%, речь идёт именно о нём) может представлять интерес для ИСС.
А с Вашей точки зрения, почему выбор устаревшей SPARC-based архитектуры является очень разумным подходом?

Возможно, что среда разработки своя - а нет, так тогда все можно сделать так же, как и для Вашего HTC - берем сертифицированный Linux (можно взять ОС МСВС, хоть на x86/x64, хоть на Sparc), Eclipse с соответствующим модулем или просто Vim/Emacs для любителей консоли, GNU Modula-2/GDB (вместо Android SDK) - и вперед, пишем код, тестируем на эмуляторе (понятно, что никто не станет на реальном железе разработку вести). Потом пересобираем при помощи кросс-компиляции (и вышеуказанный договор о разработке вполне мог касаться именно его), прогоняем некий набор тестов - и вперед, на стенд к реальному аппарату.

По архитектурам. 10 лет назад на ужине в Бостоне (оплаченном, кстати, Гуглом) инженер Intel и Broadcom донес до меня следующую мысль. После бурных войн 80-90 архитектуры ушли каждая в свои ниши.

• x86/x64 - максимально возможная общая производительность, максимальная поддержка со стороны ПО.
• ARM - гибкое лицензирование, максимальная производительность на ватт мощности - поэтому и занял практически мобильную нишу
• MIPS - гибкое лицензирование, максимальная производительность на единицу стоимости. Как ни странно, по количеству CPU это самая распространенная архитектура - ставится в сетевые устройства.
• Sparc - открытое по GPL лицензирование, что в ряде случаев критично из соображений безопасности (не все же делать нелицензионный MIPS как китайцы)
• Power - максимальная производительность по float point (хотя понятно, что тут все меняется быстро), это своя архитектура IBM, она им важна для бизнес применений, до недавнего времени (до PS-4 и XBox One) практически все игровые консоли строились на этой архитектуре.
• s390 - как правильно писали - сквозная поддержка ПО для майнфреймов.
  

Единственная приходящая в голову действительно устаревшая архитектура - это IA-64. Причем она даже скорее не взлетела просто, так и не смогли написать достойные компиляторы для EPIC.

Цитироватьbsdv пишет:

Цитироватьbsdv пишет:

Цитироватьdmitryskey пишет:


И может, кто просветит, что на сей счет американская военщина использует на том же F-35?

У них своя кухня, очень специфичная...
 http://www.ghs.com/AerospaceDefense.html
 http://www.ddci.com/products_deos/

И на Аде пишут, и С не брезгуют...
Но там все завязано на сертификацию летной годности. Естесственно никакого опен сорс....

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

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

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


В качестве аналогии - психические заболевания человека. Шизофрения и т.п.

Цитироватьsychbird пишет:
По поводу F-35. Когда полный набор функциональности, запихнутый в один девайс, переходит некий порог по объему, наступает состояние принципиальной не полной стабильности набора функциональности в процессе производства .и интеграции его с ПО, а также и работы девайся. Вероятность ошибок при воспроизведения ПО и интерфейсов, аппаратных средств и прочей требухи становиться велика просто в силу их общего количества.


В качестве аналогии - психические заболевания человека. Шизофрения и т.п.

Полностью согласен. Самое обидное - что порог этот непонятно, как определять. В одно и то же время делали Saturn/Apollo и Valkyrie XB-70, причем во многом одни и те же люди и промышленность - результат абсолютно противоположный. Причем в первом случае - вроде как реальный скачок, во втором - достаточно поступательное движение.

P.S. Пример плохой оказался - почитал историю вопроса, XB-70 скорее стал жертвой Saturn/Apollo плюс поменялись требования и проект закрыли.

ЦитироватьSGS_67 пишет:

Цитироватьbsdv пишет:

Цитироватьbsdv пишет:

Цитироватьdmitryskey пишет:


И может, кто просветит, что на сей счет американская военщина использует на том же F-35?

У них своя кухня, очень специфичная...
 http://www.ghs.com/AerospaceDefense.html
 http://www.ddci.com/products_deos/

И на Аде пишут, и С не брезгуют...
Но там все завязано на сертификацию летной годности. Естесственно никакого опен сорс....

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

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

Попробуйте как нибудь побеседовать на тему современной авионики с пилотами. Думаю доброго слова вряд ли услышите... ))

ЦитироватьSGS_67 пишет: Вопрос только: за чей счёт банкет? Спутники нужны не только ИСС, а оплачивать издержки таких джедайских методов из гос. кармана согласны далеко не все, кто своим трудом его наполняет.

1. Методы ИСС как раз позволяют сократить средства на банкет.

Цитировать

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

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

3. С тобой, хамло и невежда, вообще вести дальнейшую дискуссию нет смысла. Ибо сказано: не мечите бисера своего...

ЦитироватьSGS_67 пишет: Тоскливо глядя на ПО Фобосов, в т.ч.,и Грунта
Прежде, чем судить о надёжности, попробуйте её обеспечить хотя бы в своём курятнике, а дотоле не суйте нос туда, где вы ни ухом, ни рылом.

Попробовал бы для начала повнимательнее разобраться в причинах потери Фобосов. В т.ч. Грунта.

Фобос-1 - ошибка оператора.
Фобос-2 - науке точная причина неизвестна
Фобос-Грунт - если можно говорить об ошибке, то в системной логике и в проекте в целом, а не в программном обеспечении, реализовавшем эту логику...

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

ЦитироватьFeol пишет:
У Фобос-2 было периодическое зависание вычислительных каналов. Вопрос состоял в том, когда зависнут два одновременно. В итоге это и произошло.

А при чем здесь программное обеспечение?

ЦитироватьTAU пишет:

ЦитироватьFeol пишет:
У Фобос-2 было периодическое зависание вычислительных каналов. Вопрос состоял в том, когда зависнут два одновременно. В итоге это и произошло.

А при чем здесь программное обеспечение?

При том что:

ЦитироватьTAU пишет: 
Фобос-2 - науке точная причина неизвестна

Цитироватьbsdv пишет: 
Попробуйте как нибудь побеседовать на тему современной авионики с пилотами. Думаю доброго слова вряд ли услышите... ))

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

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

Всем рулят народные массы :)

По этому, например, дискуссии о том, как ИСС ПО пишет, на чём его пишет, правильно оно его пишет или нет, выглядят забавно, когда их пытаются вести в технической плоскости. В реальности сложившаяся система имеет социальную основу, которая лишь приняла некое техническое обличие. Обсуждать это техническое обличие нет смысла, ибо оно оболочка, смена которой может в любой момент произойти мгновенно или не произойти никогда - в зависимости от социальных процессов в коллективе. Под социальной основой надо понимать то, что каждый в коллективе решает, в общем-то, свои личные задачи, которые не обязательно, не всегда, и даже чаще всего не заключаются на самом деле в предельной оптимизации разрабатываемого ПО, в оптимизации процесса его разработки, в оптимизации качества спутников или чего-то еще. Кто-то Модулу-2 не любит, кто-то на Си писать не хочет, кому-то ребёнка лечить надо, кто-то не может заставить штукатура нормально выровнять потолок. Сумма этого и есть социальная основа, которая открывает себя миру в виде технических и организационных решений. Обязательно нужно учитывать, что в социальном смысле у НПО ПМ значительная специфика. По отношению к другим отраслям нужно учитывать специфику производства спутниковых платформ, которое на текущем этапе весьма консервативно. Безотносительно этого и по отношению к другим предприятиям того же направления надо учитывать специфику истории и географического положения НПО ПМ. Расположение в России (уже достаточно  :)  ), в глубине Сибири (за Уралом население 15 млн. - пожалуй, меньше уже, чем в Москве охвачено метро..), в закрытом городе, построенном по приказу сверху с нуля в тайге, пережившим элитарный статус и высший уровень снабжения в советские времена, затем периоды угасания, положительных ростков, неопределённости и т. п. Постоянная дилемма между комфортной жизнью в городе при дефиците работы и наличием какой-никакой работы, но в грязным пыльном Красноярске. Желание перейти на другую интеллектуальную, квалифицированную работу нередко требует "большого" переезда на тысячи километров, на что не всем легко пойти без особых оснований. С чем-то разумнее смириться. И т. д. В итоге иной раз получается, что внешний наблюдатель, незнакомый с потрохами НПО ПМ, обозрев снаружи техническое обличие какого-то вопроса, фактически видит тайну, покрытую сракой мраком. Начинает критиковать покрытие с видимой ему технической стороны. В свою очередь, оппоненты из НПО ПМ просто живут этим вопросом. Так, что  уже не осознают это. Они видят, что имеет место наезд и из лучших побуждений начинают защищать себя и предприятие. При этом, не поняв суть происходящего, принимают правила игры зачинщика и начинают искать контр-аргументы в технической плоскости, которая не имеет отношения к вопросу. Естественно, что оппонент разбивает притянутое за уши. После этого спор переходит в драку.

Для внешних наблюдателей хочется отметить, что коллектив НПО ПМ реально очень специфичен. Он не плох и не хорош, он очень специфичен. Есть свои плюсы и минусы. Там слишком высокая концентрация умных людей. Это недостаток и я не шучу. Там очень много хороших людей. Это, ясное дело, плюс. Нужно просто держать в уме, общаясь с НПОшниками, что у них есть много внутренних ньюансов, которые вы не знаете, но можете столкнуться с их проявлением. Некоторые из них, на мой взгляд, вредны для дела, а некоторые полезны. Любой вопрос в НПО ни в коем случае не отделим от своей истории. Это часто важно, но в НПО ПМ это критически важно. Без этого невозможно понять логику, предсказать развитие и выбрать решение.

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

ЦитироватьFeol пишет:
дискуссии о том, как ИСС ПО пишет, на чём его пишет, правильно оно его пишет или нет, выглядят забавно, когда их пытаются вести в технической плоскости... 

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

Знаете, Feol, давайте все же отделим мух от котлет и оставим "социальные" вопросы за скобкамиза забором ЗАТО Железногорск.

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

Цитироватьdmitryskey пишет:

ЦитироватьSGS_67 пишет:
Мне, например, понятно, почему Леон (а, с вероятностью, близкой к 100%, речь идёт именно о нём) может представлять интерес для ИСС.
А с Вашей точки зрения, почему выбор устаревшей SPARC-based архитектуры является очень разумным подходом?

Возможно, что среда разработки своя - а нет, так тогда все можно сделать так же, как и для Вашего HTC - берем сертифицированный Linux

На моём HTC ведроид, и кем и почему он там сертифицирован, а, может, и вообще никем и ничем, меня колышет всего меньше, поскольку он работает на данном устройстве без сбоев и глюков, демонстрируя высокое качество исполнения аппарата и ПО.
Кстати, я слегка ошибся - One X вышел чуть менее 5 лет назад, но я его купил сразу после выпуска.

Ладно, скажите, ИСС действительно взял сертифицированный Линукс для Леона, или это просто предположение?

Цитировать(можно взять ОС МСВС, хоть на x86/x64, хоть на Sparc), Eclipse с соответствующим модулем или просто Vim/Emacs для любителей консоли, GNU Modula-2/GDB (вместо Android SDK) - и вперед, пишем код, тестируем на эмуляторе (понятно, что никто не станет на реальном железе разработку вести). Потом пересобираем при помощи кросс-компиляции (и вышеуказанный договор о разработке вполне мог касаться именно его), прогоняем некий набор тестов - и вперед, на стенд к реальному аппарату.

Простите, но этот набор слов не имеет никакого отношения к действительности.
Скажите, Вы и вправду считаете, что МСВС можно поддерживать при помощи GNU Modula-2?
И что МСВС вообще годится для задач ИСС?

ЦитироватьПо архитектурам.

Пожалуйста, не нужно больше ничего и никого цитировать.
Особенно специалистов Интел, процессоры которым сейчас проектирует АМД.
Речь идёт совсем о другом.

Цитироватьsychbird пишет:
По поводу F-35. Когда полный набор функциональности, запихнутый в один девайс, переходит некий порог по объему, наступает состояние принципиальной не полной стабильности набора функциональности в процессе производства .и интеграции его с ПО, а также и работы девайся.

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

Ибо современные средства и методы создания ПО позволяют поддерживать в работоспособном состоянии системы любого мыслимого (и даже немыслимого) уровня сложности.

ЦитироватьВ качестве аналогии - психические заболевания человека. Шизофрения и т.п.

Это верно, только не в качестве аналогии, а в прямом смысле.
   :D

Цитироватьdmitryskey пишет: 
Полностью согласен. Самое обидное - что порог этот непонятно, как определять.

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

ЦитироватьВ одно и то же время делали Saturn/Apollo и Valkyrie XB-70, причем во многом одни и те же люди и промышленность - результат абсолютно противоположный.

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

ЦитироватьP.S. Пример плохой оказался - почитал историю вопроса....

Ну вот, уже лучше...

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет: Вопрос только: за чей счёт банкет? Спутники нужны не только ИСС, а оплачивать издержки таких джедайских методов из гос. кармана согласны далеко не все, кто своим трудом его наполняет.

1. Методы ИСС как раз позволяют сократить средства на банкет.

Эта мантра проскакивала здесь много раз, однакоже, хотелось бы достать до её сущности.

Цитировать

Цитировать

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

2. Ну-ну. Так и хочется послать учить матчасть...

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

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

Ну, давайте про материалы, что ж кокетничать.

Цитировать3. С тобой, хамло и невежда, вообще вести дальнейшую дискуссию нет смысла. Ибо сказано: не мечите бисера своего...

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

В соседней ветке SOE дал очень интересную ссылку, где коротко и доходчиво про подход TAS-1, см http://www.adacore.com/press/ada-on-board-gnat-pro-helps-exomars-get-to-the-red-planet/

Т.е. Thales Alenia Space используют Аду с компилятором GNAT Pro, LEON2 и самописную RT OS.

C учетом вышеуказанного по F-35 можно сделать вывод, что подход ИСС вполне себе в духе работы других аэрокосмических фирм, все работают со своим букетом технологий. Как они сложились - тут прав  Feol, это вопрос уже скорее исторический.

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

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

https://geektimes.ru/post/180697/

 
Почему я не верю в отечественный космос — взгляд изнутри 

Уже несколько лет я работаю программистом на одном из предприятий РосКосмоса — ФГУП ХХХХХ и в этом посте мне бы хотелось поделиться своими впечатлениями об этой организации.

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

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

1) Для расчета тепловыделения на платах взять специалиста по теплотехнике зданий.
2) Разослать в подразделения информацию о повышении квалификации для выбора конкретных курсов, получить выбранные курсы и... PROFIT заключить договора на другие курсы. В том числе на те, для которых у отправляемых не было необходимых начальных знаний.

Так же отдел кадров подозревает о существовании сайтов для поиска работы, но почему-то брезгует ими пользоваться. Поэтому вакансии можно найти только на сайте предприятия. 
Второй способ получения свежей крови — студенты. Студенты прибывают на практику по приказам сверху, и никого не волнует, что, возможно, их нечем занять. У меня в ВУЗе надо было довольно подробно отчитываться о проделанной работе, происходила мини-защита, но это скорее исключение из правил. Итог практики многих студентов — отхоженные дни и всё. Если студент ходит один-два дня в неделю, то считается, что ему нельзя ничего поручить, хотя, учитывая общую заторможенность всех процессов на предприятии, это оптимальное число дней для посещения, чтобы не спать на работе. При этом если студенту все-таки дали задание, а он пинает болты, то сделать с ним ничего не возможно т.к. его прислали по договоренности с институтом. Естественно, отсидев положенный срок, студент сваливает далеко и навсегда. Студентам платят в зависимости от способностей, но в общем мало.

Круглое носить, квадратное катить
Что общего у флэшки, мобильного телефона, гитары и проигрывателя винила? Правильно, все это нельзя проносить на территорию предприятия, во всяком случае в сумках. Сумки на выходе, а иногда и на входе досматривает орава бесполезных в обычной жизни теток-охранниц. При этом на автомобиле с территории можно вывезти все что угодно. Естественно что ни о каком интернете на рабочем месте речи не идет, точнее я не представляю сколько бумаги надо измарать, чтобы было произведено подключение. После подключения, говорят, блокируют USB порты. Соответственно даже начальство сидит с 3g модемами.
Перейдем ближе к моей непосредственной работе. Мне предстояло запрограммировать микроконтроллеры в пульте, который принимал бы сигналы датчиков бесплатформенного инерциального блока (БИБ) и выдавал их по USB в компьютер, а так же написать программу приёма информации в ЭВМ. Первое что меня удивило — это отсутствие ТЗ в каком-нибудь твердом виде — все на словах, соответственно сложности с внезапными изменениями проекта в дальнейшем. Второе — отсутствие каких бы то ни было стандартов написания программ. В итоге получается что у трех программистов в одном отделе разные IDE, причем два из них пишут на C++, а третий на C#. Взаимодействие, написание продукта командой — нет, не слышали. В начале моё ПО отрабатывалось на макете. Макет состоял из демонстрационных плат Миландра и пары своих. Свои платы были заказаны на стороне (намного быстрее и человечнее) — и это на предприятии с огромной производственной базой. Макет вполне помещался в коробку из-под туфель. Далее было решено использовать в серийном изделии все те же демонстрационные платы, хотя 90% перифирии на них не использовалось. Остальные платы были сделаны уже на предприятии навесным монтажом (!). В итоге пульт получился размером с системный блок. Проверять работу монтажников поручили какого-то черта мне, при наличии у монтажников своих проверяющих. Следующую неделю, проведенную с паяльником и тестером я возненавидел. Проверять навесной монтаж и жгуты МГТФа не хочется желать даже врагу. Еще одной странностью является лояльность к разного рода костылям. В пульте работают два контроллера, и вместо того, чтобы соединить их по шине и сделать один USB выход, каждый контроллер использует свой USB, и пульт соединяется с компьютером двумя проводами (да, мне стыдно за это, но тогда я был озадачен написанием диплома). Политика предприятия такова, что к пульту приписывается компьютер. Т.е. если, допустим, надо перенести пульт с одного стенда на другой — вместе с ним тащится и компьютер. Это вызвано системой документооборота. Кстати, сдать работающую программу из-за кучи бесполезных бумажек почти так же сложно как и написать ее.

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

Нанотехнологии
Самое интересное то, что западные БИБ содержат нормальное устройство обмена в себе, сразу предлагая потребителю нормальный выход, например, RS-232, и имеют значительно меньшие размеры, в то время как отечественные имеют один неудобоваримый выход выход на один канал, что приводит к килограммам кабелей и специфической архитектуре БЦВМ. В электронных устройствах можно использовать только отечественные компоненты, хотя в тех же процессорах Миландра отечественный только корпус, что приводит к огромным размерам конструируемых устройств.

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

Итак, основные причины, почему я не верю в отечественный космос:

— Вредительская кадровая политика;
— Крайне низкий уровень руководства, затягивание сроков;
— Бюрократия и отсутствие ответственности;
— Полное отсутствие конкуренции в данной области -> паразитирование на советском наследии; 
— Отсутствие перспектив роста для сотрудников (в плане зарплаты);
— Отсутствие отечественной элементной базы.

ЦитироватьMax Andriyahov пишет:
https://geektimes.ru/post/180697/
Почему я не верю в отечественный космос — взгляд изнутри
Уже несколько лет я работаю программистом на одном из предприятий РосКосмоса — ФГУП ХХХХХ...

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

В ИСС, например, все намного лучше.

ЦитироватьTAU пишет:
Пропагандист? Русофоб? Явно тенденциозный вброс. 

А чего еще можно ждать от статьи в этом специально огороженном заповеднике для айтишников?

ЦитироватьА чего еще можно ждать от статьи в этом специально огороженном заповеднике для айтишников?

А кто занимается разработкой БЦВМ? Кочегары?

ЦитироватьMax Andriyahov пишет:
А кто занимается разработкой БЦВМ? Кочегары?

Если разработчиков РЭА назвать айтишниками, они могут и обидеться

ЦитироватьLunatik-k пишет:

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

Отличный пример бессмысленной траты ресурсов. К сожалению, неполный. Вам нужно было добавить, что ASM они тоже сами написали, тогда было бы вообще здорово.

Цитироватьopinion пишет:

ЦитироватьLunatik-k пишет:

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

Отличный пример бессмысленной траты ресурсов. К сожалению, неполный. Вам нужно было добавить, что ASM они тоже сами написали, тогда было бы вообще здорово.

Вы просто показали свою ограниченность. Смыслы - они разные бывают. В разных предметных областях.

ЦитироватьTAU пишет:

Цитироватьopinion пишет:

ЦитироватьLunatik-k пишет:

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

Отличный пример бессмысленной траты ресурсов. К сожалению, неполный. Вам нужно было добавить, что ASM они тоже сами написали, тогда было бы вообще здорово.

Вы просто показали свою ограниченность. Смыслы - они разные бывают. В разных предметных областях.

Ну, это да. Просто для разработки ПО то, что вы описали точно не требуется.

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

На чём же они его написали?

На ASM для СМ-1420. (ой давно это было)
Система команд БЦВМ была как у СМ-1420.
Работа проводилась только ради того чтобы в коде не было незапланированных дыр.
Буржуям веры не было.

Все предварительные модели прикладных программ писали и отрабатывали на обычном Досовском Паскале для PC-XT, AT286 и AT386 машин только без применения процедур, которые отсутствовали в урезанном собственном паскале.
Предварительная имитационная модель была построена на сети из персоналок.
Компилятор собственного ПАСКАЛЯ был полностью прозрачен  и предсказуем.
Была полная уверенность, что он не выкинет глупости и дыр не будет.
И только после тчательной отработки алгоритмов отлаженных на предварительной имитационной модели на обычных персоналках их переносили на СМ1420, проводили длительные тестовые прогоны на модели построенной на СМ1420 и только после этого допускали к переносу на испытательный стенд с реальной БЦВМ и полной обвязкой всех систем и там испытывали многими месяцами.

Кстати собственный паскаль нужен был еще потому, что он был оптимизирован для работы в режиме постоянных прерываний т.к. прикладные программы на БЦВМ шли в фоновом режиме и прикладные задачи не перегружали работу БЦВМ. Чтобы все задачи реального времени работали строго по плану.

ЦитироватьLunatik-k пишет:
На ASM для СМ-1420. (ой давно это было)
Система команд БЦВМ была как у СМ-1420.
Работа проводилась только ради того чтобы в коде не было незапланированных дыр.
Буржуям веры не было.

Все предварительные модели прикладных программ писали и отрабатывали на обычном Досовском Паскале для PC-XT, AT286 и AT386 машин только без применения процедур, которые отсутствовали в урезанном собственном паскале.
Предварительная имитационная модель была построена на сети из персоналок.
Компилятор собственного ПАСКАЛЯ был полностью прозрачен и предсказуем.
Была полная уверенность, что он не выкинет глупости и дыр не будет.
И только после тчательной отработки алгоритмов отлаженных на предварительной имитационной модели на обычных персоналках их переносили на СМ1420, проводили длительные тестовые прогоны на модели построенной на СМ1420 и только после этого допускали к переносу на испытательный стенд с реальной БЦВМ и полной обвязкой всех систем и там испытывали многими месяцами.

Кстати собственный паскаль нужен был еще потому, что он был оптимизирован для работы в режиме постоянных прерываний т.к. прикладные программы на БЦВМ шли в фоновом режиме и прикладные задачи не перегружали работу БЦВМ. Чтобы все задачи реального времени работали строго по плану.

О, как интересно, спасибо большое. Нужно рассказать на работе мужику из Питера, он в 80-ых на то ли на CM-1420, то ли на Электронике-60 для ЦУП-а сеть делал, на MACRO-11 как раз писали. Другой коллега из бывшей конторы увлекается ретрокомпьютингом и написал с другом (тоже, кстати, из Флориды) эмулятор УКНЦ, что использовал аж два процессора КМ1801ВМ2 с PDP-11 (https://code.google.com/archive/p/ukncbtl/). 

Тем, кто не в теме, нужно сказать, что ассемблер для PDP-11 был очень продвинут, и в MACRO-11 это было скорее похоже на написание кода на C, чем на ассемблере для x86.

А как компилятор Паскаля писали - с начала до конца на ASM или метод раскрутки использовали?

Я не могу  пояснить всех тонкостей всего процесса, я был только свидетелем творческого процесса программистов.
Реально я занимался ремонтом оборудования хотя мог писать простые задачи на ASM, СИ и Паскале.
Реально мог вникать и даже анализировал коды оперционной системы для БЦВМ, которую писали на СМ1420.(ради любопытства). Читал документацию на БЦВМ, но это была работа в удовольствие, мне ее не планировали, так привлекали несколько раз для обсуждения работы некоторых тонкостей программирования таймеров, последовательных и параллельных  портов на персоналках.
Построения простеньких имитаторов для построения модели на персоналках.
Но повторю реально работали программисты и я иногда по дружбе присутствовал в их некоторых обсуждениях связанных с их работой.
У меня была работа высококвалифицированного сторожа, пока техника работала я мог и любопытствовать.
 Приходилось вязать веревки между компьтерами объединяя их.
Организовывать мосты, между сетью РС и СМ1420 и далее.
Вязал железо для информационных потококов.
Я был обеспечивающим звеном их творческого процесса.
По поводу Паскаля(в простонародии),  кстати по разработке он мог проходить под другим названием типа
ЯВУ - ХХХ  для БЦВМ - ХХХ.XX
Так из общих сображений, заняться написанием языка, могли и по другим причинам, ввод/вывод стандартного языка отличался от ввода/вывода БЦВМ.

Цитироватьdmitryskey пишет: коллега из бывшей конторы увлекается ретрокомпьютингом и написал с другом (тоже, кстати, из Флориды) эмулятор УКНЦ, что использовал аж два процессора КМ1801ВМ2 с PDP-11 ( https://code.google.com/archive/p/ukncbtl/ )

Эх, какие крутые программы на ассемблере мои друзья для этого УКНЦ писали... Да, с использованием обоих процессоров.

А меня, помню, начавшего изучение ассемблеров с PDP-11 как раз, ужасно "ломало" когда взялся за Intel x86...

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет: Тоскливо глядя на ПО Фобосов, в т.ч.,и Грунта
Прежде, чем судить о надёжности, попробуйте её обеспечить хотя бы в своём курятнике, а дотоле не суйте нос туда, где вы ни ухом, ни рылом.

Попробовал бы для начала повнимательнее разобраться в причинах потери Фобосов. В т.ч. Грунта.

Фобос-1 - ошибка оператора .
Фобос-2 - науке точная причина неизвестна
Фобос-Грунт - если можно говорить об ошибке, то в системной логике и в проекте в целом, а не в программном обеспечении, реализовавшем эту логику...

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

ЦитироватьСтарый пишет:

Цитироватьbsdv пишет:
Попробуйте как нибудь побеседовать на тему современной авионики с пилотами. Думаю доброго слова вряд ли услышите... ))

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

Трындите, оба.
С гражданкой всё более-менее нормально. Оборудование современных авиалайнеров вполне соответствует назначению, в т.ч., и в смысле надёжности; о серьёзных происшествиях по причине его отказа за последние лет 30 слышать не приходилось, а вот по причине ошибок пилотов, от которых "не услышишь доброго слова", - как раз более 90%. Им бы матчасть учить, а не языком трепать...
Правда, кабельная система самолёта ГА в расчёте на датчик весит раза в 4 больше, чем для самосвала, но это тяжкое наследие АРИНК.

У вояк же не знаю, но по слухам, всё гораздо хуже. Там крутые прохвессионалы с допусками в нутрь спецпоселений всем рулят.

ЦитироватьУ меня, как у специалиста караз по авионике, современная авионика не вызывает ничего кроме недоумения. Кроме как желанием распилить бабло на чём угодно я её появление объяснить не могу.

Что там у тебя, как специалиста, вызывает недоумение в современной авионике, и о каком желании распилить бобло ты тут трёшь?

Цитироватьdmitryskey пишет:
В соседней ветке SOE дал очень интересную ссылку, где коротко и доходчиво про подход TAS-1, см http://www.adacore.com/press/ada-on-board-gnat-pro-helps-exomars-get-to-the-red-planet/

Т.е. Thales Alenia Space используют Аду с компилятором GNAT Pro, LEON2 и самописную RT OS.

C учетом вышеуказанного по F-35 можно сделать вывод, что подход ИСС вполне себе в духе работы других аэрокосмических фирм, все работают со своим букетом технологий. Как они сложились - тут прав Feol , это вопрос уже скорее исторический.

Вы ДЕЙСТВИТЕЛЬНО не понимаете разницы?
Леон - детище ЕКА, хоть и замшелое, но ещё подающее признаки жизни, поскольку в эуроппах существует профессиональная авторская поддержка данного мастодонта, а для их космоконтор его почти достаточно, а где недостаточно, там поставят два, а то и многоголового заделают, всё по отказоустойчивой технологии, возможен радостойкий вариант, программное обеспечение разрабатывается и поддерживается аффилированными конторами, у которых всякими сертификатами обклеены даже сортиры, короче, прогресс в области микровычислительных структур их какбэ некасаецца, и оне на ентом дремучем Леоне ещё кучу подвигов в этом столетии намерены совершиць.

А ИСС, с учётом отсутствия авторской поддержки, с вероятностью, близкой к 100%, будут на Леоне лепить горбатого даже не в духе F-35, а раз в 10 хуже, поскольку сравнимого бобла для них нет и не будет, и результата ждать придётся не 15 лет, а все 30, когда нонешние железячники и программеры большей частью впадут уже в маразм, и от затеи останется только шлак и пена.


Я б не писал этого, еслиб на такую порнографию не тратились деньги, которые я отдаю обществу как честный налогоплательщик. :(

А что Модула или Форт умерли совсем?

ЦитироватьSGS_67 пишет:
А ИСС, с учётом отсутствия авторской поддержки, с вероятностью, близкой к 100%, будут на Леоне лепить горбатого даже не в духе F-35, а раз в 10 хуже, поскольку сравнимого бобла для них нет и не будет, и результата ждать придётся не 15 лет, а все 30, когда нонешние железячники и программеры большей частью впадут уже в маразм, и от затеи останется только шлак и пена.

С какой даты начинать отсчет 15 лет?

ЦитироватьSGS_67 пишет:
Леон - детище ЕКА, хоть и замшелое, но ещё подающее признаки жизни

Такое "замшелое", что в ближайшее десятилетие БЦВК с ним (2м и 3м) улетят на десятках аппаратов, примерно 80% таковых произведенных TAS, Airbus и OHB. Почти все остальные 20% с еще более "замшелым" ERC32.

Цитироватьmahor11 пишет: 
А что Модула или Форт умерли совсем?

Очевидно, нет.  :)   

Цитироватьthunder26 пишет: 

ЦитироватьSGS_67 пишет: 
А ИСС, с учётом отсутствия авторской поддержки, с вероятностью, близкой к 100%, будут на Леоне лепить горбатого даже не в духе F-35, а раз в 10 хуже, поскольку сравнимого бобла для них нет и не будет, и результата ждать придётся не 15 лет, а все 30, когда нонешние железячники и программеры большей частью впадут уже в маразм, и от затеи останется только шлак и пена.

С какой даты начинать отсчет 15 лет?

С даты первого полёта прототипов (X-35 A и B).
Ежели с опытных образцов F-35, то всё равно 10+ лет выходит.
Но финзатраты на разработку там приблизились к 100 гигазелёных, емнис.
Такого жыра нашим даже не мечтать.

ЦитироватьSOE пишет: 

ЦитироватьSGS_67 пишет: Леон - детище ЕКА, хоть и замшелое, но ещё подающее признаки жизни

Такое "замшелое", что в ближайшее десятилетие БЦВК с ним (2м и 3м) улетят на десятках аппаратов, примерно 80% таковых произведенных TAS, Airbus и OHB. Почти все остальные 20% с еще более "замшелым" ERC32.

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

Разговор не о ЕКА, а о фраерстве и обезьянстве, ежели Вы заметили.
Пеар TAS, Airbus и OHB хорош, не спорю, но посты желательно дочитывать до конца.

Цитироватьmahor11 пишет:
А что Модула или Форт умерли совсем?

Чак Мур (разработчик Форта) иногда заглядывает вот на эти посиделки - http://forth.org/svfig/index.html .

ЦитироватьLunatik-k пишет:
для SGS_67
Вам бы я посоветовал продолжать писать трехкопеечные программы, а не рассуждать о разумности написания операционной системы на С++.

Такими, как занимается ваша богадельня?
Увольте, но я работаю в структуре, продукцию которой копеечной при всей фантазии не назовёшь, и которая не кормится от госбюджета.

ЦитироватьЕсли Вы прочтете любую аннотацию к используемых Вами компиляторов, то у всех них написано,
что продукт используется таким каким он есть и никакой отвественности за ошибки в компиляторе разработчики не несут. И этим все сказано.

Съедите свой котелок, ежели это не так?  ;)  

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

Такой подход был оправдан для разработчиков ПО микросистем в 80-90-е годы, мне самому приходилось писать на АСМе для систем с жёстким ограничением аппаратных возможностей, а также DSP приложения, поскольку адекватных компиляторов ЯВУ для них тогда просто не существовало, да и сама структура микровычислительных систем часто не способствовала их адаптации.
В 2000+ подобным тому, что Вы пишете, могли заниматься только идиоты.

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

Ну, и как вам там процветается нонче, с ентим обрезанным Паскалем?   :D  

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

Вот болван...

ЦитироватьSGS_67 пишет:
С даты первого полёта прототипов (X-35 A и B).
Ежели с опытных образцов F-35, то всё равно 10+ лет выходит.
Но финзатраты на разработку там приблизились к 100 гигазелёных, емнис.
Такого жыра нашим даже не мечтать.

Не, вы сказали, что ИСС будет более 15 лет создавать БПО для БЦВК Салют-32М1.
Я собственно и спрашиваю - с какой даты отсчитывать 15 лет, чтобы контролировать выполнение вашего прогноза.

ЦитироватьSGS_67 пишет:
100 гигазелёных

100 миллиардов - это 500 тысяч человеколет, 10 лет коллектив 50 тыс человек колбасил один продукт. Это непредставимо много. Так не бывает.

Может, в приставке ошибка?

PS: Продукт себестоимостью 200+ миллионов видел сам. Сегодня на работе.

ЦитироватьSGS_67 пишет: 
1. Это говорит о крайне низкой надёжности и отказоустойчивости системы управления аппаратами в целом, и ПО в частности.
2. Продолжайте в том же духе, и лет через -дцать за место в космосе соревноваться придётся разве с Габоном.

1. Это говорит о низкой устойчивости системы управления аппаратами в целом. А о ПО в частности - ничего не говорит.

2. А ты кто - американец, если "нас" от себя отделяешь и высказываешься с подобной ненавистью? Или просто планируешь уехать? Да, на всякий случай - к Фобосам никакого отношения я не имел, естественно.

Цитироватьmahor11 пишет:
А что Модула или Форт умерли совсем?

Ну почему же  :)  
Форт - есть международное сообщество энтузиастов (http://forth.org/). Проводят конференции, дорабатывают помаленьку язык...

Модула-2 нашла свое развитие в языке Оберон (http://oberoncore.ru/wiki/lang/oberon) уважаемого профессора Вирта (https://www.inf.ethz.ch/personal/wirth/Miscellaneous/ComputersAndComputing.pdf). В принципе, помимо использования Модулы-2 при написании критически важных приложений в АО "ИСС", известны еще некоторые примеры ее использования в подобных приложениях.

Цитироватьthunder26 пишет:

ЦитироватьSGS_67 пишет:
С даты первого полёта прототипов (X-35 A и B). Ежели с опытных образцов F-35, то всё равно 10+ лет выходит. Но финзатраты на разработку там приблизились к 100 гигазелёных, емнис. Такого жыра нашим даже не мечтать.

Не, вы сказали, что ИСС будет более 15 лет создавать БПО для БЦВК Салют-32М1.
Я собственно и спрашиваю - с какой даты отсчитывать 15 лет, чтобы контролировать выполнение вашего прогноза.

Он просто хамит и рисуется. В ИСС, без особых сомнений, все БПО будет разработано - как и неоднократно до того - за пару лет.

ЦитироватьTAU пишет:

Цитироватьmahor11 пишет:
А что Модула или Форт умерли совсем?

Ну почему же  :)  
Форт - есть международное сообщество энтузиастов (http://forth.org/) . Проводят конференции, дорабатывают помаленьку язык...

Модула-2 нашла свое развитие в языке Оберон (http://oberoncore.ru/wiki/lang/oberon) уважаемого профессора Вирта (https://www.inf.ethz.ch/personal/wirth/Miscellaneous/ComputersAndComputing.pdf) . В принципе, помимо использования Модулы-2 при написании критически важных приложений в АО "ИСС", известны еще некоторые примеры ее использования в подобных приложениях.

Как таковой Форт, конечно же, сейчас никому не нужен, его особенности были актуальны во времена микрокомпьютеров. Но нужно иметь ввиду, что PostScript вырос из Форта примерно в той же степени, в какой Оберон вылупился из Модулы-2. А PostScript породил PDF, про связи же Оберона и Джавы Вирт сам говорил.

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

ЦитироватьКак таковой Форт, конечно же, сейчас никому не нужен, его особенности были актуальны во времена микрокомпьютеров. Но нужно иметь ввиду, что PostScript вырос из Форта примерно в той же степени, в какой Оберон вылупился из Модулы-2. А PostScript породил PDF, про связи же Оберона и Джавы Вирт сам говорил.

Но у вас же система управления не на ibm pc  реализована. Нужен компилятор, который учитывает особенности железа. И что у нас используют?

Цитироватьthunder26 пишет:

ЦитироватьSGS_67 пишет:
С даты первого полёта прототипов (X-35 A и B).
Ежели с опытных образцов F-35, то всё равно 10+ лет выходит.
Но финзатраты на разработку там приблизились к 100 гигазелёных, емнис.
Такого жыра нашим даже не мечтать.

Не, вы сказали, что ИСС будет более 15 лет создавать БПО для БЦВК Салют-32М1.
Я собственно и спрашиваю - с какой даты отсчитывать 15 лет, чтобы контролировать выполнение вашего прогноза.

С 2011 года.
http://cyberleninka.ru/article/n/bortovoy-vychislitelnyy-kompleks-dlya-negermetichnyh-dolgoresursnyh-ka

Правда, тогда в БЦВК Салют-32М поставили европейско-американский процессор - старый добрый Атымель 697F:
http://www.atmel.com/devices/at697f.aspx

При условии адекватной авторской поддержки, БЦВК давно пора уже летать.
На сайте же производтеля вы хрен её найдёте.

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

ЦитироватьНу-и-ну пишет:

ЦитироватьSGS_67 пишет:
100 гигазелёных

100 миллиардов - это 500 тысяч человеколет, 10 лет коллектив 50 тыс человек колбасил один продукт. Это непредставимо много. Так не бывает.

Бывает.
Грю же - затраты только на разработку неумолимо приближаются к этой цифре.
К 12-го году, оне уже составляли 55 гигабаков, емнис.
С тех пор ихний конгресс их только увеличивает. Отступать поздно, типа.

ЦитироватьМожет, в приставке ошибка?

Никакой ошибки.
Справедливости ради, надо сказать, что F-35 - это три разных самолёта.
В этом смысле, подход уникален.
Но не приведи готт его кому-нить повторить...

ЦитироватьPS: Продукт себестоимостью 200+ миллионов видел сам. Сегодня на работе.

Ну, поскольку форум космический, ентим здесь особо никого не удивишь. :)

ЗЫ Ихний Трамп давеча наорал на локхиды с нортропами, шо более 100 млн. бакинских за самолёт платить не будет. И шо представители (гос)заказчика чюдесным образом через пару лет по заключении контрактов, оказываются на тёпленьких местах в ентих конторах.
Видимо, достали даже и его.  :D

ЦитироватьTAU пишет: 

ЦитироватьSGS_67 пишет: 
1. Это говорит о крайне низкой надёжности и отказоустойчивости системы управления аппаратами в целом, и ПО в частности.
2. Продолжайте в том же духе, и лет через -дцать за место в космосе соревноваться придётся разве с Габоном.

1. Это говорит о низкой устойчивости системы управления аппаратами в целом. А о ПО в частности - ничего не говорит.

Говорит.
Утрата пространственной ориентации аппарата вследствие ошибки управления - не повод для его потери.
Грамотно написанное ПО должно уметь ликвидировать последствия такого события.

Цитировать2. А ты кто - американец, если "нас" от себя отделяешь и высказываешься с подобной ненавистью? Или просто планируешь уехать?

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

Цитировать Да, на всякий случай - к Фобосам никакого отношения я не имел, естественно.

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

ЦитироватьTAU пишет: 
Он просто хамит и рисуется. В ИСС, без особых сомнений, все БПО будет разработано - как и неоднократно до того - за пару лет .

Дятел, там уже 5+ лет трахаются.
А воза пока не видно.

Цитироватьmahor11 пишет:

ЦитироватьКак таковой Форт, конечно же, сейчас никому не нужен, его особенности были актуальны во времена микрокомпьютеров. Но нужно иметь ввиду, что PostScript вырос из Форта примерно в той же степени, в какой Оберон вылупился из Модулы-2. А PostScript породил PDF, про связи же Оберона и Джавы Вирт сам говорил.

Но у вас же система управления не на ibm pc реализована. Нужен компилятор, который учитывает особенности железа. И что у нас используют?

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

Не, я готов ошибиться, и, честно, желаю, чтобы КА у нас было лучче и больше, но мне сей подход представляется мешающим фактором. :(

ЦитироватьSGS_67 пишет:

ЦитироватьTAU пишет:
Он просто хамит и рисуется. В ИСС, без особых сомнений, все БПО будет разработано - как и неоднократно до того - за пару лет .

Дятел, там уже 5+ лет трахаются. А воза пока не видно.

Не понимаешь. Путаешь Салют-32 и Салют-32М1. С ней как раз недавно начали работать. И если внимательнее почитать по ссылкам, начиная с начала данной ветки - сразу виден и воз, и не он один.

ЦитироватьSGS_67 пишет:
Бывает.
Грю же - затраты только на разработку неумолимо приближаются к этой цифре.

Не. конкретно софта себестоимостью 100 миллиардов не бывает.

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

Безотносительно индустрии, кстати, их нигде нет.

И тут не надо мнений, тут я могу рассказывать, как оно есть.

ЦитироватьTAU пишет:
Не понимаешь. Путаешь Салют-32 и Салют-32М1. С ней как раз недавно начали работать. И если внимательнее почитать по ссылкам, начиная с начала данной ветки - сразу виден и воз, и не он один.

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

ЦитироватьВ 2011 г. на ОАО «ИРЗ» были начаты работы по созданию БЦВК «Салют-32М1». На начальном этапе работ были рассмотрены возможные варианты реали- зации БЦВК и выбран процессор для перспективного вычислительного комплекса. При выборе процессора были рассмотрены раз- личные варианты процессоров и процессорных ядер отечественного и зарубежного производства. В ре- зультате изысканий был выбран процессор AT697F европейской компании Atmel. Выбранный процессор и его предшественники имеют богатую «летную ис- торию» и используются на текущий момент во мно- гих проектах Европы и Америки, например, Colombus (200  8)  , Proba2 (2009), JUNO (2011), SVOM/Éclair (2012), SWARM (2012), Sentinels (2013), Alphasat (2013) и т. д. Процессор AT697F удовлетворяет текущим требо- ваниям заказчика и, по нашим оценкам, перспектив- ным требованиям на 10 лет вперед. Производитель, в свою очередь, гарантирует производство этого про- цессора в течение более чем 10 лет. Для поставки в Россию процессоров Atmel c любым уровнем ква- лификации не требуется разрешения Государствен- ного Департамента США.

"Европейский" Атымел - это ошибка автора статьи.
Писанной в 13-году. Щаз - санкцыи.
  :(

ЦитироватьНу-и-ну пишет:

ЦитироватьSGS_67 пишет:
Бывает.
Грю же - затраты только на разработку неумолимо приближаются к этой цифре.

Не. конкретно софта себестоимостью 100 миллиардов не бывает.

Нет, я не про только софт писал, а про всю программу разработки.
Которая уже года 4+ тормозится именно из=за софта, и на который тратися бобло в размерах сов. секретных.
Мелочи типа удушения пилота на высоте опустим; кроме них там проблемы системного свойства из-за фраерского подхода (мсм) - типо, главное - начнём, а потом кривая вывезет, а получилось так, что ить не вывезла, и пару лет назад пришлось чуть ли не вы...дить/зпаменить большую часть создателе системного ПО, да ещё стыковка БРЭО с оружием там не то что аховая а вообще под плинтусом, кароче, за панты обломилось по полной, но теперь уже доделают - деваться некуда, а общая стоимость программы вааще 1,5 терабака.
Специально не слежу, но гугель Вам подскажет, если интересно.

Цитироватьopinion пишет:
...что ASM они тоже сами написали...

Прикола ради - я однажды АСМ написал. Для 1816ВЕ51 (аналог 8051), когда она "пошла в народ" через блошиные рынки у Пионера и на Шаболовке.
Базовый компьютер был - "Специалист", основательно переработанный и адаптированный под процессор Z-80.
:)

ЦитироватьSGS_67 пишет:
С 2011 года.

Это железо. Вы пророчили 15-30 лет разработки БПО. С какой даты отсчитывать?

ЦитироватьSGS_67 пишет:
При условии адекватной авторской поддержки, БЦВК давно пора уже летать.

БЦВК не может летать без КА

ЦитироватьSGS_67 пишет:
Правда, тогда в БЦВК Салют-32М поставили европейско-американский процессор - старый добрый Атымель 697F:

Это и есть LEON2, который в составе БЦВК европейских не экспериментальных (PROBA) аппаратов летает совсем недавно и еще лет 10 будет основным для них. Как процессор ЗД, массовых ЗУ и, например, приемников GPS начал летать на год-два раньше (пример - SWARM) и на 5-10 лет дольше будет еще использоваться. Первый Sentinel (1C) с ним как с центральным процессором БЦВК еще не вышел из этапа проектирования, близкий коммерческий аппарат уже в производстве.

Цитироватьthunder26 пишет:

ЦитироватьSGS_67 пишет:
С 2011 года.

Это железо. Вы пророчили 15-30 лет разработки БПО. С какой даты отсчитывать?

Да он просто по ходу, разницы не понимает. Предметом не владеет.

Дело не в процессоре, ежели коротко. И при создании СУ КА собственно аппаратная часть и системное ПО БЦВК - не самая трудоемкая часть. Есть еще функциональное ПО - и на его проектирование, разработку и отладку и уходит львиная часть усилий и времени.

ЦитироватьSGS_67 пишет:  ты точно пейсатель, нет чтоб заглянуть

Анисимова читать надо. И Колташева. Но для этого еще понять нужно, о чем речь вообще - что собой представляет БПО.

Так, между прочим, не о космическом БПО, но некоторые поучительные вещи прослеживаются.

Истребитель F-35 оказался ещё хуже, чем думали (http://www.popmech.ru/weapon/318122-istrebitel-f-35-okazalsya-eshchye-khuzhe-chem-dumali/?utm_source=push_pm&utm_medium=direct_msg&utm_campaign=20170121_66041)

ЦитироватьF-35 Joint Strike Fighter является самой дорогой военной программой в мире — её общая стоимость превышает 1 триллион долларов. При этом в новом докладе Пентагона сообщается, что истребитель до сих пор имеет несколько сотен критических недостатков и не будет готов к боевым испытаниям как минимум до 2019 года.
На сей раз многострадальный истребитель-бомбардировщик пятого поколения F-35 подверг разгромной критике в своём ежегодном докладе директор управления по эксплуатационным испытаниям и проверкам Министерства обороны США Майкл Гилмор. Военные обнаружили в самолёте 276 уязвимостей, которые относятся к работе операционной системы версии 3F, более половины из которых остались и в обновлённой версии программного обеспечения 3FR6.
Но это ещё не всё. В дополнение к почти трём сотням уже известных ошибок, найденным в истребителе-бомбардировщике, Пентагон продолжает находить новые, причём с завидной регулярностью. Если точнее, то в среднем по 20 недостатков в месяц, и предпосылок для их окончания пока не наблюдается...
Но самое интересное, что чёткого плана действий, как решить все эти проблемы, у разработчиков самолёта нет. Неудивительно, что на программу F-35 Joint Strike Fighter обратил внимание даже избранный президент США Дональд Трамп, который потребовал у военных сократить расходы на истребитель. Он пообещал «сэкономить миллиарды долларов», вплотную занявшись программой с сегодняшнего дня, 20 января.
Что он конкретно имел в виду, покажет время. Если Трамп рискнёт и вовсе отменить программу F-35, то разработка нового истребителя займёт как минимум десятилетие и потребует несколько сотен миллиардов долларов. Компания Lockheed Martin, разработчик истребителя-бомбардировщика, тем временем подешевела на 2 миллиарда, а стоимость её акций упала на 4%

Самая дорогая военная программа вообще в мире на сегодня может быть закрыта из-за проблем с программным обеспечением системы управления!!!  Насколько показательно.

Насколько я помню, между прочим, бортовое ПО F-35 писалось на С++.

ЦитироватьTAU пишет:


Самая дорогая военная программа вообще в мире на сегодня может быть закрыта из-за проблем с программным обеспечением системы управления!!! Насколько показательно.

Насколько я помню, между прочим, бортовое ПО F-35 писалось на С++.

Ага, я спрашивал уже в этой ветке, вот что ответили
[TH]Цитата[/TH]

bsdv пишет:  [TH]Цитата[/TH] dmitryskey пишет:  И может, кто просветит, что на сей счет американская военщина использует на том же F-35?  У них своя кухня, очень специфичная...  http://www.ghs.com/AerospaceDefense.html (http://www.ghs.com/AerospaceDefense.html)  http://www.ddci.com/products_deos/ (http://www.ddci.com/products_deos/)  И на Аде пишут, и С не брезгуют...  Но там все завязано на сертификацию летной годности. Естесственно никакого опен сорс....

Интересно, конечно, было бы у спецов узнать точно в чем дело, не должен язык настолько большие проблемы вызывать, по большому счёту - язык дело обычно вторичное. То, что я читал - так это супернавороченный радар для работы по земле, тут охотно можно поверить в проблемы ПО, там и распознование образов и проч. А если радар не работает сверхнадёжно - то как на боевые вылетать, когда, извиняюсь, и убить могут

Вообще говоря, умение вояк тратить деньги, оправдываясь тем, что они, де, Родину защищают, внушает даже какое-то уважение. Потратить триллион в Штатах (а это, вообще-то, мои налоги тоже) на F-35, а в России иметь два вида БРПЛ, три вида МБР, три вида базирования с разработкой новой шахтной ракеты и БЖРК (причём даже МИТ был против) - и тут тоже за мои налоги в РФ. Грустно все это, давно можно было и на Луне базу и на Марс слетать

Цитироватьthunder26 пишет:

ЦитироватьSGS_67 пишет:
С 2011 года.

Это железо. Вы пророчили 15-30 лет разработки БПО. С какой даты отсчитывать?

Написано уже, извольте ознакомиться.
Нормальный подход состоит в том, чтоб начинать писать ПО с момента утверждения вычислительной платформы, задолго до создания "боевого" железа.
Если ИСС избрал и здесь "не имеющий аналогов" путь, то так и говорите.
Только у меня есть подозрение, что вы не в теме, уважаемый.
А просто тарахтите здесь за свой курятник.

ЦитироватьБЦВК не может летать без КА

То есть, вы уже там почти 6 лет сидите и д.очите, шоб под вашу уникальную систему с Леоном на Молдуле-2 подвернулся хоть какой-нить завалящий аппарат, я правильно вас понял?

ЦитироватьSOE пишет: 

ЦитироватьSGS_67 пишет: 
Правда, тогда в БЦВК Салют-32М поставили европейско-американский процессор - старый добрый Атымель 697F:

Это и есть LEON2, 

Ну надо же, открыли вот америку, написанную тамочки на сайте, да и ещё с 
эмблемой ЕКА.
Собссно, я о том, что чип нонче - санкционный, а кетайский клон будет работать по-кеиайски.

Цитироватькоторый в составе БЦВК европейских не экспериментальных (PROBA) аппаратов летает совсем недавно и еще лет 10 будет основным для них. Как процессор ЗД, массовых ЗУ и, например, приемников GPS начал летать на год-два раньше (пример - SWARM) и на 5-10 лет дольше будет еще использоваться. Первый Sentinel (1C) с ним как с центральным процессором БЦВК еще не вышел из этапа проектирования, близкий коммерческий аппарат уже в производстве.

Цвайхандер в обе рУки вам.

МСМ, аппаратная платформа не соответствует вполне современным требованиям.
Ну и пусть их.

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

ЦитироватьTAU пишет:

Цитироватьthunder26 пишет:

ЦитироватьSGS_67 пишет:
С 2011 года.

Это железо. Вы пророчили 15-30 лет разработки БПО. С какой даты отсчитывать?

Да он просто по ходу, разницы не понимает. Предметом не владеет.

Дятел, ты ващще имеешь представление, как работает транзистор или даже диод?

ЦитироватьДело не в процессоре, ежели коротко. И при создании СУ КА собственно аппаратная часть и системное ПО БЦВК - не самая трудоемкая часть. Есть еще функциональное ПО - и на его проектирование, разработку и отладку и уходит львиная часть усилий и времени.

Денек нет, но вы ипитесь
.
Подсказка- на модуле-2.  :D

ЦитироватьSGS_67 пишет:
Написано уже, извольте ознакомиться.

С 2011? Ок. По вашим прогнозам, ждем БПО под С-32М1 в 2026-2041 году.

ЦитироватьSGS_67 пишет:
То есть, вы уже там почти 6 лет сидите и д.очите, шоб под вашу уникальную систему с Леоном на Молдуле-2 подвернулся хоть какой-нить завалящий аппарат, я правильно вас понял?

Нет

Цитироватьdmitryskey пишет:
Вообще говоря, умение вояк тратить деньги, оправдываясь тем, что они, де, Родину защищают, внушает даже какое-то уважение. Потратить триллион в Штатах (а это, вообще-то, мои налоги тоже) на F-35, а в России иметь два вида БРПЛ, три вида МБР, три вида базирования с разработкой новой шахтной ракеты и БЖРК (причём даже МИТ был против) - и тут тоже за мои налоги в РФ. Грустно все это, давно можно было и на Луне базу и на Марс слетать

Вы же умный человек. А рассуждения, как у дебила. Вы предлагаете всё старое выкинуть в один момент и заменить новым? Разработка F-35 имела в виду заменить сразу 3 вида боевых самолётов. Что из этого получилось-сами знаете. Унификация должна проводиться в разумных пределах, не нанося ущерба ТТХ и постепенно заменяя выбываемые образцы военной техники новыми образцами.

ЦитироватьSGS_67 пишет:
аппаратная платформа не соответствует вполне современным требованиям

Какая "аппаратная платформа" ? Процессор? Это, грубо говоря, 10% БЦВК по затратам на разработку. И каким требованиям он не соответствует-то?

ЦитироватьВиктор Зотов пишет: 
Вы же умный человек. А рассуждения, как у дебила. Вы предлагаете всё старое выкинуть в один момент и заменить новым? Разработка F-35 имела в виду заменить сразу 3 вида боевых самолётов. Что из этого получилось-сами знаете. Унификация должна проводиться в разумных пределах, не нанося ущерба ТТХ и постепенно заменяя выбываемые образцы военной техники новыми образцами.

Не, я как раз прямо противоположное имел ввиду, скорее всего, неясно выразился. У меня вызывает даже восхищение умение военных что в Штатах, что в России выбивать деньги на новые вундерваффе. Ну что, нельзя было что-ли просто модернизировать в самом деле легендарный F-15 (тем паче, что Боинг спит и видит, как продать свой Silent Eagle) для ВВС. Тем более, что для Navy все-равно Super Hornet сделали, для КМП тоже что-то можно было бы придумать без F-35. Ну где все эти навороты того же F-22 использовать - против патрулирующих Ту-95МС что-ли? А если уж так хочется поддержать экономику военным кейнсианством - так тем же компаниям дать больше денег на завершение космических программ - в итоге деньги так же и с таким же эффектом потрачены, зато народ горд лунной базой. И в России не тратят кучу денег на Т-50, а дотируют у того же Сухого СуперДжет - а то из Ижевска в Ростов-на-Дону через Москву летать приходится.

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

Чтобы не отвлекаться от темы форума - я по той же причине поддерживаю подход ИСС с Модулой-2 и LEON2. Если можно спокойно модернизировать то, что есть, и решать целевые задачи - то нужно так и делать.

Тут мне очень нравится подход Росатома - а на данный момент это чуть ли не единственная область, где мы и старое не растеряли, и новое делаем, и вполне конкурентноспособны на мировом рынке. Там четкая линия - РБМК пока работают, если ремонт как на ЛАЭС экономически целесообразен - ремонтируем, нет - заменяем на ВВЭР-1200. На экспорт серийный и отработанный ВВЭР-1000, там эксперименты не к чему. Параллельно строим быстровики - но без фанатизма. Денег стало меньше - приостановили БРЕСТ и БН-1200, но продолжаем с нитридным топливом и БН-800. Все понятно, разумно и запланировано.

ЦитироватьSGS_67 пишет:

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет:
1. Это говорит о крайне низкой надёжности и отказоустойчивости системы управления аппаратами в целом, и ПО в частности

1. Это говорит о низкой устойчивости системы управления аппаратами в целом. А о ПО в частности - ничего не говорит.

Говорит. Утрата пространственной ориентации аппарата вследствие ошибки управления - не повод для его потери. Грамотно написанное ПО должно уметь ликвидировать последствия такого события

Марш учить матчасть (хотя кто ж такому даст... ну, можно и открытые материалы найти, хотя бы по форуму по моим сообщениям поискать...)!

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

И лишь после этого на основе спецификаций создается ПО. В нем самом как таковом, увы, возникают ошибки - несоответствие спецификации. В этом случае правомерно говорить о вине программистов и некачественном ПО. Но в случае, ежели аппарат а) неправильно спроектирован - случай Фобос-Грунта; б) неверно сформулирована логика управления в нештатной ситуации, или в) ошибка содержалась в спецификации - не нужно валить все на программы.

ЦитироватьSGS_67 пишет:  колокол на шею прицепи, ходи и звони о не имеющих аналогов скрепах и устоях, бо у попов на байконурах вода уже протухла вся

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

ЦитироватьSGS_67 пишет: 
При условии адекватной авторской поддержки, БЦВК давно пора уже летать. На сайте же производтеля вы хрен её найдёте

Летает не БЦВК. Летает космический аппарат. В коем система управления (БКУ) - подсистема. Имеющая аппаратные и программные составляющие. В ней же БЦВК - подсистема. Когда готов будет КА как сложный технический комплекс - тогда БЦВК и начинает летать. А уж об отдельно взятом процессоре вообще говорить смешно. Не играет процессор определяющую роль в системе управления КА, поймите же наконец.

ЦитироватьSOE пишет:

ЦитироватьSGS_67 пишет: аппаратная платформа не соответствует вполне современным требованиям

Какая "аппаратная платформа" ? Процессор? Это, грубо говоря, 10% БЦВК по затратам на разработку. И каким требованиям он не соответствует-то?

Да просто не в теме демагог. Не представляет вообще специфики "космических" процессоров, как я и говорил.

ЦитироватьSOE пишет:

ЦитироватьSGS_67 пишет:
аппаратная платформа не соответствует вполне современным требованиям

Какая "аппаратная платформа" ? Процессор?

Не только.
Аппаратная (или, в данном случае, вычислительная) платформа - это "тело" электронной системы, построенной вокруг "головы" - микропроцессора.

Цитировать Это, грубо говоря, 10% БЦВК по затратам на разработку.

Вот именно, что грубо, мягко говоря.
В любом случае, это печка, от которой начинаются все танцы с бубном - разработка ПО.

Цитировать И каким требованиям он не соответствует-то?

Частью написал выше. Также есть, кхм,.. особенности аппаратного свойства данного процессора, которые уместно обсуждать только со специалистом.

Цитироватьdmitryskey пишет: 
Не, я как раз прямо противоположное имел ввиду, скорее всего, неясно выразился.

Лучше не пишите о том, чего не знаете.

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

Бред.

ЦитироватьЧтобы не отвлекаться от темы форума - я по той же причине поддерживаю подход ИСС с Модулой-2 и LEON2. Если можно спокойно модернизировать то, что есть, и решать целевые задачи - то нужно так и делать.

В чём вы здесь усматриваете "модернизацию того, что есть", особенно с учётом Модулы -2?

ЦитироватьТам четкая линия - РБМК пока работают, если ремонт как на ЛАЭС экономически целесообразен - ремонтируем, нет - заменяем на ВВЭР-1200.

Бред №2.
Вы не понимаете, по каким причинам выводятся из эксплуатации РБМК. И вряд ли сможете поведать, где они были заменены на ВВЭР-1200.

Про БН даже не комментирую.
:(

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет:

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет:
1. Это говорит о крайне низкой надёжности и отказоустойчивости системы управления аппаратами в целом, и ПО в частности

1. Это говорит о низкой устойчивости системы управления аппаратами в целом. А о ПО в частности - ничего не говорит.

Говорит. Утрата пространственной ориентации аппарата вследствие ошибки управления - не повод для его потери. Грамотно написанное ПО должно уметь ликвидировать последствия такого события

Марш учить матчасть (хотя кто ж такому даст... ну, можно и открытые материалы найти, хотя бы по форуму по моим сообщениям поискать...)!

Что учить-то, дятел?
Ваши пройопы? Так я о них не только из открытых материалов сведения имею.

ЦитироватьИ лишь после этого на основе спецификаций создается ПО. В нем самом как таковом, увы, возникают ошибки - несоответствие спецификации. В этом случае правомерно говорить о вине программистов и некачественном ПО. Но в случае, ежели аппарат а) неправильно спроектирован - случай Фобос-Грунта; б) неверно сформулирована логика управления в нештатной ситуации, или в) ошибка содержалась в спецификации - не нужно валить все на программы.

Программы - это и есть логика управления, выраженная на "языке" исполнительной части (контроллера).
Мог бы прочитать об этом и в открытых источниках.  :)  

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет:
При условии адекватной авторской поддержки, БЦВК давно пора уже летать. На сайте же производтеля вы хрен её найдёте

Летает не БЦВК. Летает космический аппарат. В коем система управления (БКУ) - подсистема.

А БЦВК что, на земле в это время лежит??   :o  

Пилот по твоей логике тоже не летает, верно?

ЦитироватьSGS_67 пишет: Аппаратная (или, в данном случае, вычислительная) платформа - это "тело" электронной системы, построенной вокруг "головы" - микропроцессора...
В любом случае, это печка , от которой начинаются все танцы с бубном - разработка ПО

Ну и?

Начинается ладно. Первый шаг, небольшой. Дальше что? 

По оценкам специалистов ЦНИИМАШ, например, трудоемкость и стоимость создания программного обеспечения БКУ на порядок превосходит аналогичные показатели аппаратнго обеспечения БКУ в целом - а ведь это вовсе не один сам по себе взятый процессор, а еще интерфейсные модули сопряжения, память, и прочая, и прочая, и прочая.

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

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

ЦитироватьSGS_67 пишет: Ваши пройопы? Так я о них не только из открытых материалов сведения имею

ЦитироватьПрограммы - это и есть логика управления, выраженная на "языке" исполнительной части (контроллера).

1. Чьи, позвольте поинтересоваться? Что имеется в виду? Давай, делись сведениями своими "не из открытых источников".


2. Дело в следующем. При создании КА - как сложного технического комплекса - присутствует разделение труда. И зачастую логику управления формулируют (на различных языках и различными средствами) другие люди - не программисты. Логика эта фиксируется в официальных документах, за кои эти люди отвечают. После чего попадает эта документация программистам, кои - в силу своего понимания этих спецификаций - вообще, именно здесь "зарыта собака" причин многих ошибок при управлении КА - разрабатывают и отрабатывают реализующие эту логику программы.

ЦитироватьSGS_67 пишет:
Частью написал выше. Также есть, кхм,.. особенности аппаратного свойства данного процессора, которые уместно обсуждать только со специалистом.

Смешно.

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет: Аппаратная (или, в данном случае, вычислительная) платформа - это "тело" электронной системы, построенной вокруг "головы" - микропроцессора...
В любом случае, это печка , от которой начинаются все танцы с бубном - разработка ПО

Ну и?

Начинается ладно. Первый шаг, небольшой. Дальше что?

Написано же, выше.  :)  

ЦитироватьПо оценкам специалистов ЦНИИМАШ, например, трудоемкость и стоимость создания программного обеспечения БКУ на порядок превосходит аналогичные показатели аппаратнго обеспечения БКУ в целом - а ведь это вовсе не один сам по себе взятый процессор, а еще интерфейсные модули сопряжения, память, и прочая, и прочая, и прочая.

Дык, об том и речь.
И ещё о том, что неправильный выбор аппаратной платформы увеличит стоимость и трудоёмкость создания ПО ещё на порядок.
А в случае с Леоном это именно так; есть примеры из жизни, но не для "открытых источников".

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет: Ваши пройопы? Так я о них не только из открытых материалов сведения имею

ЦитироватьПрограммы - это и есть логика управления, выраженная на "языке" исполнительной части (контроллера).

1. Чьи, позвольте поинтересоваться? Что имеется в виду? Давай, делись сведениями своими "не из открытых источников".

Для примера, Фобос-1.
О причинах потери имею непосредственные сведения как от разработчиков "железа", так и специалиста ЦУП. Ещё "тогдашних".

Цитировать2. Дело в следующем. При создании КА - как сложного технического комплекса - присутствует разделение труда. И зачастую логику управления формулируют (на различных языках и различными средствами) другие люди - не программисты . Логика эта фиксируется в официальных документах, за кои эти люди отвечают. После чего попадает эта документация программистам, кои - в силу своего понимания этих спецификаций - вообще, именно здесь "зарыта собака" причин многих ошибок при управлении КА - разрабатывают и отрабатывают реализующие эту логику программы.

Согласен.

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

------------------------------------------------
ЗЫ. Далее...

ЦитироватьTAU пишет:
Дело не в процессоре, ежели коротко. И при создании СУ КА собственно аппаратная часть и системное ПО БЦВК - не самая трудоемкая часть.

Заявление столь же поверхностное, сколь и неверное.

ЦитироватьЕсть еще функциональное ПО - и на его проектирование, разработку и отладку и уходит львиная часть усилий и времени.

Так по функциональному ПО у ИСС должен быть как раз обширнейший задел, и никаких камланий, по идее, тут как раз быть не должно!

Весь вопрос как раз в системном ПО, и средствах разработки.
У которых тоже есть своя логика, требующая реализации, с коей ИСС и Ко, вопреки твоим "откровениям", возятся уже почти 6 лет.
Это действительно непонятно, или просто придуриваешься?
  :(

ЦитироватьTAU пишет:

ЦитироватьSGS_67 пишет: колокол на шею прицепи, ходи и звони о не имеющих аналогов скрепах и устоях, бо у попов на байконурах вода уже протухла вся

1. Наезд по принципу "оппонент - дурак" - низкопробная демагогия, не более.

Так не занимайся ею.
Тем более, что я тебя предупредил.

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

Да верьте вы хоть в ктулху с чортом, только за свой счёт, пожалуйста.

ЦитироватьSOE пишет:

ЦитироватьSGS_67 пишет:
Частью написал выше. Также есть, кхм,.. особенности аппаратного свойства данного процессора, которые уместно обсуждать только со специалистом.

Смешно.

Вам - возможно, а некоторым вот - вовсе нет.

Feol пишет:

Спойлер

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

Всем рулят народные массы    :)   

По этому, например, дискуссии о том, как ИСС ПО пишет, на чём его пишет, правильно оно его пишет или нет, выглядят забавно, когда их пытаются вести в технической плоскости. В реальности сложившаяся система имеет социальную основу, которая лишь приняла некое техническое обличие. Обсуждать это техническое обличие нет смысла, ибо оно оболочка, смена которой может в любой момент произойти мгновенно или не произойти никогда - в зависимости от социальных процессов в коллективе. Под социальной основой надо понимать то, что каждый в коллективе решает, в общем-то, свои личные задачи, которые не обязательно, не всегда, и даже чаще всего не заключаются на самом деле в предельной оптимизации разрабатываемого ПО, в оптимизации процесса его разработки, в оптимизации качества спутников или чего-то еще. Кто-то Модулу-2 не любит, кто-то на Си писать не хочет, кому-то ребёнка лечить надо, кто-то не может заставить штукатура нормально выровнять потолок. Сумма этого и есть социальная основа, которая открывает себя миру в виде технических и организационных решений. Обязательно нужно учитывать, что в социальном смысле у НПО ПМ значительная специфика. По отношению к другим отраслям нужно учитывать специфику производства спутниковых платформ, которое на текущем этапе весьма консервативно. Безотносительно этого и по отношению к другим предприятиям того же направления надо учитывать специфику истории и географического положения НПО ПМ. Расположение в России (уже достаточно    :)    ), в глубине Сибири (за Уралом население 15 млн. - пожалуй, меньше уже, чем в Москве охвачено метро..), в закрытом городе, построенном по приказу сверху с нуля в тайге, пережившим элитарный статус и высший уровень снабжения в советские времена, затем периоды угасания, положительных ростков, неопределённости и т. п. Постоянная дилемма между комфортной жизнью в городе при дефиците работы и наличием какой-никакой работы, но в грязным пыльном Красноярске. Желание перейти на другую интеллектуальную, квалифицированную работу нередко требует "большого" переезда на тысячи километров, на что не всем легко пойти без особых оснований. С чем-то разумнее смириться. И т. д. В итоге иной раз получается, что внешний наблюдатель, незнакомый с потрохами НПО ПМ, обозрев снаружи техническое обличие какого-то вопроса, фактически видит тайну, покрытую сракой мраком. Начинает критиковать покрытие с видимой ему технической стороны. В свою очередь, оппоненты из НПО ПМ просто живут этим вопросом. Так, что уже не осознают это. Они видят, что имеет место наезд и из лучших побуждений начинают защищать себя и предприятие. При этом, не поняв суть происходящего, принимают правила игры зачинщика и начинают искать контр-аргументы в технической плоскости, которая не имеет отношения к вопросу. Естественно, что оппонент разбивает притянутое за уши. После этого спор переходит в драку.

Для внешних наблюдателей хочется отметить, что коллектив НПО ПМ реально очень специфичен. Он не плох и не хорош, он очень специфичен. Есть свои плюсы и минусы. Там слишком высокая концентрация умных людей. Это недостаток и я не шучу. Там очень много хороших людей. Это, ясное дело, плюс. Нужно просто держать в уме, общаясь с НПОшниками, что у них есть много внутренних ньюансов, которые вы не знаете, но можете столкнуться с их проявлением. Некоторые из них, на мой взгляд, вредны для дела, а некоторые полезны. Любой вопрос в НПО ни в коем случае не отделим от своей истории. Это часто важно, но в НПО ПМ это критически важно. Без этого невозможно понять логику, предсказать развитие и выбрать решение.

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

[свернуть]

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

Спойлер

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

[свернуть]

Потому, что описанное положение дел характерно не только для ИСС, а встречается повсеместно.
.

Цитироватьdmitryskey пишет: 

Цитировать умение вояк тратить деньги, оправдываясь тем, что они, де, Родину защищают, внушает даже какое-то уважение. Потратить триллион в Штатах (а это, вообще-то, мои налоги тоже) на F-35, а в России иметь два вида БРПЛ, три вида МБР, три вида базирования с разработкой новой шахтной ракеты и БЖРК (причём даже МИТ был против) - и тут тоже за мои налоги в РФ. Грустно все это, давно можно было и на Луне базу и на Марс слетать

Этот кошмар кончится , когда все страны договорятся и примут закон в ООH против 6 стран обладающих ядерным оружием, чтобы политики 6 стран не пугали им другие страны, чтоб атомное орyжие запретили совсем.Сейчас нет войн, оружия накоплено в несколько десятков раз больше, чем во время 2 мировои воины.Hаселение потеряло огромные деньги на торговцев оружием, на жадных военных.Например корейский диктатор считает, что он сможет правит вечно, если там создали ядерное оружие с помощью России.
Другои пример.В СССР было 240 атомн. подлодок,  в странах СНГ и России вcего 80(примeрно).Каждая атомн. подлодка стоит 300-400 миллионов долларов.Значит в СССР, США потеряло население огромные деньги на ненужные никому атомные подлодки из -за глупости.1 подлодка в CША стоит 3 миллиарда $.

ЦитироватьMaks пишет: Сейчас нет войн

Вы, простите, с какой планеты?

Это целиком в юмор )

ЦитироватьMaks пишет:
Этот кошмар кончится , когда все страны договорятся и примут закон в ООH против 6 стран обладающих ядерным оружием, чтобы политики 6 стран не пугали им другие страны, чтоб атомное орyжие запретили совсем.

Вы, вероятно, молоды.
И ещё не успели оценить смысл древнеримской пословицы: si vis passum, para bellum.
Поэтому, отвечу Вам без стёба.


Стратегическое ядерное оружие в современном мире - гарантия глобальной безопасности. Термин "наступательное" в корне не верен, поскольку после его масштабного применения уже никому и никуда не надо будет наступать.
И мировых войн, покуда в мире есть ЯО в достаточном количестве, не будет.
"Сильные мира сего" - те, которые развязывают мировые войны, и делают на них Большой Гешефт, тоже хотят жить. Хоть Вам это, возможно, будет и не сразу понятно. Ну, дело наживное.

ЦитироватьMaks пишет:
Этот кошмар кончится , когда все страны договорятся и примут закон в ООH против 6 стран обладающих ядерным оружием, чтобы политики 6 стран не пугали им другие страны, чтоб атомное орyжие запретили совсем

Maks, то что вы написали не вызывает даже смеха. Посмотрите на список членов Совета Безопасности ООН. Затем посмотрите на список стран, которые имеют атомное оружие. Мне кажется, эти два списка чем-то похожи, не находите?

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

Проще говоря, право на вето в СБ ООН - отражение возможности уничтожить этот мир. Несправедливо? Справедливо!

https://www.iss-reshetnev.ru/media/newspaper/newspaper-2017/newspaper-427.pdf

ЦитироватьПерспективный интеллект
Компания «ИСС» сделала качественный рывок в развитии бортовых программных технологий.
В этом году исполнилось ровно 35 лет с тех пор, как в компании «ИСС» начался про­цесс бортовой компьютери­зации спутников. В 1982 году состоялся успешный запуск спутника-ретранслятора «Поток», на котором решет­нёвцы впервые установили бортовой информационный вычислительный комплекс (БИВК) на основе цифровой вычислительной машины. На базе этой машины было организовано управление всеми служебными систе­мами. БИВК также позволил рассчитывать целевые ука­зания, по которым проводи­лось наведение лучей актив­ной фазированной антенной решётки на абонента.
И сегодня, спустя десяти­летия, перспективные косми­ческие аппараты компании «ИСС» оснащаются борто­выми комплексами управле­ния (БКУ) нового поколения с мощным интеллектом и практически неограничен­ными возможностями управ­ления спутником, его ремонта (в частности, парирования отказов аппаратуры, которая в течение 10-15 лет открыта экстремальному воздействию космоса), а также высокоско­ростного информационного обмена между всеми систе­мами аппарата. Всё это много­кратно повышает надёжность работы спутника в космосе, и, следовательно, гарантирует выполнение растущего спектра целевых задач.
В конце 2016 года отде­лом системного программи­рования «ИСС» была завер­шена более чем двухлетняя работа по подготовке средств разработки бортового программного обеспечения для внедрения на создаваемых предприятием космических аппаратах. Речь о двух новых вычислительных платформах на базе компьютеров С-32М1 (архитектура SPARCv8 )  и БИВК-М (архитектура PowerPC).
Впервые в истории ком­пании «ИСС» работы по созданию средств для двух компьютеров разной архитек­туры проходили практически параллельно, соответственно, задача решалась вдвойне сложная. Но, как говорят сами специалисты-разработ­чики, нет худа без добра – это обстоятельство заставило их провести перепроектирова­ние технических программ­ных средств в направлении максимальной унификации, и, как следствие, уменьшить трудоёмкость работ и уло­житься в требуемые сроки.
В итоге решетнёвцам уда­лось решить очень сложную задачу – выделить и миними­зировать архитектурно-зави­симое микроядро операцион­ной системы и предоставить компонентам операционных систем более высокого уровня уже унифицированный архитектурно-независимый программный интерфейс. Найденное решение позво­лило до 90% исходного кода (текстов программ) исполь­зовать для обеих операцион­ных систем: и на платформе SPARCv8, и на платформе PowerPC.
Но в целях создания бортового программного обеспечения для новых вычислительных платформ предстояло создать средства разработки и автономного тестирования программ – кросс-систему программи­рования на языке МОДУЛА-2 (КСП М2). Программный имитатор команд бортового компьютера был разрабо­тан специалистами «ИСС», а транслятор и другие, зависимые от архитектуры бортового компьютера , компоненты созданы ООО «Эксельсиор» из новосибир­ского Академгородка. Также нашими специалистами для проведения системного тестирования на наземном отладочном комплексе были разработаны программные модели бортового компью­тера и аппаратуры бортового комплекса управления.
При этом опять-таки предстояло выполнить удво­енный объём работ: разра­ботать крос-систему программирования М2-SPARC и программные модели для платформы SPARCv8 и КСП М2-PPC и модели для платформы PowerPC. И здесь решетнёвцам удалось найти решение – унифицировать структуру программного имитатора команд борто­вого компьютера, что позво­лило сократить общий срок и трудоёмкость создания двух имитаторов.
Важно отметить, что созданные средства сохра­няют традиционные пользо­вательские и программные интерфейсы, применяемые в Решетнёвской фирме. Это существенно облегчает работу специалистов, раз­рабатывающих программ­ное обеспечение бортовых систем, и позволяет при создании новых спутников в большом объёме использо­вать уже имеющийся задел компонент программного обеспечения систем косми­ческого аппарата, процедур тестирования и программной документации.
Таким образом, созданы все необходимые условия для проведения разработки бортового программного обеспечения новых косми­ческих аппаратов в рамках типовых рабочих планов и ещё две вычислительные платформы стали доступны специалистам компании «ИСС» для использования при создании новых космических аппаратов.

Благодарим за предоставленный материал начальника отдела системного программирования для космических аппаратов Андрея Колташева

Спойлер

Первые бортовые программисты появились в НПО ПМ (ныне «ИСС») в 1975 году. Их группу возглавил Олег Петрович Кузоятов. На базе этой группы вырос сектор, а потом и отдел, которые обеспечили создание программных составляющих как первой вычислительной платформы – на основе БЦВМ С-4, так и всех последующих – на основе бортовых компьютеров OBC-1750, C-32, БИВК и двух новых, рассмотренных в статье. Следует отметить, что все созданные вычислительные платформы до настоящего времени в деле: С-4 функционирует в составе спутников Sesat и «Экспресс-А», OBC-1750 на спутниках «Экспресс-АМ», C-32 на «Глонассах-М» и «Экспрессах АМ5/АМ6/АТ1/АТ2» и др., БИВК – на «Лучах-5», «ГЕО-ИК» и «Глонасс-К».
Всего на начало 2017 года специалистами компании «ИСС» сопровождается 47 версий бор­тового программного обеспечения космических аппаратов, находящихся в эксплуатации, и 15 версий программного обеспечения космических аппаратов на стадии изготовления и заводских испытаний.

[свернуть]

 

Цитироватьzandr пишет:
В конце 2016 года отде­лом системного программи­рования «ИСС» была завер­шена более чем двухлетняя работа по подготовке средств разработки бортового программного обеспечения для внедрения на создаваемых предприятием космических аппаратах. Речь о двух новых вычислительных платформах на базе компьютеров С-32М1 (архитектура SPARCv8 )и БИВК-М (архитектура PowerPC).

А каков был прогноз то...

ЦитироватьSGS_67 пишет:
А ИСС, с учётом отсутствия авторской поддержки, с вероятностью, близкой к 100%, будут на Леоне лепить горбатого даже не в духе F-35, а раз в 10 хуже, поскольку сравнимого бобла для них нет и не будет, и результата ждать придётся не 15 лет, а все 30, когда нонешние железячники и программеры большей частью впадут уже в маразм, и от затеи останется только шлак и пена.

https://www.iss-reshetnev.ru/media/newspaper/newspaper-2017/newspaper-429.pdf

Цитировать«Прокачали» мозг
Специалисты «ИСС» проводят отработку модернизированного борто­вого комплекса управления для спутника «Глонасс-К2».

Спойлер

В рамках работ по соз­данию навигационного спутника нового поколения «Глонасс-К2» в компании «ИСС» проводятся автоном­ные испытания его бортового комплекса управления (БКУ). Это своего рода «мозг» косми­ческого аппарата, его авто­номные испытания – это обя­зательный этап при создании любого из спутников. На этом этапе специалистам пред­стоит отработать режимы его включения, а также произвести отладку каналов приёма телеметрии, выдачи команд и обмена данными между при­борами и системами.
Автономные испыта­ния БКУ могут проходить стандартно. А могут нести в себе и новые для испытате­лей задачи. И случай с пер­вым «Глонассом-К2» как раз такой. Дело в том, что бор­товой комплекс управления для данного навигационного спутника модернизирован. Реализованные в нём новые технические решения позво­лят повысить эффективность управления аппаратом на орбите.
«Главным новшеством БКУ «Глонасса-К2» является вычислительный модуль бортового интегрирован­ного вычислительного комплекса, построенный на пер­спективной технологии, которая на наших спутниках до этого не использовалась. Это «Power PC» – процессор с новым программным обеспе­чением, – рассказал инженер отдела проектирования и испытаний аппаратуры БКУ Андрей Тимофеев. – Приборы в составе БКУ также дорабо­таны для обеспечения мак­симально эффективного взаимодействия с новыми вычислительными сред­ствами. Телеметрическая система, в отличие от пре­дыдущих поколений, впер­вые построена на базе вычислительного модуля. Принципиально новыми раз­работками являются также блоки управления БКУ и нагревателями и командно-измерительная система, в которой совмещены блок выдачи-приёма командно-программной информации и блок обработки телеметрии».
Опытным компьютер­ным пользователям хорошо известно: чем мощнее про­цессор, тем продуктивнее идёт работа – и с интерне­том, и с электронной почтой, и с другими приложениями. Бортовые приборы совре­менных спутников – это, в определённом смысле, тоже пользователи. И для них новое программное обеспе­чение на основе мощных процессоров – это гарантия высокоскоростного инфор­мационного обмена между всеми системами аппарата. Это многократно повышает надёжность работы спутника в космосе, и, как следствие – его функционал.
Прежде всего, переход на новый тип процессора позволяет выполнять боль­шее количество операций в секунду, поясняют специалисты отдела проектирования и испытаний БКУ. Это достига­ется за счёт применения более производительного ядра про­цессора. Увеличение количества операций, выполняемых процессором за единицу вре­мени, вместе с увеличением аппаратных ресурсов запо­минающих устройств позво­ляют значительно увеличить и объёмы обрабатываемых данных. Это, в свою очередь, позволяет в большей степени использовать современные цифровые интерфейсы и выполнять анализ состояния аппаратуры бортового комплекса управления, используя максимальное количество программной информации и снизив при этом до мини­мума контроль при помощи средств измерений.
Вывод программной информации в ходе испытаний БКУ происходит в режиме реального времени на мониторы через сред­ства контроля автоматизи­рованного испытательного комплекса. Это возможно благодаря тому, что обмен данными осуществляется по мультиплексному каналу обмена, который в настоя­щий момент является основ­ным цифровым каналом обмена как внутри бортового комплекса управления, так и внутри космического аппа­рата в целом.
После завершения авто­номных испытаний борто­вого комплекса управления «Глонасс-К2» специалисты проверят его взаимодействие с системой ориентации и ста­билизации спутника. И далее новый бортовой комплекс управления будет готов про­ходить испытания уже в составе навигационного кос­мического аппарата

[свернуть]

Zandr, вы не по адресу кинули новость. Эта ветка про БЦВК

https://www.iss-reshetnev.ru/media/newspaper/newspaper-2018/newspaper-451.pdf

ЦитироватьИнтеллектуальный ресурс
В «ИСС» отрабатывают бортовой комплекс управления спутника «Экспресс-80».  (https://forum.novosti-kosmonavtiki.ru/forum/file/87029)
В рамках реализации проекта по созданию космического аппарата «Экспресс-80» специалисты фирмы Решетнёва завершают наземную экспе­риментальную отработку его бортового комплекса управления. Именно в этой аппаратуре сосредоточен интеллект спутника. Она отвечает за сбор телеметрии, а также выдачу и приём управляю­щих команд, которые регулируют работу систем жизнеобеспечения космического аппарата и его полезной нагрузки.
Составные элементы бортового комплекса управления «Экспресса-80» – интерфейсный блок, а также блоки управления, защиты и другие приборы – решетнёвцы разработали с максимальным использованием российской эле­ментной базы нового поколения. В ито­ге успешно решили сразу две важные задачи – повысили производительность и добились снижения массогабаритных характеристик.
Впервые в составе бортового комплекса управления спутника специалистами «ИСС» применена принципиаль­но новая разработка – цифровой вы­числительный комплекс «Салют 32М1», построенный с использованием про­цессора с архитектурой SPARC-V8. Он разработан и изготовлен по техническому заданию «ИСС» давним партнё­ром фирмы – Ижевским радиозаводом. А программное обеспечение для него создали сами железногорские спутникостроители. Помимо высокой произво­дительности вычислительный комплекс обладает уменьшенными массой и габа­ритами, равно как и новая бортовая ап­паратура телесигнализации, при помощи которой осуществляется сбор данных с телеметрических датчиков.
Автономная отработка бортового комплекса управления «Экспресса-80» продлилась около двух месяцев. За это время специалисты протестировали ра­боту каждого прибора и проверили их взаимодействие с новыми вычислитель­ными средствами, а также произвели общую отладку программного обеспе­чения.
«В процессе отработки мы про­водим адаптацию уже существующего программного обеспечения, которое действует в блоке управления, в блоке интерфейсном, чтобы его взаимодей­ствие с вновь внедрёнными вычисли­тельными программами проходило без ошибок, без сбоев, – рассказал Андрей Тимофеев, инженер отдела проектиро­вания и испытаний бортового комплекса управления. – Лишь в таком случае мы можем добиться, чтобы от каждого при­бора без замечаний, в полном объёме доставлялась информация, необходимая для организации всех вычислительных процессов на борту».
Когда аппаратура будет находиться уже в составе спутника, доступ к при­борам станет весьма ограниченным. А после запуска в космос – и вовсе не­возможным. И поэтому автономная наземная экспериментальная отработка – особенно важный этап в реализации каждого космического проекта. Именно на нём специалисты «ИСС» подтверждают тот ресурс надёжности, который позволит аппаратуре спутника исправно работать в его составе на протяжении долгих 15 лет.

Цитироватьzandr пишет:
цифровой вы­числительный комплекс «Салют 32М1», построенный с использованием про­цессора с архитектурой SPARC-V8.

Он на Atmel AT697F
Где импортозамещение???

ЦитироватьPIN пишет:

Цитироватьzandr пишет:
цифровой вы­числительный комплекс «Салют 32М1», построенный с использованием про­цессора с архитектурой SPARC-V8.

Он на Atmel AT697F

Нет

Цитироватьthunder26 пишет:
Нет

Так напишите, на каком процессоре.
ИРЗ на своём сайте вещает: "Разработан на базе радиационно-стойкого процессора AT697F компании Atmel"
Не говоря уже о https://elibrary.ru/item.asp?id=21069288

ЦитироватьPIN пишет:

Цитироватьthunder26 пишет:
Нет

Так напишите, на каком процессоре.
ИРЗ на своём сайте вещает: "Разработан на базе радиационно-стойкого процессора AT697F компании Atmel"
Не говоря уже о https://elibrary.ru/item.asp?id=21069288

На Экспрессах стоит С-32М1С. Это «урезанный» С-32М1, который применяется на других изделиях, про внутренности которых распространяться не стоит

Цитироватьthunder26 пишет:
про внутренности которых распространяться не стоит

Не понимаю смысла комментария. В РФ производится полный аналог AT697F? Совершенно не исключаю, это относительно простое изделие.
Но это не может быть секретом, никак.

PIN, я с вашего позволения все же воздержусь от дальнейших комментариев