На чем пишется софт для КА?

Автор hudvin, 06.05.2009 15:28:09

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

Not

Цитироватьвсегда приятно когда самые высокооплачиваемые специалисты разделяют твое мнение :D
А вам не приходила в голову мысль, что размер оплаты работы программиста слабо коррелирует с гениальностью его трудов? Если не сказать - вообще никак. Ваши кумиры из Майкрософт не смогли создать ни одного своего языка, получившего мировое признание. Ни од-но-го. Все что они делают - перепевы и перехваты. А эффективность такой организации как Microsoft Research вообще вызывает здоровый смех в приличном обществе  :D Так что я бы поостерегся гордиться столь сомнительной корреляцией  :wink:

Not

ЦитироватьДжеффри Сновер пошутил, что программирование вышло на такой абстрактный уровень, что скоро писать код можно будет с помощью игрового контроллера для Xbox. Новое поколение таких контроллеров (Project Natal) распознают движения тела, то есть можно просто танцевать перед экраном.
Ага.

zyxman

Спасибо всем за ценную информацию!

Еще уточняющий вопрос: назовите пожалуйста десять КА, в которых тысяча и более датчиков, выдающих не просто пороговую величину, а величину, которую необходимо вводить в уравнение и считать? (скажем, 800 датчиков тоже пойдет)
- Отдельные ячейки ПЗС итп матрицы не считаем датчиками.
- МКС, Буран/Шаттл и РН не называть :lol:

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

TAU

Цитироватьсложностью работы программиста-математика!
Что имеется в виду?

zyxman

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

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

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

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

ДалекийГость

Цитироватьно это все еще не та сложность, которую я бы сравнил с сложностью работы программиста-математика!
Что по Вашему мнению относится к работе программиста-математика?

А то я тут предложил конкретную задачу, непосредственно относящуюся к ПО КА. А мне в ответ, типа - "Это не  задача для программиста-математика."

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

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

ЦитироватьОтдельные ячейки ПЗС итп матрицы не считаем датчиками
Это почему же так? Отдельная ячейка ПЗС-матрицы содержит свою собственную скалярную информацию и ни чем не хуже, чем любой отдельный датчик со скалярным выходом. Или Вы  любое количество однотипных датчиков считаете за один датчик?

PyKaB

Цитировать
Цитироватьно это все еще не та сложность, которую я бы сравнил с сложностью работы программиста-математика!
Что по Вашему мнению относится к работе программиста-математика?

А то я тут предложил конкретную задачу, непосредственно относящуюся к ПО КА. А мне в ответ, типа - "Это не  задача для программиста-математика."

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

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

ЦитироватьОтдельные ячейки ПЗС итп матрицы не считаем датчиками
Это почему же так? Отдельная ячейка ПЗС-матрицы содержит свою собственную скалярную информацию и ни чем не хуже, чем любой отдельный датчик со скалярным выходом. Или Вы  любое количество однотипных датчиков считаете за один датчик?
"уеб-дизайны" дизайнеры могут создавать высоконадежные системы обрабатывающие сотни тысяч запросов в день к базам данных объемом сотни гигабайт - рядовая задача. Чего вы все привязались к вэбу? Завидно что быстрее других развивается не смотря на бОльшую сложность? "программисты-математики ПО КА" курят в сторонке когда речь идет об оптимизации или написание надежных и быстрых СУБД, которые должны работать везде и на всем, а не на одном заточенном под них калькуляторе

LRV_75

Эти вэб-дизайнеры создают сложные системы, потому что имеют в распоряжении соответствующие современные технические и программные средства, поэтому, в этом плане им проще. А также не замарачиваются о многих вещах с которыми разработчикам КА приходиться поработать
Главное не наличие проблем, главное способность их решать.
У каждой ошибки есть Имя и Фамилия

Werno

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

Дем

ЦитироватьСофт для КА включает в себя все системное программирование которое можно представить. Это и драйвера для устройств, и матемитика, служебные задачи обмена информацией между устройствами КА.
так основной и логично возникающий вопрос тут - а не является ли это во многом изобретением велосипеда?
Нельзя ли просто взять готовые протоколы обмена и драйвера, благо их наработано много?
Летать в космос необходимо. Жить - не необходимо.

ДмитрийК

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

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

Конечно разрабатывать/отлаживать алгоритм и код может один и тот же человек, но это два разных вида деятельности, и их лучше не смешивать. И вообще между этими этапами должен быть втиснут документ. Я делал и то и другое попеременно, бывало так что "шляпу менять" приходилось по нескольку раз, напр: Кодируем/оптимизируем алгоритм, пытаемся утоптать некую структуру в 128 бит (так нужно). Нэлэзэт. Меняем шляпу, исследуем а сколько значащих бит нам реально нужно до и после запятой. Строим мат. модель, ставим эксперименты, чертим в экселе графики. Меняем шляпу обратно, продолжаем кодировать.

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

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

А вообще пишут на банальном C только с кучей драконовских самоограничений. Есть несколько стандартов типа "MISRA C", "Japanese Automotive C" итп.
http://en.wikipedia.org/wiki/MISRA_C

ДалекийГость

Цитироватьдизайнеры могут создавать высоконадежные системы обрабатывающие сотни тысяч запросов в день к базам данных объемом сотни гигабайт...
надежных и быстрых СУБД, которые должны работать везде и на всем, а не на одном заточенном под них калькуляторе
Конечно, Web-дизайн и CУБД могут быть очень сложными. Поэтому я там специально уточнил - "Для мелких лавочников". Я занимался такими делами, поэтому знаю, о чем говорю.

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

ДалекийГость

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

Цитироватьсможет ли он это сделать быстрее и лучше чем профессионал, который хорошо владеет контекстом (железо и софт) в котором сей алгоритм будет вариться.
Железо развивается так, что профессиональное владение им и софтом для уже давно становится не актуальным (для прикладных программ). Ну будет код в три раза объемней и/или медленней. Ну и ладно, никому не мешает. Перешли же с ассемблера на языки высокого уровня.

ДмитрийК

Цитировать
ЦитироватьСофт для КА включает в себя все системное программирование которое можно представить. Это и драйвера для устройств, и матемитика, служебные задачи обмена информацией между устройствами КА.
так основной и логично возникающий вопрос тут - а не является ли это во многом изобретением велосипеда?
Нельзя ли просто взять готовые протоколы обмена и драйвера, благо их наработано много?
Основную часть времени занимает не кодирование, а тестирование и всякого рода бюрократия до и после. Использование чужого готового кода эту работу увы не уменьшает а наоборот увеличивает. Например одно из требований - 100% покрытие кода тестами. Если в готовом продукте есть функции или фрагменты кода которые в твоем случае не вызываются - пофиг, либо придумывай (утверждай, согласовывай) для них тест-план, либо выкидывай, просто так оставить их нельзя (и в этом есть свой резон - первый Ариан-5 напр). Фактически получается что "ты в ответе за того кого приручил". А оно тебе это надо?

Дем

ЦитироватьОдин человек - одна зарплата и нет вопросов, кто виноват, если что-то не так.
Два человека - две зарплаты и нужно разбираться, кто из них сделал ошибку.
Но ведь задача, всё-таки - ошибки не сделать. А свои ошибки человек как правило очень хреново видит

ЦитироватьЕсли в готовом продукте есть функции или фрагменты кода которые в твоем случае не вызываются - пофиг, либо придумывай (утверждай, согласовывай) для них тест-план, либо выкидывай
Это да. Но ведь оптимизирующие компиляторы давно придуманы - если на данную функцию нет ссылки, она в продукт не попадёт.
Летать в космос необходимо. Жить - не необходимо.

ДалекийГость

ЦитироватьНо ведь задача, всё-таки - ошибки не сделать.
Это невыполнимая задача (и не только в программировании). Ошибки неизбежны. Их нужно уметь обнаруживать и исправлять.

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

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

ДмитрийК

Цитировать
ЦитироватьЕсли в готовом продукте есть функции или фрагменты кода которые в твоем случае не вызываются - пофиг, либо придумывай (утверждай, согласовывай) для них тест-план, либо выкидывай
Это да. Но ведь оптимизирующие компиляторы давно придуманы - если на данную функцию нет ссылки, она в продукт не попадёт.
Я специально упомянул о фрагментах кода. Например if который никогда не срабатывает или неиспользуемый case в операторе switch. Важно что есть исходный код не покрытый тестами. А значит неизвестно что он может натворить если на него попадет управление. А что оно туда никак не попадет - это еще доказать надо, теорему Тьюринга никто не отменял.
Пример из жизни, называется как правильно подкладывать грабли: Некий протокол обмена с устройством на базе ASCII, половина чисел в 10ой системе, половина в 16ой с префиксом 0x. Лень разбираться где что и как, везде использую библиотечную функцию strtol(), все работает. Но вот только эта сцу^H^H^H функция еще и 8ую систему понимает. Т.е. 0100 интерпретируется как 64. Но в документации на протокол это не отражено! Там вообще синтаксис для целых чисел дан весьма расплывчато, подразумевается что все и так всё понимают. А править и утверждать ради этого новую версию (с переводом на японский и обратно) - оно того не стоит, не ракету делаем в конце концов :)

ДмитрийК

ЦитироватьЖелезо развивается так, что профессиональное владение им и софтом для уже давно становится не актуальным (для прикладных программ). Ну будет код в три раза объемней и/или медленней. Ну и ладно, никому не мешает. Перешли же с ассемблера на языки высокого уровня.
Я эту мантру слышу уже много лет. Во многих случаях так и есть. Но не во всех.
Наверное мне повезло, я работаю в уникальном месте, вот только мы 2 месяца потратили чтобы выжать лишние 10-15% (и оно того стоило). И то что происходит у процессора на шине во время критического цикла я наблюдал с большим интересом. При этом мы не луддиты, все написано на нормальном Ц, на ассемблере только отдельные команды которые компилятор не знает, и те аккуратно обернутые в inline-функции. Основная оптимизация как раз происходит на этапе перевода алгоритма в код. Разумеется следующая версия должна работать быстрее и на более дешевом железе :)
А в другом проекте мне пришлось по-бырому изучить/вспомнить SSE2/3/4 - тоже о чем-то говорит.

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

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

PyKaB

ЦитироватьПрограммисты работающие по СУБД должны сделать программу универсальной и гибкой

Это кто Вам сказал? Нагрузки на СУБД очень большие. Я бы даже сказал, что нагрузки на СУБД являются определяющими для highload проектов со всеми вытекающими. Вы все еще думаете не так? Спросите у гугла зачем он разрабатывает себе собственную СУБД. Мне кажется надежность все системы гугла переплюнет любые КА и их СУБД в том числе или Вы видели неработающий google.com?

LRV_75

ЦитироватьМне кажется надежность все системы гугла переплюнет любые КА и их СУБД в том числе или Вы видели неработающий google.com?
Всё верно. А всё почему? Гугл денги зарабатывает, а предприятия на которых разрабатывают софт для КА деньги осваивают. Почувствуйте разницу
Главное не наличие проблем, главное способность их решать.
У каждой ошибки есть Имя и Фамилия