Особенности программирования БВК АМС

[Unispace]

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

А как насчет увеличения сложности миссий?

У вас мысли расползаются   Мы о конкретной АМС, ее миссия четко задана. Была. Не нужно там ничего перемудривать. Физика есть физика, уменьшение проектной нормы в кристаллах и увеличение активных элементов уменьшает надежность в условиях космоса. В какую космическую сеть вы собрались встроить аппарат, миссия и время жизни которого строго ограничены 2-3 годами. А коммутатор может работать 30 лет. Вот вам лишь бы поспорить, давайте, завязывайте с этой порочной практикой    Одна из причин, по которой я ушел из наших НИИ и промышленности, не к ночи, это сидящие там дяди с безумными глазами, рисующие сотни картинок пустых на листах и болеющие гигантизмом. Гигантизм обладает способностью из горы родить одну малую мышь. Новому - да, оптимуму -да, гигантизму  - нет. Так и голосуйте  

[zyxman]

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

Вас могли учить ассемблеру по разным причинам - от недостатка матчасти ВУЗа до отсталости преподавателей.
- Ассемблеры ведь тоже разные есть, как и ЯВУ между прочим. - Я знаю немало людей отлично владеющих ассемблером х86, но им например крайне сложно объяснить ЦСП - они его понимают конечно, но то что они проектируют выглядит как полет бегемота.
А вот если человек в достаточно молодом возрасте достаточно имел дело с машинами вроде PDP, Vax, m68k, там уже совсем другая ситуация наблюдается - там ведь есть богатый простор для оптимизации и для изощрений и это развивает мозг и позволяет лучше и быстрее воспринимать новое и эффективнее новое использовать.

То же и с ЯВУ - люди всю жизнь прожившие что на Java, что на C++ без серьезного опыта с такими языками как Lisp, Fort (ну пусть хоть Perl или Ruby) тоже в итоге оказываются ограничены.
У меня когда-то была очень занятная беседа - я несколько часов не мог человеку с огромным опытом C++ объяснить, как работает динамическая типизация в ВМ - он просто не мог пустить в свое сознание понятие, что можно работать не с байтами и словами процессора а с более высокоуровневыми абстракциями, и что эти абстракции могут в ВМ приобретать совершенно немыслимые для сишника свойства.

[Unispace]

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

Вас могли учить ассемблеру по разным причинам - от недостатка матчасти ВУЗа до отсталости преподавателей..

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

[zyxman]

А как насчет увеличения сложности миссий?

Мы о конкретной АМС, ее миссия четко задана. Была.

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

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

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

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

В какую космическую сеть вы собрались встроить аппарат, миссия и время жизни которого строго ограничены 2-3 годами. А коммутатор может работать 30 лет.

Никто не знает, сколько будет работать "Вояджер" - а уже больше 30 лет.

Вообще мы пришли к интересной тенденции, которую вы похоже не заметили - сейчас миссии АМС постоянно удлиняются и постоянно отдаляется срок получения результатов - например "Кассини" практически 10 лет летел и практически ничего от него не было, а потом успех с "Гюйгенс". А сколько лет будет лететь миссия к Плутону? А как насчет изучения облака Оорта? - Там как раз и нужно будет чего-то сооружать, которое будет в полете саморемонтироваться и переконфигурироваться.

И тут есть неприятный такой момент, ИМЕННО что миссии ДОЛЖНЫ усложняться - такой возможности обойти всех на кривой козе как была попытка Ф-Г уже может и не быть, тк может оказаться что ввиду длительности самого процесса подготовки к запуску следующей АМС уже не будет смысла в тех экспериментах что МЫ можем следать, тк их уже сделают другие страны.

АМС это как спорт - тут интересны только призовые места, а какое-нить надцатое место не оправдывает затраты.
- Это сейчас мы якобы четвертые после США,ЕС и Японии, а что будет когда подтянутся Китай, Индия, Бразилия? - Думаю тогда на этом форуме останутся только ностальгирующие да занимающиеся практическим применением в ДЗЗ и связи, тк остальной космос просто оставят без финансирования.

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

Я не болею гигантизмом. Потому что для меня критерий истины практика. И вам того-же желаю :wink:

[Cyberax]

Правильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.

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

А как насчет вероятностного увеличения абсолютного количества сбойных вентилей и ячеек при увеличении объема памяти, что отразится на надежности системы ?

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

Если страница критична, то система просто уйдёт в перезагрузку. Этот механизм даже уже в обычных "гражданских" серверных процессорах есть ( http://lwn.net/Articles/348886/ ).

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

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

Есть старые байки о том, как НАСА патчили в полёте код Вояджера. Так там код написан был на диалекте ЛИСПа. И ничего.

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

[Cyberax]

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

Вообще-то, у НАСА сейчас совершенно серьёзные планы по созданию межпланетной коммункационной сети. До какой-то степени они уже работают - с Марсом у нас сейчас устойчивый канал в 8Мбит. Так что Opportunity не надо будет напрямую до Земли стучаться, достаточно достать ближайший спутник.

[Not]

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

Для примера: ПО Mars Science Laboratory написано на С, содержит 2.5 миллиона строк кода и исполняет порядка 130 конкурентных процессов одновременно. Вы ЭТО собрались писать на ассемблере?  

[Unispace]

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

.

Вот же давал себе слово не вступать в этот раздел    Быстрее бы  разобрались с ФГ, и я уйду. Заниматься ликбезом не входит в мои планы. Почитайте, что такое коды команд, адресное пространство, область кода, счетчик команд, как устроена память, что такое вентили и почему всю систему нельзя считать одной большой самовосстанавливающейся матрицей, из-за чего и применяют то самое дублирование и троирование  
Беда, совсем беда....  и так давно понятно, но когда сталкиваешься напрямую, становится не по себе. Хорошо, что еще кто-то понимает, что нет несокрушимой никаким силами ОС, что работает она в тех же битах памяти, которые могут выйти из строя, и что PC - это не черный ящик, который работает на уровне ООП. Пока такие люди есть, АМС еще будут летать.
 

[Cyberax]

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

Нет, потому что по-другому не умели. Программирование за эти годы ушло даааааалеко вперёд. Сейчас знание ассемблера нужно для:
1) Очень низкоуровневых вещей в ядре ОС.
2) Коротких вставки для оптимизации.
3) Очень ограниченных архитектур.
4) Написания компиляторов и других инструментальных систем.

Из этого списка к космическому аппарату применимо только 4) и даже пункт 1 можно избежать. Сколь-либо больше ассемблерные программы не имеют смысла вообще.

В современном программировании (и даже не космическом!) главное уже не скорость работы, а надёжность. Мы за многие годы выяснили, что человек не умеет писать программы без ошибок, и чем на более низком уровне - тем всё хуже.

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

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

[Unispace]

Я не болею гигантизмом. Потому что для меня критерий истины практика. И вам того-же желаю :wink:

Скажите прямо, пока я еще на форуме, вы что-то создали своим руками ? От задумки, квадратов, моделирования алгоритмов на языке высокого уровня, до железа+программ, до тестов образцов, испытаний ? Я  - да. И сейчас, если я не выполню очень практические дела, сам, то не получу на кусок хлеба. Это к вашему вопросу о практике. Вашим RISC-процессорам лет 30. Еще важно то, что вам могут просто не продать не то что готовые современные схемы, годные для космоса, но даже болванки. А своего передового производства у нас нет. Поэтому нужно делать на чем есть.

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

[Cyberax]

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

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

Опять же, уходите от вопроса: "почему нельзя поставить больше памяти". Возможность возникновения ошибки в памяти КА - это совершенно штатная ситуация. И надеяться, что уменьшение объёма памяти от неё спасёт - это ненадёжно.

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

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

Вот тут замечательный список: http://en.wikipedia.org/wiki/Gravity_Probe_B_mission_timeline

[Not]

Скажите прямо, пока я еще на форуме, вы что-то создали своим руками ? От задумки, квадратов, моделирования алгоритмов на языке высокого уровня, до железа+программ, до тестов образцов, испытаний ? Я  - да.

В наше время никому  нельзя доверять, даже самому себе. Мне - можно

:mrgreen:

[Unispace]

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

Не, я пас. Я умею общаться с теми, кто слышит  Вы вообще понимаете, что все на кристаллах состоит из элементарных физических активных единиц, и все они в равной степени подвергаются воздействию ? И эти единицы не знают, что ее величество ОС беспокоить никак нельзя. Увеличение сбоев в матрице памяти будет устранено системой коррекции ошибок, но кто будет устранять сбойные вентили или транзисторы в физической системе этой коррекции - это вам не кадр информации, дополнительных линиях, системе адресации и контроля записи/чтения матрицы ? Для этого и используется троирование по шине, контроль более простой системой над более сложной, неравенство вероятностей сбоя обеспечивает логичность такого подхода. Это я не говорю еще об уменьшении проектной нормы. Про качество кристаллов уже сказал. До встреч  

[LRV_75]

Дублирование и троирование - это способ восстановления после аппаратных ошибок.

Эт Вы зря. "Горячее" дублирование и троирование - это способ не замечать аппаратных ошибок

[Cyberax]

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

Вам стоит понять, что во ВСЕХ инженерных системах будут какие-то критичные части. Это просто факт жизни. Необходимо количество таких частей сводить к абсолютному минимуму.

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

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

Более того, дополнительная память не будет лежать на критическом пути. Потому влияние её на надёжность будет минимально.

А программирование логики КА напрямую на ассемблере без защиты памяти - это вообще сумасшествие, так как делает ВЕСЬ программный код критичным. И это не шутка - из-за глупой программной ошибки мы потеряли "Фобос-1" и скорее всего "Фобос-2".

[Cyberax]

Дублирование и троирование - это способ восстановления после аппаратных ошибок.

Эт Вы зря. "Горячее" дублирование и троирование - это способ не замечать аппаратных ошибок

Не то чтобы "не замечать" - отказ одного из канала будет точно заметен А скорее способ сделать отказ одного канала некритичным.

Но от программных ошибок оно таки не спасает никак.

[zyxman]

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

Дайте ссылочку на источник этого утверждения.
Я конечно могу ошибаться, но ЕМНИС коррекции не важно, где случился сбойный вентиль - в проверяемой/корректируемой системе или в корректирующей - МАТЕМАТИКА устраняет все сбои без разбора где именно они произошли и вопрос только в количестве допустимых для конкретной математики сбоев.
- А по сути нашего обсуждения этой коррекции хватает на функционирование БВК с защитой памяти и с десятками мегабайтов ОЗУ возле Юпитера, где радиация намного жестче чем возле Марса.

[Unispace]

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

Дайте ссылочку на источник этого утверждения.
Я конечно могу ошибаться, но ЕМНИС коррекции не важно, где случился сбойный вентиль - в проверяемой/корректируемой системе или в корректирующей - МАТЕМАТИКА устраняет все сбои без разбора г.

Вы несете такую чушь, простите. Вы просто не понимаете разницу между логически-математическим уровнем исправления ошибок и физическим. Я не буду вам объяснять дальше. Самовосстанавливающиеся от ошибок на физическом уровне дискретные схемы есть только в фантастике. Если вы хотите внедрить свой Эрланг в НПОЛ и предложить свои знания на этот счет, обратитесь туда напрямую, здесь какой толк о нем писать. Я знаю другой язык подобного уровня, применяемый в очень сложных системах, вам его название, возможно, ничего не скажет. Теперь каждый будет пихать свое видение в этот ФГ ?    Непродуктивно.
Задача бортовой машины  - обеспечивать необходимые функции при заданном уровне надежности. Если это обеспечивается с 2 Мб, то зачем ставить больше, чтобы увеличивать вероятность проблем ? Не умножайте сущности без надобности. Это привычка всех программеров на коленке, которые не связаны четкими ТЗ на конкретное железо, видят перед собой PC, где бездонные терабайты и большие скорости. В железе рамки часто куда более жесткие, и нужно уметь оптимально распорядиться теми ресурсами, которые есть и ограничены. У американцев, японцев есть технологические линии по производству наилучших кристаллов, а у нас этого нет.

[Unispace]

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

[zyxman]

Всегда есть люди, читающие по диагонали

Все люди субъективны, и все люди ошибаются. Только есть еще такие вроде вас, которые упрямо отстаивают собственные ошибки, игнорируя единственное мерило истины - практику.