ЦитироватьЦитироватьДля этого надо либо тактовый генератор, полный отстой, либо оооочень в притык.
Обычно на сторожевом таймере стоит RC-генератор с точностью +/- лапоть (даже без термо компенсации как на основном тактирущем).
То что в АМС есть тактирование от RC в это верится с трудом, А уж в RC без термо компенсации вообще не верится .
ЦитироватьТакое может стоять на детской игрушке или микроволновой печи, а не на серьезной технике.
Возьмите доку на любой современный процессор. Там именно RC-генератор без компенсации. И работает это устройство стабильнее часов ;) . Компенсированный калибруемый RC-генератор стоит как основной тактовый.
ЦитироватьЦитироватьТакое может стоять на детской игрушке или микроволновой печи, а не на серьезной технике.
Возьмите доку на любой современный процессор. Там именно RC-генератор без компенсации. И работает это устройство стабильнее часов ;) . Компенсированный калибруемый RC-генератор стоит как основной тактовый.
Как раз обычно с термокомпесацией , и стабильнее нормальных часов не работает , хотя и работает очень стабильно (Для RC), на столько стабильно что надо "оооочень в притык".
ЦитироватьЦитироватьТакое может стоять на детской игрушке или микроволновой печи, а не на серьезной технике.
Возьмите доку на любой современный процессор. Там именно RC-генератор без компенсации. И работает это устройство стабильнее часов ;) . Компенсированный калибруемый RC-генератор стоит как основной тактовый.
Вы о чем ? Не люблю я такие диалоги, ни о чем. Зачем в ватчдоге компенсируемый калибруемый RC-генератор ? Ему что, необходимо на лету менять частоту в широких пределах или обеспечивать пропорциональную реакцию в петле АУ, АПЧ ? Нет. А для изменения интервала есть программируемые WDT. Здесь же нужно просто обеспечивать контролируемый интервал без отклонений, присущих обычной RC-цепочке.
ЦитироватьТо что в АМС есть тактирование от RC в это верится с трудом, А уж в RC без термо компенсации вообще не верится .
Не общее тактирование, а тактирование сторожевого таймера. У этого блока принципиально должен быть отдельный генератор который должен работать при любых воздействиях на процессор вплоть до его разрушения. Использования кварцевых генераторов для этого блока скорее минус.
ЗЫ. Кроме того, в современных процессорах часто используют PLL-генераторы у которых в качестве ГУН-а используется перестраиваемый RC-генератор.
ЦитироватьДа и как раз недавно, сделал я одно изделие на PIC24F а нужного кварца под рукой не было, пока заказанный шел, запустил от внутреннего RC и долго думал , а надо ли мне вообще сюда кварц ставить, и это обычный, даже не промышленный микроконтроллер . Так что в RC без без термо компенсации в АМС поверю только если увижу это в официальной документации.
Правильно сделал - я еще 10 лет назад перешёл. :)
Я говорю не про основной тактовый (который у PIC- +/- 2% во всем диапазоне температур и напряжений) , а про тактовый Watchdog Timer который в том-же камне имеет период 3,4...4,6мс.
ЦитироватьТакое может стоять на детской игрушке или микроволновой печи, а не на серьезной технике.
.
Кстати, если в процессорном узле используются внешние прерывания, то для подстраховки можно использовать и программный ватчдог, отслеживающий факт прохода по программным модулям. Что и как в реалиях - зависит от многих факторов, ибо гигантизм так же вреден, как и упущения.
ЦитироватьВы о чем ? Не люблю я такие диалоги, ни о чем. Зачем в ватчдоге компенсируемый калибруемый RC-генератор ? Ему что, необходимо на лету менять частоту в широких пределах или обеспечивать пропорциональную реакцию в петле АУ, АПЧ ? Нет. А для изменения интервала есть программируемые WDT. Здесь же нужно просто обеспечивать контролируемый интервал без отклонений, присущих обычной RC-цепочке.
А теперь представь, что в ФГ стоит такой, но его период взят без запаса. Т.е. типовой цикл в программе скажем 100мс, а период WDT взять 120мс. При изменении параметров внешней среды изменится и частота тактового. И такие условия могут привести к тому, что WDT просто не даст работать процессору постоянно его пересбрасывая.
ЦитироватьЯ говорю не про основной тактовый (который у PIC- +/- 2% во всем диапазоне температур и напряжений) , а про тактовый Watchdog Timer который в том-же камне имеет период 3,4...4,6мс.
Не, ну исползовании в АМС таких приемов назавается "лохоутся по полной". Мне ка кто даже в голову не пришло . К тому же камень там используется специалный ,жаль что доки на него толком нет.
Странно... Я всегда считал, что в подобных системах кварц обязателен (ещё и подстройку иногда приходится делать при помощи триммеров). И с максимально широким температурным диапазоном. А тут... :roll:
ЦитироватьЦитироватьВы о чем ? Не люблю я такие диалоги, ни о чем. Зачем в ватчдоге компенсируемый калибруемый RC-генератор ? Ему что, необходимо на лету менять частоту в широких пределах или обеспечивать пропорциональную реакцию в петле АУ, АПЧ ? Нет. А для изменения интервала есть программируемые WDT. Здесь же нужно просто обеспечивать контролируемый интервал без отклонений, присущих обычной RC-цепочке.
А теперь представь, что в ФГ стоит такой, но его период взят без запаса. Т.е. типовой цикл в программе скажем 100мс, а период WDT взять 120мс. При изменении параметров внешней среды изменится и частота тактового. И такие условия могут привести к тому, что WDT просто не даст работать процессору постоянно его пересбрасывая.
Мы в окопах вместе вроде не были. Читайте написанное внимательно, перед тем, как писать писанину из серии глухих о бане или ломления в открытую дверь.
ЦитироватьНе, ну исползовании в АМС таких приемов назавается "лохоутся по полной". Мне ка кто даже в голову не пришло . К тому же камень там используется специалный ,жаль что доки на него толком нет.
Судя по сообщениям - жутко специальны - FPGA. Что весьма настораживает не только в плане программы, но и в плане того железа в которое эта FPGA сконфигурирована.
ЦитироватьСтранно... Я всегда считал, что в подобных системах кварц обязателен (ещё и подстройку иногда приходится делать при помощи триммеров). И с максимально широким температурным диапазоном. А тут... :roll:
Кварц в условиях вибраций менее надежный элемент чем полностью интегрированный в чип RC-генератор. Кроме того - менее живучий.
ЦитироватьЦитироватьНе, ну исползовании в АМС таких приемов назавается "лохоутся по полной". Мне ка кто даже в голову не пришло . К тому же камень там используется специалный ,жаль что доки на него толком нет.
Судя по сообщениям - жутко специальны - FPGA. Что весьма настораживает не только в плане программы, но и в плане того железа в которое эта FPGA сконфигурирована.
А вот с этим соглашусь, все наши камни меня весьма настораживают , особенно после того как я с милардовскими аналогами поработал.
ЦитироватьЗдесь же нужно просто обеспечивать контролируемый интервал без отклонений, присущих обычной RC-цепочке.
Использование в WDT RC может иметь смысл лишь в том случае, если в процессорном модуле и критически важных подсистемах также не используются кварцевые резонаторы. Я могу представить себе такую систему, даже с учетом необходимости иметь синхронно-асинхронные связи, но только не такую систему, где необходимо иметь точную привязку по времени. Что тут гадать про какие-то WDT на гуще из воздуха, в стиле совНИИ, информации как не было, так и нет.
ЦитироватьЦитироватьСтранно... Я всегда считал, что в подобных системах кварц обязателен (ещё и подстройку иногда приходится делать при помощи триммеров). И с максимально широким температурным диапазоном. А тут... :roll:
Кварц в условиях вибраций менее надежный элемент чем полностью интегрированный в чип RC-генератор. Кроме того - менее живучий.
Это ещё и от конструктивного исполнения зависит. Мы свои железяки и трясли, и били, и на центрифуге вертели. Резонаторы в SMD-корпусах - ни один ещё не отказал.
ЦитироватьЭто ещё и от конструктивного исполнения зависит. Мы свои железяки и трясли, и били, и на центрифуге вертели. Резонаторы в SMD-корпусах - ни один ещё не отказал.
Плохо трясли. Все GSM-модули запрещено мыть в ультрозвуковых ваннах по причине вероятного разрушения тех самых SMD-кварцев. Особо заметно если частота колебаний кварца близка к одной из гармоник воздействия.
ЗЫ. Лично испытывал - у меня в свое время 4 из 5 испытываемых померли с концами...
ЦитироватьА теперь представь, что в ФГ стоит такой, но его период взят без запаса. Т.е. типовой цикл в программе скажем 100мс, а период WDT взять 120мс. При изменении параметров внешней среды изменится и частота тактового. И такие условия могут привести к тому, что WDT просто не даст работать процессору постоянно его пересбрасывая.
Как то не слишком верится, что создатели были не в курсе условий среды открытого космоса и не учли этого фактора в части влияния на тактовый генератор. Такое, имхо, из области фантастики.
К тому же аппарат исправно работал уже в условиях этой самой среды открытого космоса, когда в начала передал ТМИ, из которой следовало, что все идет штатно.
ЦитироватьЯ не знаю, какие программные и аппаратные платформы используются в ФГ. Но ведь космос почти тождественен оборонным отраслям. Поэтому я бы удивился, если там используются те платформы, которые не позволяют иметь полный контроль над кодом (ПО разработки) и исполнителем кода (процессорный модуль). Любое стороннее ПО и сторонний процессор могут иметь закладки, которые обеспечат крах выполнения ПО и физическое разрушение процессора.
Про закладки не поспоришь :D
Но во первых, какая оборонная ценность ФГ? - Его наоборот был смысл открыть как можно открытее, хотя-бы из политических соображений.
А во вторых в реальной жизни есть примеры переезда высоконадежных платформ на ядро Линукс. Вот конкретно фирма ОС которой летала на Марс и стоит в куче спутниковых железяк на Земле, недавно официально перешла на использование ядра Линукс вместо самописного.
Вероятно проблема что они не могут угнаться драйверами за появлением новых железяк, и вот они пошли на такое решение, что ядро вроде как достаточно проверено, часть драйверов у них свои, и плюс дают клиенту некоторую свободу использовать чужие непроверенные драйвера.
ЦитироватьКак то не слишком верится, что создатели были не в курсе условий среды открытого космоса и не учли этого фактора в части влияния на тактовый генератор.
Вот, как раз это, уже проходили.
ЦитироватьПлохо трясли. Все GSM-модули запрещено мыть в ультрозвуковых ваннах по причине вероятного разрушения тех самых SMD-кварцев. Особо заметно если частота колебаний кварца близка к одной из гармоник воздействия.
ЗЫ. Лично испытывал - у меня в свое время 4 из 5 испытываемых померли с концами...
А зачем Ф-Г ультразвук? Разве главный вибрационный фактор - не низкочастотные колебания при выведении?
Цитировать, и стабилние часов не работает , хотя и работает очень стабильно
:shock: У нас многие часы синхронизируются от 50 герц из розетки (имхо такое) , так как уже крепко надоело поправлять время на место, убегает регулярно, хотя температура в квартире меняется мало и повода менять частоту кварца как бы нет. :( А вы стабильнее часов... 3 минуты в 2 недели, это уже надоедает.
З.Ы. а у кого там в целом городе часы начали лагать, в инете пробегало? Может просто частота в сети сильно поменялась?
ЦитироватьЦитироватьПлохо трясли. Все GSM-модули запрещено мыть в ультрозвуковых ваннах по причине вероятного разрушения тех самых SMD-кварцев. Особо заметно если частота колебаний кварца близка к одной из гармоник воздействия.
ЗЫ. Лично испытывал - у меня в свое время 4 из 5 испытываемых померли с концами...
А зачем Ф-Г ультразвук? Разве главный вибрационный фактор - не низкочастотные колебания при выведении?
Ультразвук применяют при изготовлении , для отмывки, от флюса например.
ЦитироватьЦитироватьА теперь представь, что в ФГ стоит такой, но его период взят без запаса. Т.е. типовой цикл в программе скажем 100мс, а период WDT взять 120мс. При изменении параметров внешней среды изменится и частота тактового. И такие условия могут привести к тому, что WDT просто не даст работать процессору постоянно его пересбрасывая.
Как то не слишком верится, что создатели были не в курсе условий среды открытого космоса и не учли этого фактора в части влияния на тактовый генератор. Такое, имхо, из области фантастики.
К тому же аппарат исправно работал уже в условиях этой самой среды открытого космоса, когда в начала передал ТМИ, из которой следовало, что все идет штатно.
Добавлю, что такой допуск в 20% - очень строгий. В сложной системе с многими связями нужно тогда очень фантастично точно просчитать время прохода циклов. Еще нужно учесть, что после перезагрузки по WDT пройдет немалое время инициализации и прохода по программным модулям. Вряд ли для ФГ имеет большое значение джиттер карты операций на интервал в 20 мс, даже в 200 мс. Тогда WDT настроен как обычно во многих системах - на интервал, в несколько раз превышающий максимальный интервал между импульсами active sensing.
И вообще, мы опять ничего не знаем, где проблема, в железе или софте. Про софт можно еще сказать такую мысль. Писали, что набирали чуть ли не студентов. А у нас, из-за отсталости в промышленности, нынче преобладает культ "чистого" программирования. Много "знатоков" ООП, пишущих базы данных, интернет-приложения, победителей олимпиад по программированию и прочего, совершенно оторванного от железа. Плюс желание уйти от машинного кода. Даже когда я писал код для мульти-DSP системы на асме, много лет назад, то и тогда уже многие старались взять процессор помощнее, для компенсации скорости кода компилятора, купить пакет высокоуровневого программирования и писать на Си.
В общем, я надеюсь, что в проекте ФГ работали не те самые "чистые" программисты. В таких проектах любой программист, даже пишущий часть кода, максимально абстрагированную от железа, должен нутром чувствовать, как работает вся система, на аппаратном уровне.
ЦитироватьУ нас многие часы синхронизируются от 50 герц из розетки (имхо такое) , так как уже крепко надоело поправлять время на место, убегает регулярно
Поэтому я и добавил чуть позже "нормальных часов" а то еще с ходиками сравнить можно.
ЦитироватьЦитироватьЦитироватьПлохо трясли. Все GSM-модули запрещено мыть в ультрозвуковых ваннах по причине вероятного разрушения тех самых SMD-кварцев. Особо заметно если частота колебаний кварца близка к одной из гармоник воздействия.
ЗЫ. Лично испытывал - у меня в свое время 4 из 5 испытываемых померли с концами...
А зачем Ф-Г ультразвук? Разве главный вибрационный фактор - не низкочастотные колебания при выведении?
Ультразвук применяют при изготовлении , для отмывки, от флюса например.
Ну вот и поставить кварц. И именно эту плату не мыть ультразвуком. А то странно получается: ради возможности промыть плату ультразвуком нужно отказываться от применения кварцевых резнаторов? :shock:
ЦитироватьЦитироватьЯ не знаю, какие программные и аппаратные платформы используются в ФГ. Но ведь космос почти тождественен оборонным отраслям. Поэтому я бы удивился, если там используются те платформы, которые не позволяют иметь полный контроль над кодом (ПО разработки) и исполнителем кода (процессорный модуль). Любое стороннее ПО и сторонний процессор могут иметь закладки, которые обеспечат крах выполнения ПО и физическое разрушение процессора.
Про закладки не поспоришь :D
Но во первых, какая оборонная ценность ФГ? - Его наоборот был смысл открыть как можно открытее, хотя-бы из политических соображений.
А во вторых в реальной жизни есть примеры переезда высоконадежных платформ на ядро Линукс. Вот конкретно фирма ОС которой летала на Марс и стоит в куче спутниковых железяк на Земле, недавно официально перешла на использование ядра Линукс вместо самописного.
Вероятно проблема что они не могут угнаться драйверами за появлением новых железяк, и вот они пошли на такое решение, что ядро вроде как достаточно проверено, часть драйверов у них свои, и плюс дают клиенту некоторую свободу использовать чужие непроверенные драйвера.
А что, полная документация на ФГ не помечена грифом ? При нашей любви к засекречиванию - очень может быть, что помечена. Фирма эта, которая перешла на ядро Линукс, может знать все про каждый скомпилированный байт этого ядра. И кто скажет, что она перешла на этот Линукс не на уровне концепции, мета-структур, архитектуры ? Тогда фраза "переход на Линукс" имеет совсем другой смысл.
zyxman, а название фирмы можно, с железом, а то я, поморщив лоб, ничего с возможным линуксом, не обнаружил. Разве что Бигль?
ЦитироватьЭто ещё и от конструктивного исполнения зависит. Мы свои железяки и трясли, и били, и на центрифуге вертели. Резонаторы в SMD-корпусах - ни один ещё не отказал.
Все равно нет ничего надежнее чем находящееся прямо на кристалле.
У меня были случаи когда плату заливало конденсатом и генератор внутри продолжал работать а кварцы естественно отказывали.
ЦитироватьУ нас многие часы синхронизируются от 50 герц из розетки (имхо такое) , так как уже крепко надоело поправлять время на место, убегает регулярно, хотя температура в квартире меняется мало и повода менять частоту кварца как бы нет. :( А вы стабильнее часов... 3 минуты в 2 недели, это уже надоедает.
З.Ы. а у кого там в целом городе часы начали лагать, в инете пробегало? Может просто частота в сети сильно поменялась?
Были и у меня такие часы скороходы (5 -15 мин в сутки) только проблема там была не в кварце а в микросхеме российского изготовления , которая к тактовой частоте кварца прибавляла частоту сети умноженную на количество вспышек на солнце. Искренне верю что для космоса микросхемы делают хотя бы на 2 порядка надежней, потому что если только на один то до Марса ни как не долететь.
Странно, а вот у меня микроволновка за 2000 рублей, который год, идёт минута в минуту :wink:
ЦитироватьСтранно, а вот у меня микроволновка за 2000 рублей, который год, идёт минута в минуту :wink:
Если частота сети не "плавает" то будет идти минута в минуту
ЦитироватьА теперь представь, что в ФГ стоит такой, но его период взят без запаса. Т.е. типовой цикл в программе скажем 100мс, а период WDT взять 120мс. При изменении параметров внешней среды изменится и частота тактового. И такие условия могут привести к тому, что WDT просто не даст работать процессору постоянно его пересбрасывая.
походу вы все таки игрушки обсуждаете, а не многозадачные системы реального времени
Можно посмотреть на результат работы БЦВМ на КА Ямал-100: 11 лет безотказной работы. Разработана теми-же людьми, что делали БВК для ФГ. И перестаньте мучиться с генератором. У нас их для космоса ставят с 1964 г.
ЦитироватьМожно посмотреть на результат работы БЦВМ на КА Ямал-100: 11 лет безотказной работы. Разработана теми-же людьми, что делали БВК для ФГ. И перестаньте мучиться с генератором. У нас их для космоса ставят с 1964 г.
Но всё-таки кварц или нет? :)
Конечно есть кварцевый генератор. Таких БВК сейчас много летает над нашими головами
Информации ноль. А людям хотя бы узнать, в чем проблема - в железе, не обязательно компьютерном, или в ПО. Разное ПО на одном и том же надежном процессоре даст разные результаты. Поскольку ничего не сообщают, то либо сами ничего не знают, либо знают, но не хотят озвучивать. А грубые ляпсусы в ПО гораздо тяжелее озвучивать, чем проблемы в железе станции. Отсюда и длинные дебаты о возможных проблемах в ПО и процессоре, со многими неизвестными. Хотя проблема может быть совсем в другом месте.
36 лет этим занимаюсь, а ни как привыкнуть не могу, что аппаратчиков и программистов на БВК всегда мажут одинаковой черной краской
ЦитироватьLytnev. пишет:
ЦитироватьУ нас многие часы синхронизируются от 50 герц из розетки (имхо такое)
Это совсем даже не ИМХО - в США 60Гц в розетке высокостабильные и поэтому всякие разные часы от них синхронизирующиеся совершенно рядовое явление. Естественно, на нашей электросети они безумно отстают.
Один мой товарищ даже копейку когда-то заработал на впайке в импортную электронику платок для лечения этой фичи :D
Советую Всем прочитать bruks_frederik_mificheskii_chelovekomesyac_ili_kak_sozdayutsya_programmnye_sistemy.
Это должна быть настольная книга разработчиков больших систем. Актуальность книги - история разработки программного обеспечения фирмой IBM. Уже больше 25-лет ее перечитываю перед началом сложных проектов или в запутанных ситуациях при разработке.
ЦитироватьСоветую Всем прочитать bruks_frederik_mificheskii_chelovekomesyac_ili_kak_sozdayutsya_programmnye_sistemy.
Это должна быть настольная книга разработчиков больших систем. Актуальность книги - история разработки программного обеспечения фирмой IBM. Уже бльше 25-лет ее перечитываю перед началом сложных проектов или в запутанных ситуациях при разработке.
Человека, не прочитавшего Брукса, вообще нельзя допускать до разработки ПО ближе, чем на морскую милю.
P.S. Любителям малых форм предпринимательства в космонавтике - прошу обратить внимание на то, как Bigelow завалили свои надувные проекты, а те, кто побольше, ещё живы. Пока толстый ссохнет, тонкий сдохнет.
P.P.S. Солидарен с предложениями тов.belov2018.
ЦитироватьЭто совсем даже не ИМХО - в США 60Гц в розетке высокостабильные и поэтому всякие разные часы от них синхронизирующиеся совершенно рядовое явление. Естественно, на нашей электросети они безумно отстают.
У меня недавно диск вышибло на вычислителе, в этой "высокостабильной" сети. Ощущение было, что три раза подряд дернули рубильник. Контроллер диска вздохнул и больше не проснулся.
ЦитироватьЦитироватьЭто совсем даже не ИМХО - в США 60Гц в розетке высокостабильные и поэтому всякие разные часы от них синхронизирующиеся совершенно рядовое явление. Естественно, на нашей электросети они безумно отстают.
У меня недавно диск вышибло на вычислителе, в этой "высокостабильной" сети. Ощущение было, что три раза подряд дернули рубильник. Контроллер диска вздохнул и больше не проснулся.
Китайский БП? :D
ЦитироватьЦитироватьЦитироватьЭто совсем даже не ИМХО - в США 60Гц в розетке высокостабильные и поэтому всякие разные часы от них синхронизирующиеся совершенно рядовое явление. Естественно, на нашей электросети они безумно отстают.
У меня недавно диск вышибло на вычислителе, в этой "высокостабильной" сети. Ощущение было, что три раза подряд дернули рубильник. Контроллер диска вздохнул и больше не проснулся.
Китайский БП? :D
Не знаю, не смотрел. Компутер американской фирмы Делл.
ЦитироватьЦитироватьЦитироватьЦитироватьЭто совсем даже не ИМХО - в США 60Гц в розетке высокостабильные и поэтому всякие разные часы от них синхронизирующиеся совершенно рядовое явление. Естественно, на нашей электросети они безумно отстают.
У меня недавно диск вышибло на вычислителе, в этой "высокостабильной" сети. Ощущение было, что три раза подряд дернули рубильник. Контроллер диска вздохнул и больше не проснулся.
Китайский БП? :D
Не знаю, не смотрел. Компутер американской фирмы Делл.
:!: И На Их территории? :!:
Цитировать:!: И На Их территории? :!:
Да, в Калифорнии. Вообще американские силовые сети очень изношены, по причине ограниченности финансовых средств транспортирующих компаний. Недавно по этой причине неподалеку рванул магистральный газопровод высокого давления. Прямо в жилом квартале.
Dell D600 Малазия, уже 8 лет работает. АБ почти ЁК, но жалко - работает настольным ПК :D
ЦитироватьDell D600 Малазия, уже 8 лет работает. АБ почти ЁК, но жалко - работает настольным ПК :D
Да у меня тоже такой казус впервые в практике случился. К счастью удалось спасти информацию с диска. Теперь ученый.
ЦитироватьЦитировать:!: И На Их территории? :!:
Да, в Калифорнии. Вообще американские силовые сети очень изношены, по причине ограниченности финансовых средств транспортирующих компаний. Недавно по этой причине неподалеку рванул магистральный газопровод высокого давления. Прямо в жилом квартале.
В суд - у них запись качества ЭЭ ведется! Не ошибись в ГГ.ММ.ДД.ЧЧ.МинМин.СС при указании когда! :D
ЦитироватьЦитироватьЦитировать:!: И На Их территории? :!:
Да, в Калифорнии. Вообще американские силовые сети очень изношены, по причине ограниченности финансовых средств транспортирующих компаний. Недавно по этой причине неподалеку рванул магистральный газопровод высокого давления. Прямо в жилом квартале.
В суд - у них запись качества ЭЭ ведется! Не ошибись в ГГ.ММ.ДД.ЧЧ.МинМин.СС при указании когда! :D
Ну да, ну да. На фоне переизбытка юристов и финансистов наблюдается острая нехватка электриков.
ЦитироватьУ американцев государство только создало некоторые условия для наведения порядка, а разработчики все-же договаривались сами.
Точнее, тянули эту телегу именно разработчики - генерировали варианты, договаривались, а государство как-бы со стороны обеспечивало какие-то адекватные реальности рамки этого процесса.
Это не так. На начало 70-х в США использовалось более 450 различных языков программирования высокого уровня, включая различные диалекты. Если же считать с различными ассемблерами, то цифра переваливала за 1500 языков! В 1975-м Пентагон учредил комитет HOLWG, в которую входили представители всех родов войск, а так же некоторые союзники по НАТО. Комитет формировал требования к единому языку. Военные, промышленники и просто академики изучали их и предлагали исправления или улучшения. В конце-концов родилась Ада.
А сами разработчики вряд ли договорились бы, у каждого свои интересы и каждый заинтересован в получении преимуществ над конкурентами. Не так ли?
ЦитироватьИ вообще, мы опять ничего не знаем, где проблема, в железе или софте. Про софт можно еще сказать такую мысль. Писали, что набирали чуть ли не студентов. А у нас, из-за отсталости в промышленности, нынче преобладает культ "чистого" программирования. Много "знатоков" ООП, пишущих базы данных, интернет-приложения, победителей олимпиад по программированию и прочего, совершенно оторванного от железа. Плюс желание уйти от машинного кода. Даже когда я писал код для мульти-DSP системы на асме, много лет назад, то и тогда уже многие старались взять процессор помощнее, для компенсации скорости кода компилятора, купить пакет высокоуровневого программирования и писать на Си.
В общем, я надеюсь, что в проекте ФГ работали не те самые "чистые" программисты. В таких проектах любой программист, даже пишущий часть кода, максимально абстрагированную от железа, должен нутром чувствовать, как работает вся система, на аппаратном уровне.
Подпишусь под каждым словом. Зайдите в любой холивар, там любое меряние "пиписками" неизбежно перерастает в меряние кроссплатформенности и время написания кода. То есть коммерческий взгляд на программирование. Какое уж тут может быть железо, где кроссплатформенность невозможна в принципе, а спешка вообще противопоказано? Меня как-то дружно опускали всем форумом только за то, что я садился на прерывание в обход апи винды, мол это чревато самыми не предсказуемыми последствиями :D
ЦитироватьЦитироватьЭто совсем даже не ИМХО - в США 60Гц в розетке высокостабильные и поэтому всякие разные часы от них синхронизирующиеся совершенно рядовое явление. Естественно, на нашей электросети они безумно отстают.
У меня недавно диск вышибло на вычислителе, в этой "высокостабильной" сети. Ощущение было, что три раза подряд дернули рубильник. Контроллер диска вздохнул и больше не проснулся.
У нас нормально летом 50.45Гц а зимой 49.53Гц - очевидно что часы требуют точности генератора значительно лучше 1% (что есть почти 15 минут в сутки).
Ну а насчет вашей проблемы - очень может быть что где-то поблизости оборвалась нейтраль - у нас это вообще рядовое явление.. - у меня тоже электроника с завидной периодичностью горела (кстати электроника винта сгорела, потом внешний модем, итп), пока не купил релейный стабилизатор с защитой.
ЦитироватьА у нас, из-за отсталости в промышленности, нынче преобладает культ "чистого" программирования. Много "знатоков" ООП, пишущих базы данных, интернет-приложения, победителей олимпиад по программированию и прочего, совершенно оторванного от железа. Плюс желание уйти от машинного кода. Даже когда я писал код для мульти-DSP системы на асме, много лет назад, то и тогда уже многие старались взять процессор помощнее, для компенсации скорости кода компилятора, купить пакет высокоуровневого программирования и писать на Си.
В общем, я надеюсь, что в проекте ФГ работали не те самые "чистые" программисты. В таких проектах любой программист, даже пишущий часть кода, максимально абстрагированную от железа, должен нутром чувствовать, как работает вся система, на аппаратном уровне.
Если у вас на железе работает приличная операционка, то 90 процентов взаимодействия с железом обеспечивает именно она. И ваша задача, как программиста полетного ПО - грамотно использовать функциональность ОС. Это помимо прочего уменьшит вероятность сбоя на уровне интерфейса с железом - в ОС уже вложены сотни тысяч человекочасов, и качество вам гарантируется. Если же ваше устройство простое - пожалуйста, пишите хоть на ассемблере, любовно облизывая каждый регистр и порт ввода-вывода. Но учтите, что современный С компилятор соптимизирует код существенно лучше чем вы его вручную напишете на ассемблере.
ЦитироватьУ нас нормально летом 50.45Гц а зимой 49.53Гц - очевидно что часы требуют точности генератора значительно лучше 1% (что есть почти 15 минут в сутки).
А давайте проведем эксперимент - есть у вас приличный частотомер под рукой? Померяем нестабильности и сравним :D
ЦитироватьЦитироватьА теперь представь, что в ФГ стоит такой, но его период взят без запаса. Т.е. типовой цикл в программе скажем 100мс, а период WDT взять 120мс. При изменении параметров внешней среды изменится и частота тактового. И такие условия могут привести к тому, что WDT просто не даст работать процессору постоянно его пересбрасывая.
походу вы все таки игрушки обсуждаете, а не многозадачные системы реального времени
Вот только не надо туда Виндовс пытаться засунуть. :twisted: А потом гадать чего это добро на орбите повисло на семафорах.
ЦитироватьЦитироватьУ американцев государство только создало некоторые условия для наведения порядка, а разработчики все-же договаривались сами.
Это не так. На начало 70-х в США использовалось более 450 различных языков программирования высокого уровня, включая различные диалекты. Если же считать с различными ассемблерами, то цифра переваливала за 1500 языков!
Вы сами себе противоречите.
Я говорю что СНАЧАЛА появилось 450 языков, а только ПОТОМ случилось остальное.
ЦитироватьВ 1975-м Пентагон учредил комитет HOLWG, в которую входили представители всех родов войск, а так же некоторые союзники по НАТО. Комитет формировал требования к единому языку. Военные, промышленники и просто академики изучали их и предлагали исправления или улучшения. В конце-концов родилась Ада.
Вот именно, что ПРЕДЛАГАЛИ, а у нас нету 450 стандартов и никто НЕ предлагает свой.
Цитировать....
Но учтите, что современный С компилятор соптимизирует код существенно лучше чем вы его вручную напишете на ассемблере.
Здесь не башорг, хватит байки травить :D
ЦитироватьЦитироватьУ нас нормально летом 50.45Гц а зимой 49.53Гц - очевидно что часы требуют точности генератора значительно лучше 1% (что есть почти 15 минут в сутки).
А давайте проведем эксперимент - есть у вас приличный частотомер под рукой? Померяем нестабильности и сравним :D
Давайте откроем отдельную тему, скажем "забавы программистов дружных с паяльником".
Частотомера, который можно назвать приличным под рукой нет, но я попробую что-то придумать.
ЦитироватьЦитировать....
Но учтите, что современный С компилятор соптимизирует код существенно лучше чем вы его вручную напишете на ассемблере.
Здесь не башорг, хватит байки травить :D
Это не байки, это реальность. Глобальный анализ вам в помощь. Человеку свойственно структурировать программы, для улучшения понимания оных и уменьшения ошибок программирования. Компьютер же не ошибается. Почитайти что-нибудь про суперкомпиляцию.
ЦитироватьЕсли у вас на железе работает приличная операционка, то 90 процентов взаимодействия с железом обеспечивает именно она. И ваша задача, как программиста полетного ПО - грамотно использовать функциональность ОС. Это помимо прочего уменьшит вероятность сбоя на уровне интерфейса с железом - в ОС уже вложены сотни тысяч человекочасов, и качество вам гарантируется. Если же ваше устройство простое - пожалуйста, пишите хоть на ассемблере, любовно облизывая каждый регистр и порт ввода-вывода. Но учтите, что современный С компилятор соптимизирует код существенно лучше чем вы его вручную напишете на ассемблере.
Я не знаю, какая платформа используется в ФГ, отсюда вывод - дискутировать о компиляторе и ОС на борту ФГ я не могу. Про ассемблер - это просто иллюстрация отхода в сторону большего абстрагирования и отрыва от железа наших программистов, потому что железа производится немного. Подавляющее число тех, кто считает себя программистами, пишут коммерческие домохозяйские программы для черного ящика - PC. Эффективность компилятора, использующегося для ПО ФГ, мне неизвестна. Писать на ассемблере ПО для ФГ я бы тоже не стал, поскольку не вижу такой надобности. Время идет, скорости процессоров растут, удельная цена памяти уменьшается, и там, где раньше нужно было считать каждый такт и байт, теперь идти на такие ухищрения не нужно. А раньше из-за таких вот тактов и байт, то есть от выбора асма или языка высокого уровня, могла зависеть архитектура всего вычислительного модуля.
ЦитироватьЕсли у вас на железе работает приличная операционка, то 90 процентов взаимодействия с железом обеспечивает именно она.
:shock:
Вот квак бы не квак! Операционка железо вообще не обслуживает. Все железо обслуживают дрова. Операционка в лучшем случае обеспечивает распределение памяти и реализацию многозадачности.
ЦитироватьИ ваша задача, как программиста полетного ПО - грамотно использовать функциональность ОС. Это помимо прочего уменьшит вероятность сбоя на уровне интерфейса с железом - в ОС уже вложены сотни тысяч человекочасов, и качество вам гарантируется.
Это Вы пишите для случая софтописания под железо которое десятки лет тянет за собой хвосты тяжелого прошлого. В случаях с новой платформой для которой еще нет написанных драйверов цена "грамотно использовать функциональность ОС" стремительно направляется в корзину.
ЦитироватьА раньше из-за таких вот тактов и байт, то есть от выбора асма или языка высокого уровня, могла зависеть архитектура всего вычислительного модуля.
А еще раньше вообще стояли кулачковые командоаппараты, и никаких вам проблем со сторожевыми таймерами и языками :P
ЦитироватьЦитироватьЦитировать....
Но учтите, что современный С компилятор соптимизирует код существенно лучше чем вы его вручную напишете на ассемблере.
Здесь не башорг, хватит байки травить :D
Это не байки, это реальность. Глобальный анализ вам в помощь. Человеку свойственно структурировать программы, для улучшения понимания оных и уменьшения ошибок программирования. Компьютер же не ошибается. Почитайти что-нибудь про суперкомпиляцию.
Да, конечно, компьютер компилирует качественнее.... Но код программы в результате получается больше. Это я вам точно гарантирую как человек пишущий при необходимости программы под железо как на Асме так и на Си.
Да, теоретически можно на Си написать так-же компактно (или компактнее), но практически так не получается.
ЦитироватьЦитироватьА раньше из-за таких вот тактов и байт, то есть от выбора асма или языка высокого уровня, могла зависеть архитектура всего вычислительного модуля.
А еще раньше вообще стояли кулачковые командоаппараты, и никаких вам проблем со сторожевыми таймерами и языками :P
Скажите это Вояджерам и Пионерам. Они летят, ничего не зная о высоком искусстве ООП и очень современном продвинутом подходе к программированию. Это не та техника, где успех всенепременно обеспечивается с помощью cutting edge или около того :)
ЦитироватьЦитироватьЧеловеку свойственно структурировать программы, для улучшения понимания оных и уменьшения ошибок программирования. Компьютер же не ошибается. Почитайти что-нибудь про суперкомпиляцию.
Да, конечно, компьютер компилирует качественнее.... Но код программы в результате получается больше. Это я вам точно гарантирую как человек пишущий при необходимости программы под железо как на Асме так и на Си.
Да, теоретически можно на Си написать так-же компактно (или компактнее), но практически так не получается.
Вы таки пропустили совет почитать про суперкомпиляцию, а зря :wink:
ЦитироватьЦитироватьЦитироватьА раньше из-за таких вот тактов и байт, то есть от выбора асма или языка высокого уровня, могла зависеть архитектура всего вычислительного модуля.
А еще раньше вообще стояли кулачковые командоаппараты, и никаких вам проблем со сторожевыми таймерами и языками :P
Скажите это Вояджерам и Пионерам. Они летят, ничего не зная о высоком искусстве ООП и очень современном продвинутом подходе к программированию. Это не та техника, где успех всенепременно обеспечивается с помощью cutting edge или около того :)
А где я предлагал ООП? ООП действительно не имеет отношения к данному вопросу.
ЦитироватьЦитироватьВ случаях с новой платформой для которой еще нет написанных драйверов цена "грамотно использовать функциональность ОС" стремительно направляется в корзину.
Глубоко уважаю создателей "новых платформ", норовящих все написать с нуля, включая драйверы работы со стандартной шиной и категорически отвергающих драйверы, уже написанные для соответствующих ОСРВ производителями приборов, даже самых новейших.
"драйверы стандартной шины" обычно представлены в виде готовых (или почти готовых) библиотек. Не стоит только ради уже готовых драйверов запускать на платформе ОС.
ЗЫ. Кстати а еще часто наличие библиотек в исходниках спасает при поиске там ошибок... Т.к. чем больше я на них смотрю, тем больше ощущение, что эти драйвера пишут студенты для зачетов :( .
ЦитироватьА где я предлагал ООП? ООП действительно не имеет отношения к данному вопросу.
Тонкие различия компиляции и эффективности ОС тоже вряд ли имеют отношение. Я уверен, что миссию ФГ можно выполнить, имея в распоряжении цифровую электронику даже тридцатилетней давности. Главное, чтобы все было сделано грамотно и аккуратно, с вниманием к мелочам, и не на авось. Что в ПО, что в баках с горючим.
ЦитироватьА давайте проведем эксперимент - есть у вас приличный частотомер под рукой? Померяем нестабильности и сравним :D
Вот такой результат выдает у нас "китаец" UT81B: http://www.youtube.com/watch?v=ZRjOvwiMM8I
ЦитироватьЦитироватьА программисты в Энергии, Лавочкина, Красноярске ОС РВ, которые им предлагали как огня боятся.
Вы с программистами в Энергии давно общались? БВС РС МКС рабрает под управлением ОС WxVorks.
VxWorks
ЦитироватьЦитироватьА программисты в Энергии, Лавочкина, Красноярске ОС РВ, которые им предлагали как огня боятся.
Вы с программистами в Энергии давно общались? БВС РС МКС рабрает под управлением ОС WxVorks.
А это относится к необитаемым объектам
ЦитироватьГлавное, чтобы все было сделано грамотно и аккуратно, с вниманием к мелочам, и не на авось. Что в ПО, что в баках с горючим.
Вы знакомы с термином "тавтология" ? :D
Интересный вопрос, а как самой малой кровью можно считать частоту электросети компьютером?
В смысле так чтобы всё из хлама сделать, и паять поменьше и не слишком процессор загружать? :D
Ну вот допустим подключить 220В не проблема - есть неиспользуемый трансформатор с выходным напряжением около 6В - поделить его несложно - получим скажем 5В ~50Гц - если это пустить прямо например на ножку последовательного порта - вобщем неплохо но нужно кем-то следить за этими 50Гц (проверять их хотя-бы 200раз в секунду) и это уже будет заметная загрузка процессора.
Вообще у меня валялся комплект логики для Синклера - там есть например счетчики - может соорудить делитель частоты?
ЦитироватьИнтересный вопрос, а как самой малой кровью можно считать частоту электросети компьютером?
Сделать делитель и на LINE IN звуковухи
Уточняю вопрос: я хочу непрерывно мерять частоту сети, чтобы компьютер писал лог частоты но при этом не занимались существенно ресурсы. Например Line In занимать не могу, тк часто пользуюсь скайпом.
Вот пока возникла интересная идея: сделать чтобы по переходам через ноль запускался источник одного импульса, скажем 20мкс (на 555 это легко сделать), сам этот импульс подать в соответствующей полярности на вход данных rs232, а на порту выставить скорость 57600 - таким образом получится, что будем с частотой электросети получать на порту мусорные посылки, и просто посчитав сколько мусора пришло за какой-то период узнаем частоту - загрузка процессора будет вообще мизерная, rs232 можно спаять из дата-кабеля для мобилки.
Цитироватья хочу непрерывно мерять частоту сети,
...
часто пользуюсь скайпом.
...
Вот пока возникла интересная идея: сделать чтобы по переходам через ноль запускался источник одного импульса, скажем 20мкс (на 555 это легко сделать), сам этот импульс подать в соответствующей полярности на вход данных rs232, а на порту выставить скорость 57600 - таким образом получится, что будем с частотой электросети получать на порту мусорные посылки, и просто посчитав сколько мусора пришло за какой-то период узнаем частоту - загрузка процессора будет вообще мизерная, rs232 можно спаять из дата-кабеля для мобилки.
Исходя из вышеприведенной информации у вас или Windows, или Linux.
Ничего не получится, это не системы реального времени, а значит импульс вы будет получать с погрешностью минимум +/- одна-две миллисекунды, что составит 5-10% ошибки для 50Гц.
Предлагаю более надежный вариант: однокристалка со встроенным таймером, триггером Шмитта и контроллером последовательного порта, а также ОЗУ, ЭППЗУ или флэш-память и портом для программирования всего этого хозяйства. Ну например PIC18F46K20. Один корпус, пара резисторов на делитель, конденсатор на фильтрацию питания, разъем программирования и три вольта питания. Ну или пятивольтовый кристалл можно поискать. Программируете таймер, садите прерывание на триггер Шмитта, считаете импульсы и отсылаете через последовательный порт.
ЦитироватьНичего не получится, это не системы реального времени, а значит импульс вы будет получать с погрешностью минимум +/- одна-две миллисекунды, что составит 5-10% ошибки для 50Гц.
Это не так страшно, меряем 1000 импульсов, усредняем...
А у меня например монитор UPS частоту выдаёт, сейчас 49.9Гц.
ЦитироватьПредлагаю более надежный вариант: однокристалка со встроенным таймером, триггером Шмитта и контроллером последовательного порта, а также ОЗУ, ЭППЗУ или флэш-память и портом для программирования всего этого хозяйства. Ну например PIC18F46K20. Один корпус, пара резисторов на делитель, конденсатор на фильтрацию питания, разъем программирования и три вольта питания. Ну или пятивольтовый кристалл можно поискать. Программируете таймер, садите прерывание на триггер Шмитта, считаете импульсы и отсылаете через последовательный порт.
Здесь нигде не упоминается гальваническая развязка. Без нее в лучшем случае убьется компьютер, а в худшем - и пользователь.
ЦитироватьЦитироватьНичего не получится, это не системы реального времени, а значит импульс вы будет получать с погрешностью минимум +/- одна-две миллисекунды, что составит 5-10% ошибки для 50Гц.
Это не так страшно, меряем 1000 импульсов, усредняем...
А у меня например монитор UPS частоту выдаёт, сейчас 49.9Гц.
Ну дык, у монитора UPS как раз однокристалка этим и занимается. А усреднением мы мало что получим - скорее поймаем периодичность загрузки Windows, поскольку RS232 не гарантирует величину задержки - там есть понятие ожидания приема.
У меня тоже простейший измеритель выдает 59.9 - 60.0. Но речь то идет о более точном измерении.
ЦитироватьЗдесь нигде не упоминается гальваническая развязка. Без нее в лучшем случае убьется компьютер, а в худшем - и пользователь.
Оптоэлектронная развязка должна присутствовать на всех внешних портах ПК. Хотя конечно неплохо бы и измеритель прикрыть.
ЦитироватьОптоэлектронная развязка должна присутствовать на всех внешних портах ПК.
Разве что только в случае промышленных ПК. В бытовых персоналках развязка (трансформаторная) есть только на сетевом интерфейсе, ибо положено по стандарту. Остальные порты гальванически не развязаны.
Гм, а как же с аудиовыходом? Или это не та?
ЦитироватьГм, а как же с аудиовыходом? Или это не та?
Попробуйте подключить или выключить аудиоустройство при работающем ПК, если ПК не перегружается аудиовыход гальванически развязан. :D Были случаи, особенно у интегрированных :!:
ЦитироватьЦитироватьОптоэлектронная развязка должна присутствовать на всех внешних портах ПК.
Разве что только в случае промышленных ПК. В бытовых персоналках развязка (трансформаторная) есть только на сетевом интерфейсе, ибо положено по стандарту. Остальные порты гальванически не развязаны.
Вообще-то зависит от ПК. На многих есть. Но по сути вы правы - рисуем трансформатор с двума обмотками.
ЦитироватьГм, а как же с аудиовыходом? Или это не та?
Ну да, пожалуй, "на коленке" быстрее всего взять сетевой трансформатор 220/12, делитель и подать на вход звуковой. При частоте дискретизации 44.1 кГц погрешность будет около 0.1%, то есть примерно 0.06 Гц. Хотя я так и не понял, как это относится к БВК АМС. :)
ЦитироватьЦитироватьГм, а как же с аудиовыходом? Или это не та?
Попробуйте подключить или выключить аудиоустройство, если ПК не перегружается аудиовыход гальванически развязан. :D Были случаи, особенно у интегрированных :!:
Честно говоря, ничего не понял, но, полагаю, с моим HP Pro 3125, ничего не случится. Иначе, они бы забодались чинить.
ЦитироватьЦитироватьЦитироватьГм, а как же с аудиовыходом? Или это не та?
Попробуйте подключить или выключить аудиоустройство, если ПК не перегружается аудиовыход гальванически развязан. :D Были случаи, особенно у интегрированных :!:
Честно говоря, ничего не понял, но, полагаю, с моим HP Pro 3125, ничего не случится. Иначе, они бы забодались чинить.
При работающем! Уже поправил! :D
Цитироватьусреднением мы мало что получим - скорее поймаем периодичность загрузки Windows, поскольку RS232 не гарантирует величину задержки - там есть понятие ожидания приема.
Возникает вопрос, что именно будем мерять?
- Вы хотите именно точно мерять периоды и фиксировать все короткие выбросы?
Просто я вот этим вариантом "из г-на и палок" собирался мерять количество импульсов за несколько минут - там буферизация будет очень слабо влиять, потому что импульсов во много раз больше чем размеры буферов. Конкретно если хотим точность 0.1% нужно мерять: 16*1000/50=320секунд минимум (16 размер буфера).
Можно и час мерять и сутки - в данной постановке не проблема :wink:
ЦитироватьУ меня тоже простейший измеритель выдает 59.9 - 60.0. Но речь то идет о более точном измерении.
Насколько более точном? :D
PS А насчет однокристалки надо подумать - кварцы у меня конечно есть, но дадут-ли они метрологическую стабильность при доступном в данный момент качестве исполнения? - Все-же компьютер у меня хоть как-то калиброван и постоянно подстраивается по ntp, а однокристалку я еще не готов по ntp подстраивать - ну то есть можно, но небыстро :D
Итак, граждане-господа-товарищи, поскольку у нас уже появилась отдельная тема для обсужения аппаратно-программного обеспечения БВК, предлагаю не тереть воду в ступе заявлениями о том что хорошо когда хорошо, а плохо когда плохо, а говорить по существу. Очевидно что существуют определенные режимные ограничения на некоторые подробности, но никто не мешает быть разумно абстрактными.
Очевидно, что всех интересует вопрос увеличения надежности ПО. Также очевидно, что человек несовершенен, ошибаться ему свойственно. Ошибаются все. Вопрос в том, как организовать работу таким образом, чтобы ошибки или
1. отлавливались в момент создания программы, или
2. проще находились на этапе отладки, а также
3. парировались на этапе функционирования.
Это касается и построения аппаратной части, и выбора языка программирования, и выбора абстракций: синхронные или асинхронные, конечные автоматы или простой процедурный код.
Это моя точка зрения, но ПО должно:
1. Всегда находить решение.
2. Откатываться назад при нештатке как в аппаратуре, так и в ПО.
А главное - оно должно не мешать спасению КА.
ЦитироватьЦитироватьГлавное, чтобы все было сделано грамотно и аккуратно, с вниманием к мелочам, и не на авось. Что в ПО, что в баках с горючим.
Вы знакомы с термином "тавтология" ? :D
А как же. А вы знакомы с термином "когерентное накапливание", применительно к процессу познания и совершенствования ? :)
ЦитироватьОчевидно, что всех интересует вопрос увеличения надежности ПО. Также очевидно, что человек несовершенен, ошибаться ему свойственно. Ошибаются все. Вопрос в том, как организовать работу таким образом, чтобы ошибки или
1. отлавливались в момент создания программы, или
2. проще находились на этапе отладки, а также
3. парировались на этапе функционирования.
Это касается и построения аппаратной части, и выбора языка программирования, и выбора абстракций: синхронные или асинхронные, конечные автоматы или простой процедурный код.
Ничего особенного выдумывать не нужно. Потому что уже лет 50 существует разное ПО, на 2-3 порядка сложнее ПО ФГ, и оно работает. Все та же компетентность, четкость, прилежность, аккуратность, опыт. А то создается впечатление, что тут пишет очень много тестировщиков ПО, QA и прочее, крен в сторону.... Это все дело хорошее и нужное, но все-таки вспомогательное. Хороший инженер - генератор встроенного кода может при устремлении к пределу обойтись без проверок, а проверки без наличия кода никому не нужны.
С точки зрения практики, сказано совершенно точно
ЦитироватьВопрос в том, как организовать работу таким образом, чтобы ошибки или
1. отлавливались в момент создания программы, или
2. проще находились на этапе отладки, а также
3. парировались на этапе функционирования.
Это касается и построения аппаратной части, и выбора языка программирования, и выбора абстракций: синхронные или асинхронные, конечные автоматы или простой процедурный код.
Сразу навскидку есть совершенно очевидные вещи.
1. 100% избежать ошибок можно только в предельно простой системе.
2. любая программа должна работать под неким супервизором, желательно с аппаратной защитой памяти (и устройств ввода-вывода), чтобы супервизор ограничивал возможности программы по разрушению адресного пространства других программ, и также от супервизора ожидается восстановление некоторого "безопасного" состояния системы в случае фатальных сбоев.
Очевидно, супервизор должен быть по возможности предельно простым, либо проверенным вдоль и поперек активной промышленной эксплуатацией.
3. естественно желательно иметь такие языковые средства, которые будут минимизировать ошибки путем представления программы таким образом чтобы трудно было ошибиться. Например классика программных ошибок неавтоматическое распределение памяти, а также некорректное использование глобальных переменных и использование чужой памяти.
Я на данный момент знаю програмную систему Erlang/OTP, которая включает систему мер для высоконадежного программирования:
1. а "чистый" функциональный язык с переменными с однократной записью вообще не позволяет изменять переменные и этим избавляет от сторонних эффектов.
1.б Язык с автоматическим распределением памяти.
1.в язык построен так, что при разработке "автоматически" получается слабосвязанная система, которую легко изменять/дополнять
2.а программы функционируют в среде виртуальной машины.
2.б суперлегковесные процессы с полной изоляцией - просто в принципе нет разделяемой памяти, а взаимодействие между процессами только сообщениями.
2.в позволяет заменять модули системы прямо "на ходу" без перезапуска всей системы.
Цитироватьzyxman пишет:
ЦитироватьЯ на данный момент знаю програмную систему Erlang/OTP, которая включает систему мер для высоконадежного программирования:
1. а "чистый" функциональный язык с переменными с однократной записью вообще не позволяет изменять переменные и этим избавляет от сторонних эффектов.
1.б Язык с автоматическим распределением памяти.
1.в язык построен так, что при разработке "автоматически" получается слабосвязанная система, которую легко изменять/дополнять
2.а программы функционируют в среде виртуальной машины.
2.б суперлегковесные процессы с полной изоляцией - просто в принципе нет разделяемой памяти, а взаимодействие между процессами только сообщениями.
2.в позволяет заменять модули системы прямо "на ходу" без перезапуска всей системы.
По-моему, это уже дебри. Возьму на себя смелость утверждать, что ПО для таких аппаратов можно создавать, не пользуясь вообще такими понятиями, как многозадачность, ОС, виртуальная машина, защита и выделение памяти, и прочее. Многозадачность сама по себе не добавляет ни надежности, ни скорости, ни простоты, ни скорости реакции. Она придумана прежде всего для систем массового обслуживания и универсальных вычислительных систем, выполняющих разнородные задачи, тот же PC для кухарки. Многозадачность на одном процессорном элементе может быть сведена к выполнению циклической диаграммы с флагами событий, и эффективность с надежностью будет выше. И модули можно заменять без всяких перезапусков. Просто сейчас ПО пишется не с таким усердием, как раньше, все выше и выше по лестнице абстрагирования. Вообще тут часто предлагают не флудить, и у меня есть предложение. Писать про ПО, которое тут уже обсудили на все лады, тем, кто может назвать себя embedded applications programmer.
ЦитироватьВозьму на себя смелость утверждать, что ПО для таких аппаратов можно создавать, не пользуясь вообще такими понятиями, как многозадачность, ОС, виртуальная машина, защита и выделение памяти, и прочее.
Хотелось-бы ваши аргументы.
Многозадачность впервые была введена на больших ЭВМ для того чтобы на одной дорогой машине можно было выполнять параллельно несколько заданий, тк обычно получалось что одно задание не могло полностью загрузить все узлы ЭВМ и некоторые узлы явно простаивали. В случае АМС необходимость многозадачности вызывается как раз ограниченными вычислительными ресурсами борта.
Затем была введена защита памяти, потому что очень быстро наступили на грабли, что без защиты одна из программ могла из-за ошибки (даже без злого умысла) сорвать работу всех остальных - для АМС защита памяти еще более важна.
Смысл виртуальной машины вобщем тот-же что и языков программирования высокого уровня - в повышении уровня абстракции - человек работает с ограниченным числом сущностей, и до какой-то степени повышение сложности атомов программы позволяет увеличивать производительность программиста.
Повышение уровня абстракции вывода компилятора (для работы не с голым процессором а с виртуальной машиной) позволяет улучшать оптимизацию и тоже улучшает качество работы компилятора, тк человек который делает компилятор работает с более высокоуровневыми абстракциями лучше - и тут тоже повышение уровня абстракции улучшает качество кода и повышает вероятность успеха миссии АМС.
Я охотно допускаю, что для конкретно случая Ф-Г хватило-бы механических кулачковых программных автоматов, но вообще АМС находятся практически на переднем крае техники и сложность миссий постоянно растет, и вместе с ростом сложности миссий растет и размер и сложность программ (потому что программы уже стали составной частью техники), поэтому необходимо использовать самые современные средства разработки ПО.
PS Это всё даже если не учитывать тот момент, что разработчики АМС также косвенно влияют на уровень техники страны, тк очевидно часто занимаются не только АМС а и разработкой других высокотехнологических систем.
Единственный момент, который мне не совсем ясен - всегда ли нужно для АМС добавлять в ПО программное восстановление сбоев памяти, или для большинства миссий достаточно рассчитывать на аппаратную коррекцию ошибок, то есть считать что память "портится" реже чем случаются программные сбои.
ЦитироватьВопрос в том, как организовать работу таким образом, чтобы ошибки или
1. отлавливались в момент создания программы, или
2. проще находились на этапе отладки, а также
3. парировались на этапе функционирования
1) нужно разделять функции. Не один компьютер, который делает всё, а несколько каждый под свою узкую простую задачу. Но с возможностью заменить соседа, пусть и неоптимальным способом.
2) нормальный вылизанный язык программирования без возможности всяких изысков. пусть генерит не оптимальный, но зато безопасный код.
3) аппаратная защита на критические действия. Как в контроллерах - там битик выставь, тут выставь и только потом записать сможешь. А сразу не записал - битики сбросились.
4) дублирование не аналогичной системой, а альтернативной. Чтобы ошибки в них разные были.
Цитировать1) нужно разделять функции. Не один компьютер, который делает всё, а несколько каждый под свою узкую простую задачу. Но с возможностью заменить соседа, пусть и неоптимальным способом.
Это разумно, но так делаться скорей всего будет ограниченно, потому что один универсальный компьютер мощностью Икс как правило дешевле, легче и меньше габаритом чем N компьютеров мощностью Икс деленное на N.
Плюс программировать универсальный компьютер проще и быстрее чем узкоспециализированный.
То есть замена одного мощного универсального компьютера на несколько эквивалентных приведет к уменьшению возможностей АМС, тк всегда есть ограничения по бюджету, массе, габариту и времени.
Цитировать4) дублирование не аналогичной системой, а альтернативной. Чтобы ошибки в них разные были.
Тоже разумно - насколько я знаю, на пассажирских самолетах так и поступают (пишут, что на каждом Эйрбасе ставят компьютеры по крайней мере двух разных производителей, и ПО у них написано разными фирмами), но у них меньше ограничения по массогабариту.
То есть я думаю, что на революционные меры не пойдут из политических соображений - чтобы за те же деньги не сделать еще меньше.
А вот на небольшие изменения технологии думаю будут идти всегда.
Аппаратная защита комбинациями битиков вообще говоря не очень хорошая идея, если только она не будет реализовываться чисто программно (через виртуальную машину :wink: ), потому что такая защита очень сильно удорожит аппаратуру АМС - не удорожающими могут быть только такие меры, которые используют готовые наработки с широко растиражированной техники, например с гражданских самолетов, а лучше если есть возможность брато то что имеет миллионные тиражи в десктопах.
Язык должен быть высокого уровня, тк на низком уровне человек быстрее устает, и больше делает ошибок на тех-же объемах ТЗ.
ЦитироватьЦитироватьВозьму на себя смелость утверждать, что ПО для таких аппаратов можно создавать, не пользуясь вообще такими понятиями, как многозадачность, ОС, виртуальная машина, защита и выделение памяти, и прочее.
Хотелось-бы ваши аргументы.
Многозадачность впервые была введена на больших ЭВМ для того чтобы на одной дорогой машине можно было выполнять параллельно несколько заданий, тк обычно получалось что одно задание не могло полностью загрузить все узлы ЭВМ и некоторые узлы явно простаивали. В случае АМС необходимость многозадачности вызывается как раз ограниченными вычислительными ресурсами борта.
Затем была введена защита памяти, потому что очень быстро наступили на грабли, что без защиты одна из программ могла из-за ошибки (даже без злого умысла) сорвать работу всех остальных - для АМС защита памяти еще более важна.
Смысл виртуальной машины вобщем тот-же что и языков программирования высокого уровня - в повышении уровня абстракции - человек работает с ограниченным числом сущностей, и до какой-то степени повышение сложности атомов программы позволяет увеличивать производительность программиста.
Повышение уровня абстракции вывода компилятора (для работы не с голым процессором а с виртуальной машиной) позволяет улучшать оптимизацию и тоже улучшает качество работы компилятора, тк человек который делает компилятор работает с более высокоуровневыми абстракциями лучше - и тут тоже повышение уровня абстракции улучшает качество кода и повышает вероятность успеха миссии АМС.
Я охотно допускаю, что для конкретно случая Ф-Г хватило-бы механических кулачковых программных автоматов, но вообще АМС находятся практически на переднем крае техники и сложность миссий постоянно растет, и вместе с ростом сложности миссий растет и размер и сложность программ (потому что программы уже стали составной частью техники), поэтому необходимо использовать самые современные средства разработки ПО.
PS Это всё даже если не учитывать тот момент, что разработчики АМС также косвенно влияют на уровень техники страны, тк очевидно часто занимаются не только АМС а и разработкой других высокотехнологических систем.
В АМС нет задачи максимизировать эффективную загрузку. Многозадачность в АМС никоим образом не может увеличить эффективность использования ресурсов процессорного модуля, и это не система массового обслуживания. Защита памяти. Чтобы говорить об этом предметно, нужно знать конкретную реализацию процессорного модуля и его подсистемы памяти. Как увеличена производительность программиста (читайте - послабление для ленивых) от введения абстракций, мы видим на своих PC. Приложения, которые обязаны летать, работают медленно и очень медленно. Эти абстракции оказались нужны в первую очередь для того, чтобы заставить покупать все новые и новые PC, с большими тактовыми частотами и количеством памяти. Я хорошо помню этот переход и удивление людей, которые могли просчитать скорость работы ПО, написанного с применением старых техник и новых, с "абстракциями". За безмятежное существование программистов "абстракций" и создателей всевозможных нагромождений из протоколов и стандартов вы платите из своего кармана. Конечно, если вы сами не программист этих абстракций. Причем образовался еще и перекос в оплате труда. С абстракциями работать выгоднее, часто в несколько раз. Процессор перемалывает пустые массивы и команды, сгенерированные в угоду абстракциям, а реклама в это время призывает купить следующий N-тиум. Но к АМС это не имеет отношения. Моя мысль заключается в том, что нет большой разницы, на чем там написано. И качество ПО может быть обеспечено не каким-то особым углубленным выбором языка, подхода, платформы, тестирования, а прежде всего человеческим фактором. А вот защита от аппаратных сбоев - это уже отдельная тема. Выбор того или иного решения защиты от таких сбоев будет влиять на выбор тех самых платформ ПО и всего, что связано с софтом. Разработка АМС - не та сфера, которая двигает компьютерное железо и софт. В этой сфере как раз возможен очень консервативный подход к проектированию цифровой вычислительной системы, без излишнего увлечения абстракциями и новомодными веяниями.
У Unihorna смешались в кучу кони, люди... Зарплата, абстракции, многозадачность, реклама, и еще бог знает что. Давайте так:
Расскажите, какой проект вы довели до внедрения, на каком языке, платформе. От этой печки и будем плясать, чтобы как минимум говорить на одном языке. :D
Unispace практик и отлично понимает, о чём пишет. Всё именно так и есть. Если эти мысли кому-то кажутся странными и не очевидными, то это признак того, что Вы не имели практического опыта подобной работы со всеми вводными. Без обид, ибо неосведомлённость не порок и порицать за неё даже самого себя не нужно. Но факты - фактами. И, напротив, развитие современного ПО для ПК в виде нереального нагромождения избыточных абстракций тоже пошло по естественному пути - было редкое сочетание постоянного роста тактовой частоты, востребованности максимального быстрой разработки и быстрого и непредсказуемого роста пожеланий к новой функциональности ПО.
ЦитироватьУ Unihorna смешались в кучу кони, люди... Зарплата, абстракции, многозадачность, реклама, и еще бог знает что. Давайте так:
Расскажите, какой проект вы довели до внедрения, на каком языке, платформе. От этой печки и будем плясать, чтобы как минимум говорить на одном языке. :D
Not, Вы просто работаете в другой области и занимаетесь другими задачами. Вы (и я, и все остальные) не можете в жизни реально соприкоснуться со всем. Это невозможно. И тут не получится диалога на одном языке. Это нормально.
ЦитироватьNot, Вы просто работаете в другой области и занимаетесь другими задачами. Вы (и я, и все остальные) не можете в жизни реально соприкоснуться со всем. Это невозможно. И тут не получится диалога на одном языке. Это нормально.
Это все лирика. Давайте конкретнее. Меня интересуют высоконадежные системы. Причем надежность рассматривается с точки зрения качества алгоритмов. Качество алгоритмов включает в себя как их техническое совершенство, с точки зрения вычислительных возможностей и их устойчивости к аппаратным проблемам, так и минимизации количества ошибок.
Минимизация ошибок достигается снижением сложности их восприятия разработчиком, за счет введения абстракций типа взаимодействующих машин состояний и перехода от синхронного к синхронно-асинхронному взаимодействию. Последнее позволяет резко снизить количество состояний системы и полноценно использовать методы формальной верификации (не путать с тестированием). Последнее - шаг на пути автоматизированного программирования, когда человек с помощью компьютера ОДНОЗНАЧНО ставит задачу, а компьютер, используя некоторую базу знаний оптимально строит программу для имеющегося в наличии железа.
Именно это я имел ввиду, когда предлагал уточнить предметную область. Пока что я вижу пространные рассуждения на тему программирования на ассемблере идеальным инженером, не допускающим (вследствие своей идеальности) ошибок, что по определению невозможно. Это сфероконь в вакууме.
"Если отладка - процесс удаления ошибок, то программирование должно быть процессом их внесения" - Эдгар Дейкстра.
Если вы себя ставите выше Дейсктры - то извольте объясниться.
Вы представить научно-профессорской среды :) А, как инженер, скажу такое. Работаю по основной работе в области разработки ПО для персональных компьютеров, а по совместительству связан с бортовым ПО оптического прибора ориентации. И действительно, и там и там (!) сейчас у нас нет технологических средств обеспечения надёжности того, что мы пишем. Иногда приходится говорить это начальству, оправдываясь за свои промахи. Иногда в особо сложных случаях приходится говорить ему и то, что, мол, если не веришь в это, то ищи тех, кто владеет такими технологическими средствами или просто пишет без ошибок. Действует, ибо нормальное начальство каким-то внутренним чутьем знает, что не найдёт того, чего не существует. А глупое начальство в крайнем случае пусть пробует, не грозит ничем, ибо инженер-программист-практик в Москве находит работу за неделю. Но, тем не менее, сама по себе проблема-то есть!
Единственное, что сейчас улучшает ситуацию, это грамотность, опыт и внутренняя самодисциплина разработчика и обширные испытания системы в целом. Но это, увы, не гарантирует ничего!
Появление какого-то технологического способа обеспечения надёжности было бы великим прорывом. Как, например, можно сколь угодно долго вчитываться в текст программы, но не сможешь гарантировать, что там нет синтаксических ошибок. А успешная компиляция программы надёжно говорит о том, что синтаксических ошибок нет. Т. е., компилятор технологически гарантирует выявление синтаксических ошибок. А вот с логическими это не так.
И в свете этого - далее. Если Вы решили научно заняться этим вопросом ("Меня интересуют высоконадежные системы. Причем надежность рассматривается с точки зрения качества алгоритмов. Качество алгоритмов включает в себя как их техническое совершенство, с точки зрения вычислительных возможностей и их устойчивости к аппаратным проблемам, так и минимизации количества ошибок..."), то это похвальное дело. Но не спрашивайте у инженеров-практиков, как решить эту Вашу задачу! Ибо наука идёт впереди всего. А инженерное использование её достижений - это вторая ступень. Тут Вы должны предложить нам решение этой проблемы! А мы проверим это на практике и, если даст эффект, то будем использовать. Образно говоря, Вы пытаетесь узнать у каменщиков, как повысить прочность кирпичей и их долговечность. Каменщик вам либо напрямую скажет, что не знает, или станет объяснять, как он старается повысить прочность и долговечность возводимой им стены из имеющихся кирпичей (класть надо аккуратно и т. п. :)), что не является ответом на Ваш вопрос.
Таким образом, суть спора в том, что Вы поднимаете вопрос о технологическом механизме обеспечения надёжности алгоритмов в научной постановке. Ибо на сегодняшний день такого механизма нет. А практики пытаются вам объяснить, что они могут сделать имеющимися у них средствами. Это явно не о том, и Вы на них обижаетесь за то, что они не могут решить Вашу задачу! Если Вы решили заниматься научными вопросами (настоящими, не имеющими решения на момент постановки!), то, прежде всего, Вы должны чётко уяснить себе тот факт, что Вам не у кого спрашивать совета! Вам предстоит открыть то, что ещё никто не знает! Ход процесса познания Вы можете обсуждать в своей среде и это может быть полезно, но любое общение со следующими уровнями работы (разработчики, пользователи и т. п.) будет, как минимум, бесполезным. А в худшем случае это может быть конфликтным - ибо может показаться, что Вы пытаетесь решить свою задачу чужими силами. Уверяю Вас, любой разработчик с практическим опытом умеет выявлять и парировать ситуации, когда его заставляют делать чужую работу, ибо на практике такое, увы иногда возникает.
По этому, в Вашей - научной постановке вопроса, Вы (!) должны предложить Нам (инженерам) решение! А мы посмотрим. А не обвинять нас в том, что мы не способны выдать Вам конкретное решение Вашей же задачи. Это, как минимум, не этично. Не выдадим, ибо нам не платят за найденную Вами для себя работу.
Для тех, кто до сих пор не открыл Америку:
http://www.nrc.gov/about-nrc/regulatory/research/digital/regs-guidance.html
(АСУ для ядерных реакторов, у нас лет на 8-10 было отставание, да и сейчас не всё переняли, иногда даже к американцам обращаются).
:roll: Каждый раз, когда я слышу, что программист или инженер способны сами обеспечить надёжность ПО, моя рука тянется ... к кнопке RESET.
Уважаемые, можете просветить: какая аппаратура сейчас применяется для отладки ПО БВК?
Так понимаю, что тот же БОКЗ ФГ на этапе отладки ПО должен эмулироваться/симулироваться аппаратно-программным комплексом. Логично, что этот комплекс должен быть разработан разработчиком этого БОКЗ.
Цитироватькак инженер, скажу такое. Работаю по основной работе в области разработки ПО для персональных компьютеров, а по совместительству связан с бортовым ПО оптического прибора ориентации. И действительно, и там и там (!) сейчас у нас нет технологических средств обеспечения надёжности того, что мы пишем.
Ужасно это читать. Причем ужасно вдвойне - с одной стороны потому что говорят "нет средств обеспечения надежности", а с другой потому что такой безумный разрыв между наукой и практикой вероятно есть только в России (не подумайте, Украину я вообще не считаю - тут просто большинство областей науки мертвы).
Я инженер. И я общаюсь с инженерами решающими задачи разработки не ПО а высоконадежных инженерных систем.
И вобщем-то я согласен с постановкой что один только язык/компилятор не решает вопрос надежности, а должна быть именно полная технология - от постановки вопроса, включая написание и отладку и вплоть до исполнения кода.
И такие технологии есть и активно практически используются. Но действительно не на десктопах, а в серверном программировании.
Конкретно читайте Erlang/OTP и Enterprise Java.
ЦитироватьУ Unihorna смешались в кучу кони, люди... Зарплата, абстракции, многозадачность, реклама, и еще бог знает что. Давайте так:
Расскажите, какой проект вы довели до внедрения, на каком языке, платформе. От этой печки и будем плясать, чтобы как минимум говорить на одном языке. :D
Я вам скажу пожестче. Когда вы получите опыт программно-аппаратной разработки цифровых систем управления и обработки реального времени, тогда и будем говорить дальше. У меня такой опыт есть, железо - от транзистора до DSP, программы - несколько асмов и несколько языков высокого уровня, плюс немалые знания об одном из самых сложных классов распределенного оборудования, где работают одновременно тысячи процессоров. Поэтому мой опыт куда ближе к созданию АМС, чем пространные мудрости тестирования ПО от сисадминов, программеров окошек и QA-товарищей. И мы по-прежнему не имеем никакой внятной информации, поэтому обсуждать, что там и кто виноват, в конкретике, пока не можем.
ЦитироватьУважаемые, можете просветить: какая аппаратура сейчас применяется для отладки ПО БВК?
Судя по тому что я читаю на этом форуме и по моему личному опыту общения с разработчиками ПО из военки, отлаживается всё это на дремучем кустарном уровне - в обычном дебаггере на ПК.
ЦитироватьТак понимаю, что тот же БОКЗ ФГ на этапе отладки ПО должен эмулироваться/симулироваться аппаратно-программным комплексом.
Не обязательно.
Я разрабатываю в том числе и ПО для астрономов. Конкретно сейчас делаю программу обработки видео с метеорами - по сути оно хоть и не то же самое что БОКЗ, но входная информация практически такая-же - работаем со звездным полем. Разница в том что БОКЗ выделяет звезды и их отождествляет, я же выделяю из разницы двух кадров наличие движущейся "звезды" и пытаюсь по каким-то критериям отфильтровать другие движущиеся объекты.
Программа отлаживается на некотором множестве видеороликов, где есть эти самые метеоры.
ЦитироватьЛогично, что этот комплекс должен быть разработан разработчиком этого БОКЗ.
НЕТ. По нормальной логике комплекс тестирования должны разработывать СОВСЕМ другие люди.
ЦитироватьРазница в том что БОКЗ выделяет звезды и их отождествляет
Здесь есть гипотезы о том, что не сработала система звездной ориентации. Меня заинтересовал принцип ее реализации. С космическими алгоритмами я не знаком, но первое, что приходит на ум - соотношение сигнал/шум превосходное (с учетом параметров сенсора, конечно), точечное изображение, то есть особых проблем быть не должно. Паттерны, проекции, вращения и корреляция. Если кому не лень написать пару наводящих строк, слов о применяющихся алгоритмах, или ссылку - буду признателен.
ЦитироватьЦитироватьРазница в том что БОКЗ выделяет звезды и их отождествляет
Здесь есть гипотезы о том, что не сработала система звездной ориентации. Меня заинтересовал принцип ее реализации. С космическими алгоритмами я не знаком, но первое, что приходит на ум - соотношение сигнал/шум превосходное (с учетом параметров сенсора, конечно), точечное изображение, то есть особых проблем быть не должно. Паттерны, проекции, вращения и корреляция. Если кому не лень написать пару наводящих строк, слов о применяющихся алгоритмах, или ссылку - буду признателен.
Она не сработает, только если крышку с объектива не снять перед установкой АМС в КГЧ РН. Астронавигация, это самая отработанная и безотказная часть конструкции и алгоритмов любого аппарата. И одна из самых простых.
ЦитироватьПаттерны, проекции, вращения и корреляция. Если кому не лень написать пару наводящих строк, слов о применяющихся алгоритмах, или ссылку - буду признателен.
Когда 20 лет назад учился, было модно все делать по http://www.bookwork.ru/book/pratt_dip , в частности http://www.tvp.ru/conferen/vsppm10/speso137.pdf
Как в данном конкретном случае реализовано - не знаю
ЦитироватьОна не сработает, только если крышку с объектива не снять перед установкой АМС в КГЧ РН. Астронавигация, это самая отработанная и безотказная часть конструкции и алгоритмов любого аппарата. И одна из самых простых.
Ну положим, крышку забыли снять или кабель прикрутить....
Так что , при этом АМС в даун уходить должна? - совсем уж глупо алгоритм БКУ составить надо было
Согласен, что дело не в БОКЗ ИМХО
zyxman.
наверное Вы меня не поняли. Имелась ввиду отладка ПО БВК. Т.е применительно к взаимодействию БОКЗ, как вариант, эмулятор должен был выглядеть так.
Раздербаненый БОКЗ на матрицу которого проецируется сгенерированная картинка участка звездного неба. И ПО такого стенда реализуют алгоритмы разрешения изображения "наоборот" - по задаваемому положению КА генерируют картинку.
Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.
ЦитироватьЦитироватьПаттерны, проекции, вращения и корреляция. Если кому не лень написать пару наводящих строк, слов о применяющихся алгоритмах, или ссылку - буду признателен.
Когда 20 лет назад учился, было модно все делать по http://www.bookwork.ru/book/pratt_dip , в частности http://www.tvp.ru/conferen/vsppm10/speso137.pdf
Как в данном конкретном случае реализовано - не знаю
Почитывал, помню, но давно, двумерное - не моя специализация. Во втором источнике весьма общо, про хорошо известное преобразование как таковое. Однако направление понятно. И тоже не вижу там алгоритмических проблем и проблем тестирования. Если железо не подвело, и ПО не писалось с нуля кое-как, то звездный датчик не первый на подозрение.
Цитироватьzyxman.
наверное Вы меня не поняли. Имелась ввиду отладка ПО БВК. Т.е применительно к взаимодействию БОКЗ, как вариант, эмулятор должен был выглядеть так.
Раздербаненый БОКЗ на матрицу которого проецируется сгенерированная картинка участка звездного неба. И ПО такого стенда реализуют алгоритмы разрешения изображения "наоборот" - по задаваемому положению КА генерируют картинку.
Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.
Уткнуть датчик через оптический переходник в дисплей с запущенной программой Google Earth :) Нет, в этом модуле никаких алгоритмических проблем быть не должно.
ЦитироватьЦитироватьzyxman.
наверное Вы меня не поняли. Имелась ввиду отладка ПО БВК. Т.е применительно к взаимодействию БОКЗ, как вариант, эмулятор должен был выглядеть так.
Раздербаненый БОКЗ на матрицу которого проецируется сгенерированная картинка участка звездного неба. И ПО такого стенда реализуют алгоритмы разрешения изображения "наоборот" - по задаваемому положению КА генерируют картинку.
Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.
Уткнуть датчик через оптический переходник в дисплей с запущенной программой Google Earth :) Нет, в этом модуле никаких алгоритмических проблем быть не должно.
Осталось понять, куда в датчик "втыкать" оптический переходник. Если моя информация корректна, то БОКЗ по запросу выдает углы ориентации относительно своей системы координат.
ЦитироватьОсталось понять, куда в датчик "втыкать" оптический переходник
Ну, это частности. Важно, что при такой симуляции задействован весь
тракт преобразования, в т.ч. соединители, математика датчика.
Как эти вещи реализованы были при отладке ПО ФГ - вот что интересно.
ЦитироватьЦитироватьОсталось понять, куда в датчик "втыкать" оптический переходник
Ну, это частности. Важно, что при такой симуляции задействован весь
тракт преобразования, в т.ч. соединители, математика датчика.
Как эти вещи реализованы были при отладке ПО ФГ - вот что интересно.
Вы не прочли вторую часть моего сообщения.
Для отработки необходима имитация паузы между запросом и ответом от БОКЗ.
Необходимо искать ОДНУ причину отказа.
Цитироватьzyxman.
наверное Вы меня не поняли. Имелась ввиду отладка ПО БВК. Т.е применительно к взаимодействию БОКЗ, как вариант, эмулятор должен был выглядеть так.
Раздербаненый БОКЗ на матрицу которого проецируется сгенерированная картинка участка звездного неба. И ПО такого стенда реализуют алгоритмы разрешения изображения "наоборот" - по задаваемому положению КА генерируют картинку.
Всё даже хуже чем я думал. Извините, мне лень писать, тем более я ничего нового не добавлю, разве что мой комментарий после текста:
ЦитироватьНаткнулся на текст журнала "Вестник ФГУП НПО им. Лавочкина" (№2 за 2009). Там есть раздел, посвященный методике тестирования алгоритмов БКУ. В частности, есть описание тестирования алгоритма ориентации КА с использованием данных БОКЗ и БИБ. Процесс сводится к периодическому двунаправленном обмену данными между программой-эмулятором показаний БОКЗ и БИБ и устройством, которые авторы называют "бортовой машиной" (БМ). Обмен производится через файлы, т.е. на одном шаге программа-эмулятор формирует файлы "в оговоренном формате" с показаниями БОКЗ и БИБ, на следующем шаге БМ формирует файл с программой воздействия на элементы системы ориентации, после чего процесс повторяется. Из этого описания видно, что комплексного эмулятора, который моделирует поведение аппарата в целом, не существовало. Есть некие тесты проверки отдельных систем, с неизвестным уровнем качества исполнения. Лично мне показалось странным использование файлового обмена для проведения процесса эмуляции. Т.е. в процессе тестирования не было обмена данными в штатном виде.
Вообще, надо сказать, сам стиль изложения материала авторами не производит никакого впечатления: какие то полулюбительские кривоватые формулировки. При описании процесса зачем то приведены имена файлов, формируемых эмулятором БОКЗ и БИБ, как будто эта информация имеет какое-то важное значение для понимания процесса тестирования. Есть и другие странные моменты. В общем, не хочу наезжать на создателей и тестировщиков, но от прочтения документа осталось тягостное впечатление.
http://www.novosti-kosmonavtiki.ru/phpBB2/viewtopic.php?p=841486#841486
а тут этот самый "вестник":
http://vestnik.laspace.ru/archives/showproduct/1/2
Мой комментарий:
Как-бы это так помягче выразиться..
Вобщем обмен через файлы проще всего организовать - любой отладчик позволяет загрузить файл в какую-то область памяти и записать какую-то область памяти в файл.
Думаю, делалось из соображений "лучше хоть так, чем совсем никак".
ЦитироватьПодозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.
Вот именно поэтому я и говорю, что стенд должен делать не разработчик БОКЗ, а третья сторона или представитель заказчика.
Ибо разработчик очевидно заинтересован продать что угодно и поэтому заинтересован и в стенде убрать невыгодные ему режимы, дабы показать свое изделие в лучшем свете, а вот заказчик заинтересован не купить абы что.
Но включать третью сторону в этот интимный процесс всё усложняет и удорожает, поэтому скорей всего всё происходит на уровне анекдота:
Цитировать- вовочка, докажи теорему Пифагора
- Богом клянусь!
И собственно, я думаю что действительно алгоритмы ЦОД там скорей всего в порядке.
А подкачать могло совсем другое - встречалось сообщение что в БОКЗ применили матрицу иностранного производства, а собственно БОКЗ это получается фотоаппарат, а у матрицы своя циклограмма работы и иностранные матрицы очевидно отличаются от отечественных, и есть ненулевая вероятность что баг в подключении матрицы и из-за этого нет картинки.
Цитироватьzyxman.
наверное Вы меня не поняли. Имелась ввиду отладка ПО БВК. Т.е применительно к взаимодействию БОКЗ, как вариант, эмулятор должен был выглядеть так.
Раздербаненый БОКЗ на матрицу которого проецируется сгенерированная картинка участка звездного неба. И ПО такого стенда реализуют алгоритмы разрешения изображения "наоборот" - по задаваемому положению КА генерируют картинку.
Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.
Дядя Вова - не у того спрашиваете :D
Он сам писал, что его личный опыт - это отладка в дебаггере.
В основной теме выкладывали ссылку на документ
http://vestnik.laspace.ru/archives/showproduct/1/2
Там есть раздел про стенды. см стр 38.
Только вот плохо, если ПО стендов пишут те же люди, что и ПО борта.
ЦитироватьДядя Вова - не у того спрашиваете :D
Он сам писал, что его личный опыт - это отладка в дебаггере.
Не вырывайте слова из контекста.
Я сказал что В ОТРАСЛИ отлаживают в дебаггере и говорю это не по чьим-то словам а по личным наблюдениям.
Я отлаживаю разными методами. Наверное практически всеми встречающимися в природе, но у вояк мой опыт применения не нашел.
Да, почитал это место в Вестнике :( Загрустил - зря читал.
ЦитироватьЯ на данный момент знаю програмную систему Erlang/OTP, которая включает систему мер для высоконадежного программирования:
Это где главный лозунг "let him crash" ?
Erlang эти инструмент под одну задачу - массовый асинхронизм.
Цитировать1. а "чистый" функциональный язык с переменными с однократной записью вообще не позволяет изменять переменные и этим избавляет от сторонних эффектов.
Тем самым требует кардинального изменения стиля написания программ. И переучивания.
Язык там обычный примитивный. Основная фича там это рантайм.
Цитировать1.б Язык с автоматическим распределением памяти.
Даёт сильный недетерминизм состояния программы.
Цитировать1.в язык построен так, что при разработке "автоматически" получается слабосвязанная система, которую легко изменять/дополнять
Связность определяется предметной областью, а не языком.
Цитировать2.а программы функционируют в среде виртуальной машины.
Кто и как будет искать баги в этой ВМ ?
Цитировать2.б суперлегковесные процессы с полной изоляцией - просто в принципе нет разделяемой памяти, а взаимодействие между процессами только сообщениями.
Любой скриптовый язык это может.
Но в любом случае придётся писать кучу низкоуровневого кода для работы с железом.
Баги прежде всего возникают от недостаточной спецификации предметной области. Тут задача больше не программиста а аналитика.
Легковесные потоки и message passing есть много где. Но не любой конечный атомат допускает читабельное разбиение на всевдо параллельные задачи. Если у нас система обработки массового количества однотипных запросов, то Erlang тут может выстрелить. Если же у нас сильно связанный конечный автомат, то тут поможет только тщательно составленная спецификация.
Что касается софта для КА, то я бы затребовал ресурсы на состояние эмулятора аппарата, который бы делала отдельная группа людей. Вопрос сопряжения софта и эмулятора - вопрос чисто технический и вполне решаем.
ЦитироватьВы представить научно-профессорской среды :)
- ведущий инженер в области декларативного ПО. Таким образом половина вашего длинного изречения про инженеров-практиков вылетает в трубу - в моем активе миллионы строк кода.
ЦитироватьТаким образом, суть спора в том, что Вы поднимаете вопрос о технологическом механизме обеспечения надёжности алгоритмов в научной постановке. Ибо на сегодняшний день такого механизма нет.
На сегодняшний день такой механизм есть. Безусловно он за вас программу не напишет, но позволит ограничить ее пространственно - временным забором, любые выходы за котороый жестко пресекаются. Это не гарантирует правильное поведение программы внутри, но сильно улучшит дело.
ЦитироватьЦитироватьУ Unihorna смешались в кучу кони, люди... Зарплата, абстракции, многозадачность, реклама, и еще бог знает что. Давайте так:
Расскажите, какой проект вы довели до внедрения, на каком языке, платформе. От этой печки и будем плясать, чтобы как минимум говорить на одном языке. :D
Я вам скажу пожестче. Когда вы получите опыт программно-аппаратной разработки цифровых систем управления и обработки реального времени, тогда и будем говорить дальше.
Еще один мастер литературного жанра. Пожестче он скажет :D Персонально я писал ядро и набор драйверов для многозадачной ОСРВ. И портировал в эту ОСРВ бортовое навигационное приложение с архитектуры 68К в архитектуру x86. Будем дальше рассуждать о роли транзистора в научно-техническом прогрессе? :wink:
ЦитироватьЦитировать1. а "чистый" функциональный язык с переменными с однократной записью вообще не позволяет изменять переменные и этим избавляет от сторонних эффектов.
Тем самым требует кардинального изменения стиля написания программ. И переучивания.
"за всё приходится платить" (с) , и изучить еще один язык небольшая плата. По опыту изучение самого языка Erlang занимает пару недель.
Вот изучение OTP, версионной системы и отладчика и вообще специфики рантайма конечно может занять значительно больше, но код человек сможет писать очень быстро и очень быстро сможет присоединиться к живому проекту.
ЦитироватьЯзык там обычный примитивный. Основная фича там это рантайм.
Я вообще-то говорил комплексно про СИСТЕМУ Erlang/OTP, и она НЕВОЗМОЖНА в отрыве от языка.
ЦитироватьЦитировать1.в язык построен так, что при разработке "автоматически" получается слабосвязанная система, которую легко изменять/дополнять
Связность определяется предметной областью, а не языком.
В случае Erlang/OTP вы автоматически будете писать слабосвязанно, ибо запрещено почти всё что дает сильные связи.
ЦитироватьЦитировать2.б суперлегковесные процессы с полной изоляцией - просто в принципе нет разделяемой памяти, а взаимодействие между процессами только сообщениями.
Любой скриптовый язык это может.
ПОЛНУЮ изоляцию НЕ ЛЮБОЙ.
Точнее проблема что вы читаете язык, а я пишу про СИСТЕМУ, в которой и ВМ и библиотеки и дебаггеры и даже собственная версионная система.
ЦитироватьБаги прежде всего возникают от недостаточной спецификации предметной области. Тут задача больше не программиста а аналитика.
Вообще-то правильно разделять программиста-математика-алгоритмиста и программиста-кодера.
Аналитик это вообще отдельный человек.
ЦитироватьЛегковесные потоки и message passing есть много где.
Но практически нигде нет полноценной изоляции процессов - в Erlang даже обращение к файлу отдельного процесса медленное, чтобы этот процесс этим обращением к файлу не забрал слишком много ресурсов у других процессов.
ЦитироватьНо не любой конечный атомат допускает читабельное разбиение на всевдо параллельные задачи.
По существу у Erlang задачи НЕ псевдо-параллельные, а реально параллельные асинхронные, потому что могут жить на физически разных машинах.
ЦитироватьЕсли у нас система обработки массового количества однотипных запросов, то Erlang тут может выстрелить. Если же у нас сильно связанный конечный автомат, то тут поможет только тщательно составленная спецификация.
Что-то вы непонятное тут говорите. Такое впечатление что вам про Erlang "Рабинович напел" :D
ЦитироватьЧто касается софта для КА, то я бы затребовал ресурсы на состояние эмулятора аппарата, который бы делала отдельная группа людей. Вопрос сопряжения софта и эмулятора - вопрос чисто технический и вполне решаем.
В смысле создание эмулятора совсем отдельной группой? - Поддерживаю.
Может не совсем в тему проблемм собственно технологических аспектов программирования, но на мое ИМХО, это на данном этапе ключевой вопрос. Вынос управления "на верх" в идеологии построения алгоритмов управления КА очевидно нарушил рационально-вероятностный принцип " не класть все яйца в одну корзину. Мотивы разработчиков для принятия подобного решения очевидны. Последствия - наглядны. Если наши представления о развитии аварии соответствуют реальности. Что не факт, на данный момент.
В какой степени эта идеология соотносится с международным опытом в идеологии конструирования АМС и как это проецируется на надежность наземной отработки железа и софта? :roll:
Мне представляются эти вопросы не праздными и в определенном смысле направляющими для дискуссии по технологическим проблемам собственно программирования ПО КА.
ЦитироватьБудем дальше рассуждать о роли транзистора в научно-техническом прогрессе? :wink:
Не будем, по причинам, уже указанным мной. Когда создадите своими руками железо, напишете для него код, характерный для систем математической обработки информации, отладите, запустите в работу, тогда будет предмет для дискуссии. Тогда вы будете видеть всю систему, железо+софт+математические алгоритмы, целиком, и не акцентировать на какой-то одной стороне. Замечу, что, строго говоря, полновесного предмета все равно не будет, потому что мы здесь не обсуждаем, кто что может. А информации от НПОЛ по-прежнему нет. Возможно, и не будет.
ЦитироватьМожет не совсем в тему проблемм собственно технологических аспектов программирования, но на мое ИМХО, это на данном этапе ключевой вопрос. Вынос управления "на верх" в идеологии построения алгоритмов управления КА очевидно нарушил рационально-вероятностный принцип " не класть все яйца в одну корзину. Мотивы разработчиков для принятия подобного решения очевидны. Последствия - наглядны. Если наши представления о развитии аварии соответствуют реальности. Что не факт, на данный момент.
В какой степени эта идеология соотносится с международным опытом в идеологии конструирования АМС и как это проецируется на надежность наземной отработки железа и софта? :roll:
Мне представляются эти вопросы не праздными и в определенном смысле направляющими для дискуссии по технологическим проблемам собственно программирования ПО КА.
Надежность софта определяется:
1. Отсутствием ошибок компилятора
2. Корректными алгоритмами, в том числе обработки ошибок, диаграммами работы, структурами данных
3. Внимательным программированием
4. Аппаратной реализацией
Тестирование софта зависит от выбранной модели, платформы.
Отсюда вывод - если считать, что программисты не занимаются п.4., а п.1. выполнен, то остаются п.2,3, которые, по чести сказать, не сильно зависят от принятой идеологии, платформ и т.п. При обеспечении п.2,3 остаются лишь вариации надежности, связанные с особенностями поведения того или иного кода-исполнителя кода при наступлении аппаратного сбоя в памяти или процессоре. А уж аппаратные ухищрения для устранения или уменьшения сбоев шин данных/команд, счетчика команд и всего контекста процессора могут быть разнообразными. От специальных кристаллов, работающих на повышенных напряжениях, до параноидальных, с ECRC, с проверкой сигнатур, матрицей размножения кода и прочая...
ЦитироватьЦитироватьЧто касается софта для КА, то я бы затребовал ресурсы на состояние эмулятора аппарата, который бы делала отдельная группа людей. Вопрос сопряжения софта и эмулятора - вопрос чисто технический и вполне решаем.
В смысле создание эмулятора совсем отдельной группой? - Поддерживаю.
Кстати, господа программисты ....
А что, стенда (электромакета) для отработки ПО не предусматривается?
А то вы все о программном да о программном, а как же отлаживать и перезакладывать ПО на улетевшую АМС (пока она на Земле хоть на ней самой тренироваться можно было)?
На НПОЛ до 10 комплектов БВК
В ОАО ИСС используется достаточно совершенная (на мой взгляд и, если они искренние, по мнению французов с Евтелсата и Аэроспасьяль) мат. модель каждого космического аппарата, включая имитаторы бортовых процессоров. ПО в них исполняется на уровне двоичного кода, который после таких проверок загружается на реальный борт.
ЦитироватьНа НПОЛ до 10 комплектов БВК
К ним еще имитаторы датчиков и исполнительных органов привязать надо ИМХО.
Сам БВК - вещь в себе. Молотит программу и все для него пучком.
А вот выдать воздействие и потом оценить реакцию всей СУ - для этого стенд нужен
ЦитироватьВ ОАО ИСС используется достаточно совершенная (на мой взгляд и, если они искренние, по мнению французов с Евтелсата и Аэроспасьяль) мат. модель каждого космического аппарата, включая имитаторы бортовых процессоров. ПО в них исполняется на уровне двоичного кода, который после таких проверок загружается на
реальный борт.
PROTEUS ? :D
А если серьезно, пмсм, проверять надо реальное железо на "аппаратных" имитаторах, обязательно. Люфты, дрейфы, забития оптики и премного тракта ни одна модель не покажет.
ЦитироватьЦитироватьНа НПОЛ до 10 комплектов БВК
К ним еще имитаторы датчиков и исполнительных органов привязать надо ИМХО.
Сам БВК - вещь в себе. Молотит программу и все для него пучком.
А вот выдать воздействие и потом оценить реакцию всей СУ - для этого стенд нужен
В ИСС так и делают при отработке системы ориентации новых КА. Есть имитаторы Солнца, Земли, приводы поворота приборов относительно них, имитатор звёздного неба для ПЗВ, поворотники для датчиков угловых скоростей и гироскопов. Всё запускается в общем контуре для отладки логики и динамики системы. Но это для новых разработок. Доработки ПО и разного рода заплатки, насколько я знаю, сейчас в основном проверяются только на программном имитаторе. Это в части системы ориентации. Про другие системы утверждать не буду.
ЦитироватьЕсли наши представления о развитии аварии соответствуют реальности. Что не факт, на данный момент.
Вот именно что не факт.
Самое главное что я могу видеть из открытых источников, что за рубежом как правило организовывают связь с АМС на всех этапах полета, или по крайней мере на всех критических этапах.
И также из открытых источников я вижу, что Ф-Г спроектирован совершенно странным образом, что с ним крайне сложно организовать связь на первом критическом этапе полета. Я про то что на низкой орбите НЕлогично использовать X-band (ЕМНИС 8ГГц), а логично было-бы использовать какие-нибудь 600МГц, тк тарелкой на X-band очень тяжело отследить быстро двигающийся объект, и плюс эта тарелка почти совершенно нетраспортабельна.
То что "почти полностью отсутствуют релейные команды", которыми можно было перезагрузить компьютер итп, вобщем-то критично, но когда нет связи релейные команды не помогут.
ЦитироватьВ какой степени эта идеология соотносится с международным опытом в идеологии конструирования АМС и как это проецируется на надежность наземной отработки железа и софта? :roll:
Международный опыт такой, что вычисления всё более активно выносят на центральный компьютер.
Но это конечно требует глубокого изменения самой технологии разработки ПО, тк одно дело то что раньше центральная БЦВМ занималась только полетом а теперь ею например фотки обрабатывают.
ЦитироватьPROTEUS ? :D
Не знаю, что это такое.
ЦитироватьЛюфты, дрейфы, забития оптики и премного тракта ни одна модель не покажет.
Модель всегда можно доработать и добавить все изменения и особенности реального аппарата. Вот доработать реальный аппарат обычно невозможно.
ЦитироватьЦитироватьPROTEUS ? :D
Не знаю, что это такое.
Ну и не надо. :)
В ИСС с отладкой и так все гуд, судя по вашим сообщениям, серьезнейший подход.
Протеус - система сквозной разработки с подсистемой моделирования электронных и механических сущностей, и возможностью добавления своих описательных моделей. Отладка , в том числе процессоров, идет довольно наглядно. Кнопочки нажимаются, светодиоды мигают, на индикаторах рисуется, регистры меняются.
ЦитироватьЦитироватьPROTEUS ? :D
Не знаю, что это такое.
Протеус феноменален - на эмулируемых устройствах Линукс запускается :D
ЦитироватьЦитироватьЛюфты, дрейфы, забития оптики и премного тракта ни одна модель не покажет.
Модель всегда можно доработать и добавить все изменения и особенности реального аппарата. Вот доработать реальный аппарат обычно невозможно.
Мда. Просто на слово поверьте, описать в модели реальное устройство на 99% достоверно- не в силах современной вычислительной мощности компьютеров. МОДЕЛЬ всегда основывается на упрощениях, граничных условиях и недопонимании реальных процессов. И это в реальной работе чаще всего выходит боком.
ЦитироватьЦитироватьМодель всегда можно доработать и добавить все изменения и особенности реального аппарата. Вот доработать реальный аппарат обычно невозможно.
Мда. Просто на слово поверьте, описать в модели реальное устройство на 99% достоверно- не в силах современной вычислительной мощности компьютеров.
Какая по вашему сейчас доступная вычислительная мощность компьютеров?
ЦитироватьМОДЕЛЬ всегда основывается на упрощениях, граничных условиях и недопонимании реальных процессов. И это в реальной работе чаще всего выходит боком.
Это логично. Но это происходит с каждым днем всё меньше от недостатка вычислительной мощности, а больше от недостатка человеческой мощности.
ЦитироватьЦитироватьЦитироватьМодель всегда можно доработать и добавить все изменения и особенности реального аппарата. Вот доработать реальный аппарат обычно невозможно.
Мда. Просто на слово поверьте, описать в модели реальное устройство на 99% достоверно- не в силах современной вычислительной мощности компьютеров.
Какая по вашему сейчас доступная вычислительная мощность компьютеров?
ЦитироватьМОДЕЛЬ всегда основывается на упрощениях, граничных условиях и недопонимании реальных процессов. И это в реальной работе чаще всего выходит боком.
Это логично. Но это происходит с каждым днем всё меньше от недостатка вычислительной мощности, а больше от недостатка человеческой мощности.
Верьте во что хотите, хоть в логику, хоть в светлый ум. Вычислительной мощности кластеров как раз хватает обсчитать поведение отдельных белковых молекул.
ЦитироватьЦитироватьЦитироватьЛюфты, дрейфы, забития оптики и премного тракта ни одна модель не покажет.
Модель всегда можно доработать и добавить все изменения и особенности реального аппарата. Вот доработать реальный аппарат обычно невозможно.
Мда. Просто на слово поверьте, описать в модели реальное устройство на 99% достоверно- не в силах современной вычислительной мощности компьютеров. МОДЕЛЬ всегда основывается на упрощениях, граничных условиях и недопонимании реальных процессов. И это в реальной работе чаще всего выходит боком.
Нет другого выхода. На стенде разрозненные механические имитаторы вращения приборов, физические имитаторы ориентиров и т. п. настолько безбожно далеки от истины, что там, по крайней мере, когда я работал (по 2004 г.) на все погрешности до 1 градуса приходилось просто не обращать внимание. Иногда раздвигая пороги в бортовом ПО и т. п. Удаётся проверять только логику и, частично, динамику, но зато в полном объеме с реальным железом. На модели все гораздо тоньше и точнее. Кроме того, при моделировании с введением шумов можно обеспечить 100% воспроизводимость результата при разных прогонах, что бывает очень важно. Лучше всего было бы, конечно, экспериментировать на реальном КА в реальном полёте, видя всё со стороны - но это невозможно. На практике, в части системы ориентации имеющаяся мат. модель давала очень хорошие, достаточные результаты. Сейчас я думаю, что стало не хуже. А при разработке приборов более детальное моделирование. Сам сейчас автор реализации мат. модели звёздного датчика 329к. Там больше упор на физику, отдельно моделируется накопление заряда каждого пикселя ПЗС с введением разного рода внешних и внутренних помех, оптика объектива и алгоритмы прибора на фоне этого. В мат. модели КА для отладки систем это не очень нужно, хотя и интересно было бы съынтегрить. Модель ценна, опять-таки тем, что имеющийся стенд настолько груб, что многое уловить просто не позволяет. Нет на реальном оборудовании, конечно же, и воспроизводимости результатов. Так же можно вводить дефекты прибора и смотреть, что будет, что на реальном приборе непросто сделать. В общем, мат. моделирование сейчас весьма полезное дело на практике, ИМХО.
Насчет скорости асемблера и компилятора. Посмотрел на код ассемблера, который производит GCC при -O3 оптимизации. Код - ето парсер. Сравнивает переменную много раз с разными стоимостями, но почему-то не держит ее в реестре, а в памяти. Уж точно етот код можно сделать в ручную немного быстрее. Хотя толку от етого, конечно, немного.
ЦитироватьЦитироватьРазница в том что БОКЗ выделяет звезды и их отождествляет
Здесь есть гипотезы о том, что не сработала система звездной ориентации. Меня заинтересовал принцип ее реализации. С космическими алгоритмами я не знаком, но первое, что приходит на ум - соотношение сигнал/шум превосходное (с учетом параметров сенсора, конечно), точечное изображение, то есть особых проблем быть не должно. Паттерны, проекции, вращения и корреляция. Если кому не лень написать пару наводящих строк, слов о применяющихся алгоритмах, или ссылку - буду признателен.
Про БОКЗ ничего не знаю.. С прибором, к которому имею отношение (новая разработка, не ИКИ) основная проблема - выделение звёзд на фоне шумов ПЗС, и, особенно, снижение влияния этих шумов на точность определения ориентации. Есть 2 подхода: в первом каждый кадр (или группа кадров) обрабатывается независимо. Выполняется поиск и обнаружение световых источников, селекция помех, распознавание звезд (по угловым расстояним между ними), определение ориентации. Во втором подходе выполняется поиск и обнаружение световых источников, селекция помех, распознавание звезд (по угловым расстояним между ними), затем переход к слежению за группой звёзд с глубокой фильтрацией шумов положения, определением ориентации, предсказанием входящих в поле зрения новых звёзд, их захватом, постановкой на слежение, накоплением точности по фильтру и подключением к определению ориентации. Достоинство второго подхода, в основном, в большей точности за счет снижения влияния шумов. Иногда можно реализовать и более частую выдачу выходной информации. Недостаток в динамическом запаздывании (из-за многокадровой фильтрации) выходных данных и, главное, в возможности длительного ложного слежения после сбоя, особенно при медленном повороте оси визирования прибора. Можно устранить периодическим повтором поиска и обнаружения. В части селекции помех важной является межкадровая обработка. Объектив прибора работает в расфокусе, формируя специальную гауссоиду рассеяния. Это делается для того, чтобы движение звёзд 'раскладывалось' на уровни яркости пикселей. Иными словами, движение точечного источника внутри пикселя обнаружить нельзя, а между пикселями будет непонятно, что. При движении пятна изменяются яркости занимаемых им пикселей, что позволяет вычислить энергетический центр с точностью, намного превышающей разрешающую способность матрицы по числу пикселей. Число пикселей на практике имеет относительно небольшое значение. Наиболее сложный момент - влияние факторов космического полёта на помехи ПЗС. Очень трудно предсказуемое дело до практического облёта. Особенно на радиационно тяжёлых орбитах. Слышал, что все зарубежные приборы сделаны чуть ли не на одной и единственной американской матрице ПЗС. Ну а мы выворачиваемся, с чем можем :(. Алгоритмы распознавания и определения ориентации просты и особых проблем не вызывают. В первом случае перебор пар звёзд по каталогу, во втором случае чистая математика. При правильных значениях на входе детерминирован правильный результат. Основная сложность, повторюсь, в селекции помех разного рода и фильтрации шумов на фоне не совсем понятной картины того, что будет происходить в действительности.
Ниже, для иллюстрации, пример 'фотографии' с ПЗС. Синтезирована в модели ПЗС на основании теории, наземных тестов, проверок в ускорителе элем. частиц. Облёт дал мало информации из-за нештатного выведения и ненормальной работы КА. 'Фото' содержит 31 звезду, 28 помех от протонов, дробовые шумы, электрические шумы, ряд экспериментальных данных по фону, неравномерность св. чувствительности пикселей, учёт темновых токов пикселей и АЦП.
(http://s013.radikal.ru/i325/1111/10/3bea0195ea5f.jpg) (http://www.radikal.ru)
Июньская публикация Лаборатории надежности ПО (JPL) - формальный анализ декларативных полетных программ (Flight rules)
http://www.havelund.com/Publications/tracecontract-ladee.pdf
ЦитироватьТо есть замена одного мощного универсального компьютера на несколько эквивалентных приведет к уменьшению возможностей АМС, тк всегда есть ограничения по бюджету, массе, габариту и времени.
лучше меньше, чем ничего.
ЦитироватьАппаратная защита комбинациями битиков вообще говоря не очень хорошая идея, если только она не будет реализовываться чисто программно
А что сложного-то? Вот надо например клапаном щёлкнуть - выставляем два активных выхода, они через "И" на ключ. А не выставили второй в заданный период - первый автоматом сбросился.
Цитироватьлучше меньше, чем ничего.
Несомненно! Но АМС всегда были, есть и будут на острие технического прогресса, так что прийдется всегда делать трудный выбор, повторять ли уже известное или делать новое и рискованное.
ЦитироватьЦитироватьАппаратная защита комбинациями битиков вообще говоря не очень хорошая идея, если только она не будет реализовываться чисто программно
А что сложного-то?
Не сложно а дорого. - В массовом и поэтому _дешевом_ железе этого не будет, потому что логика современного производства в том чтобы делать попроще и подешевле (ну нет смысла бесполезно ресурсы тратить), а специальное железо очень дорогое ввиду малого тиража, плюс ПО ведь тоже прийдется отлаживать на этом железе и оно от этого тоже станет дороже.
Ну условно, компьютер IBM RAD 6000 стоит 200000-300000$, промышленный компьютер такого уровня стоит ну пусть 2000$, а если делать совсем уникальный компьютер с такими дополнительными защитами, он будет стоить еще на пару порядков дороже чем RAD 6000.
Плюс, драйвера и ОС для RAD 6000 более-менее стандартные и уже отлаженные выше крыши применением в различных устройствах вплоть до мыльниц-роутеров, а тут всё совсем новое.
ЦитироватьПро БОКЗ ничего не знаю.. С прибором, к которому имею отношение (новая разработка, не ИКИ) основная проблема - выделение звёзд на фоне шумов ПЗС, и, особенно, снижение влияния этих шумов на точность определения ориентации.
Интересно, спасибо. Но неожиданно, я полагал, что природа звездного неба и ненужность высокой скорости захвата обеспечит высокое SNR с сенсора. Однако 35 лет назад уже работало ? А за это время процессоры стали на несколько порядков мощнее. Получается, что уж с этой подсистемой алгоритмически-математических проблем быть не должно.
В добавление к вроде глупой теории о том, что на орбите не весь ФГ, а лишь разгонное железо. А нельзя ли именно этим объяснить, что орбита снижается меньше расчетной ? Законы Ньютона помню :) Уж лучше бы он полетел.. хоть куда-нибудь :)
ЦитироватьУж лучше бы он полетел.. хоть куда-нибудь :)
Сегодня и полетит ! Я сказал. :roll:
Цитировать— Я слова заветные знаю. Земля, прощ...
:wink:
ЦитироватьЦитироватьБудем дальше рассуждать о роли транзистора в научно-техническом прогрессе? :wink:
Не будем, по причинам, уже указанным мной. Когда создадите своими руками железо, напишете для него код, характерный для систем математической обработки информации, отладите, запустите в работу, тогда будет предмет для дискуссии. Тогда вы будете видеть всю систему, железо+софт+математические алгоритмы, целиком, и не акцентировать на какой-то одной стороне. Замечу, что, строго говоря, полновесного предмета все равно не будет, потому что мы здесь не обсуждаем, кто что может. А информации от НПОЛ по-прежнему нет. Возможно, и не будет.
Да где уж нам, неучам, против гениев тавтологии. Заметит он :lol:
ЦитироватьЦитироватьzyxman.
наверное Вы меня не поняли. Имелась ввиду отладка ПО БВК. Т.е применительно к взаимодействию БОКЗ, как вариант, эмулятор должен был выглядеть так.
Раздербаненый БОКЗ на матрицу которого проецируется сгенерированная картинка участка звездного неба. И ПО такого стенда реализуют алгоритмы разрешения изображения "наоборот" - по задаваемому положению КА генерируют картинку.
Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.
Уткнуть датчик через оптический переходник в дисплей с запущенной программой Google Earth :) Нет, в этом модуле никаких алгоритмических проблем быть не должно.
Как в воду глядел - http://www.iki.rssi.ru/ofo/pdf/stand_prepr.pdf (рис.4) :D
Кста, они же БОКЗ и делали - http://ofo.ikiweb.ru/p_phobos.php
Цитировать...неожиданно, я полагал, что природа звездного неба и ненужность высокой скорости захвата обеспечит высокое SNR с сенсора. Однако 35 лет назад уже работало ? А за это время процессоры стали на несколько порядков мощнее. Получается, что уж с этой подсистемой алгоритмически-математических проблем быть не должно...
Насколько я знаю (могу далеко не всё знать), до БОКЗ, в нашей стране нынешнее НПП Геофизика-Космос для космических аппаратов НПО ПМ (ОАО ИСС) создавала только датчик полярной звезды. Использовался с 1982 г. на Гейзере. Прибор отслеживал одну звезду с использованием, фактически, небольшого телескопа, болометрического фотоприёмника и имел совершенно другую массу, потребление, по началу недостаточную помехоустойчивость к летающим вокруг КА разного рода частицам. На фоторазведывательных КА использовались по несколько подобных приборов, смотрящих на разные звёзды. Так же создавались аналогичные приборы для отслеживания заданных звёзд с ракет подводных лодок, стоят они и на известной Булаве. О проблемах с ними ничего не слышал :). Для этих приборов нет проблемы помех от частиц, ибо ракета летит с ускорением, так же достаточен очень короткий ресурс работы. В настоящее время в мире активно развивается совершенно новое направление ПЗВ: приборы с широким полем зрения на базе фотоприёмников с ПЗС, работающие по нескольким звёздам одновременно, автономно выдающие полную информацию об ориентации прибора в геоцентрической системе координат, имеющие небольшой объектив, малые габариты, массу, энергопотребление и сроки службы от 10 лет и более. В Европе их выпускает французский Sodern, у нас первыми такой прибор сделали в ИКИ (БОКЗ). Теоретически, одного такого прибора при наличии баллистической информации достаточно для создания прецизионной трёхосной системы ориентации КА. Однако, установка таких датчиков на КА представляет собой сложную проблему. Надо, чтобы в окрестность, несколько превышающую поле зрения (градусов 20 - 30 обычно), не попадали Солнце, Луна, Земля (а если орбита такая, что угловой диаметр до 120 градусов?), элементы конструкции КА, которые могут иметь большие габариты, вращаться, поворачиваться, угол м/у осью визирования приборов и направлением выхлопа всех реактивных двигателей желательно обеспечить не менее 90 град. для предотвращения загрязнения объектива, и т. п. По этому, на практике разработчики КА эти приборы не очень любят. А окупают себя они, в основном, высокой точностью определения ориентации ценой малой массы и потребления.
ЦитироватьЦитироватьЦитироватьzyxman.
наверное Вы меня не поняли. Имелась ввиду отладка ПО БВК. Т.е применительно к взаимодействию БОКЗ, как вариант, эмулятор должен был выглядеть так.
Раздербаненый БОКЗ на матрицу которого проецируется сгенерированная картинка участка звездного неба. И ПО такого стенда реализуют алгоритмы разрешения изображения "наоборот" - по задаваемому положению КА генерируют картинку.
Подозреапю, что аттестовать такой стенд будет сложнее, чем его сделать.
Уткнуть датчик через оптический переходник в дисплей с запущенной программой Google Earth :) Нет, в этом модуле никаких алгоритмических проблем быть не должно.
Как в воду глядел - http://www.iki.rssi.ru/ofo/pdf/stand_prepr.pdf (рис.4) :D
Кста, они же БОКЗ и делали - http://ofo.ikiweb.ru/p_phobos.php
Безумно кошмарный ИКИшный софт у этого стенда. Тихий ужас.
Цитировать"за всё приходится платить" (с) , и изучить еще один язык небольшая плата. По опыту изучение самого языка Erlang занимает пару недель.
Функциональные языки уже прошли бум своего развития и не оправдали больших надежд. Сейчас функциональщиков не гоняет сцаными тряпками только ленивый. Ниша функционального подхода это прежде всего всевозможные DSL, но не языки общего назначения.
ЦитироватьВот изучение OTP, версионной системы и отладчика и вообще специфики рантайма конечно может занять значительно больше, но код человек сможет писать очень быстро и очень быстро сможет присоединиться к живому проекту.
На одних только иммутабельных величинах программировать сложные алгортимны очень трудно. Это факт. Хотя теоретически это возможно.
ЦитироватьЯ вообще-то говорил комплексно про СИСТЕМУ Erlang/OTP, и она НЕВОЗМОЖНА в отрыве от языка.
Реализацию рантайма ещё надо написать и отладить. При этом скорее всего ещё ОС придётся делать. Для новой железки это неподъёмная задача. Компиляторы и ВМ вылизываются и отлаживаются десятилетиями. Такое возможно только на долгоиграющей стабильной платформе типа PC.
ЦитироватьЦитироватьСвязность определяется предметной областью, а не языком.
В случае Erlang/OTP вы автоматически будете писать слабосвязанно, ибо запрещено почти всё что дает сильные связи.
С чего бы это бы? Что мешает всю ключевую логику вбухать в один большой процесс, а вспомогательные сделать только для IO? Автоматически ничего не будет, надо заниматься декомпозицей ручками. Если уж декомпозицию удалось осущствить, то параллельные процессы так же можно разложить в произведения слабосвязанных конечных автоматов.
ЦитироватьЦитироватьЛюбой скриптовый язык это может.
ПОЛНУЮ изоляцию НЕ ЛЮБОЙ.
Нет никакой полной изоляции. Её обеспечивает рантайм, либо ОС.
ЦитироватьТочнее проблема что вы читаете язык, а я пишу про СИСТЕМУ, в которой и ВМ и библиотеки и дебаггеры и даже собственная версионная система.
А я ещё раз говорю - каким боком это относится к КА и всяким контроллерам? Откуда возмётся это сверхнадёжное ПО для какой нибуть малосерийной железки?.
ЦитироватьВообще-то правильно разделять программиста-математика-алгоритмиста и программиста-кодера.
Аналитик это вообще отдельный человек.
Аналитик это тот кто составляет ТЗ на ПО.
ЦитироватьЦитироватьЛегковесные потоки и message passing есть много где.
Но практически нигде нет полноценной изоляции процессов
Если бы это было краеугольным камнем... Это лишь мелкая фича, которая ситуацию не меняет.
Цитировать- в Erlang даже обращение к файлу отдельного процесса медленное, чтобы этот процесс этим обращением к файлу не забрал слишком много ресурсов у других процессов.
Там вообще всё медленное - язык с динамической типизацией и паттерн-матчингом. Только масштабируемость хорошая. Но это опять не для КА.
ЦитироватьЦитироватьНо не любой конечный атомат допускает читабельное разбиение на всевдо параллельные задачи.
По существу у Erlang задачи НЕ псевдо-параллельные, а реально параллельные асинхронные, потому что могут жить на физически разных машинах.
А причём тут софт КА? Такие фичи точно не нужны.
Во вторых там истинный параллелизм ограничем железом, количеством ядер. Для массового создания процессов используется как раз псевдопарраллелизм, иначе ОС быстро бы загнулась на вытесняющей многозадачности.
ЦитироватьЧто-то вы непонятное тут говорите. Такое впечатление что вам про Erlang "Рабинович напел" :D
Это среда заточенная для систем массового обслуживания. Для ПО КА её фичи малополезны.
ЦитироватьВ настоящее время в мире активно развивается совершенно новое направление ПЗВ: приборы с широким полем зрения на базе фотоприёмников с ПЗС, работающие по нескольким звёздам одновременно, автономно выдающие полную информацию об ориентации прибора в геоцентрической системе координат, имеющие небольшой объектив, малые габариты, массу, энергопотребление и сроки службы от 10 лет и более. В Европе их выпускает французский Sodern
В Европе их производит даллеко не одна компания. Потому что никак не "новое направление". Тот же Sodern делает такие датчики более 2х десятилетий. Датчики 2го поколения (о таком идет речь в данном контексте) летают уже 15 лет.
ЦитироватьОднако, установка таких датчиков на КА представляет собой сложную проблему. Надо, чтобы в окрестность, несколько превышающую поле зрения (градусов 20 - 30 обычно), не попадали Солнце, Луна, Земля
Не стоит преувеличивать. Обычно используется 2-3 датчика, при этом ослепление одновременно двух из них - редкое событие. Угол, о котором Вы пишите, у современных датчиков находится в диапазоне 15 (Луна) - 20 (Солнце) градусов.
ЦитироватьЦитироватьВ настоящее время в мире активно развивается совершенно новое направление ПЗВ: приборы с широким полем зрения на базе фотоприёмников с ПЗС, работающие по нескольким звёздам одновременно, автономно выдающие полную информацию об ориентации прибора в геоцентрической системе координат, имеющие небольшой объектив, малые габариты, массу, энергопотребление и сроки службы от 10 лет и более. В Европе их выпускает французский Sodern
В Европе их производит даллеко не одна компания. Потому что никак не "новое направление". Тот же Sodern делает такие датчики более 2х десятилетий. Датчики 2го поколения (о таком идет речь в данном контексте) летают уже 15 лет.
Да, именно так.
ЦитироватьЦитироватьОднако, установка таких датчиков на КА представляет собой сложную проблему. Надо, чтобы в окрестность, несколько превышающую поле зрения (градусов 20 - 30 обычно), не попадали Солнце, Луна, Земля
Не стоит преувеличивать. Обычно используется 2-3 датчика, при этом ослепление одновременно двух из них - редкое событие. Угол, о котором Вы пишите, у современных датчиков находится в диапазоне 15 (Луна) - 20 (Солнце) градусов.
Это полураствор - в каждую сторону от оси визирования. Полное поле зрения, допустим, у 329к, 22x17 градусов (+-11 / +-8.5). А проблема - смотря на каком КА. В отношении той темы, по которой я еще работал в ИСС, это было безумно сложно. Но о ней не буду рассказывать - насколько мутная, настолько же и закрытая тема ('Л...')
ЦитироватьЦитироватьКста, они же БОКЗ и делали - http://ofo.ikiweb.ru/p_phobos.php
Безумно кошмарный ИКИшный софт у этого стенда. Тихий ужас.
Ну, вот! О чем и говорилось - стенд есть и делал его производитель.
Использовался ли он для (или что-то подобное) для разработки - опять вопрос.
А то, что софт кошмарный - это выглядит пока как субъективное мнение. И скорее всего он не реализует обратную связь двигателей АМС (ну, не надо оно разработчику, если не вменено свыше). Т.е. как и говорили здесь - отдельная песня для отдельного хора.
Использовался для разработки БОКЗ, потом был куплен Геофизикой для своего прибора. Софт стенда написали свой от начала до конца.
ЦитироватьЦитировать"за всё приходится платить" (с) , и изучить еще один язык небольшая плата. По опыту изучение самого языка Erlang занимает пару недель.
Функциональные языки уже прошли бум своего развития и не оправдали больших надежд.
Вы бумом функциональных считаете LISP? - Не смешно? :D
ЦитироватьЦитироватьЯ вообще-то говорил комплексно про СИСТЕМУ Erlang/OTP, и она НЕВОЗМОЖНА в отрыве от языка.
Реализацию рантайма ещё надо написать и отладить. При этом скорее всего ещё ОС придётся делать. Для новой железки это неподъёмная задача. Компиляторы и ВМ вылизываются и отлаживаются десятилетиями. Такое возможно только на долгоиграющей стабильной платформе типа PC.
Вот в этом и преимущество ВМ, что ее можно вылизать и отладить даже и на PC, а потом достаточно легко перенести на другую платформу, тк вся работа там внутри одного процесса.
ОС для таких критических систем разумно делать микроядерную - она и делается быстро и тоже легко переносится на другое железо.
ЦитироватьЦитироватьЦитироватьСвязность определяется предметной областью, а не языком.
В случае Erlang/OTP вы автоматически будете писать слабосвязанно, ибо запрещено почти всё что дает сильные связи.
С чего бы это бы? Что мешает всю ключевую логику вбухать в один большой процесс, а вспомогательные сделать только для IO?
Можно и на сверхнадежной Аде все сделать через Ж.
Но разница в том, что на Erlang/OTP в отличие от Java/Modula/Ada УДОБНО писать слабосвязанно.
И в случае соблюдения УМЕРЕННО сложной технологии Erlang/OTP ГАРАНТИРУЕТ стабильные приложения. - У других сверхнадежных систем сложность технологии буквально концлагерная, почему они и не распространились, и почти никто не в состоянии полноценно соблюдать.
Я всё более убеждаюсь, что вы сами ничего на Erlang/OTP не делали, а ориентируетесь на том что "Рабинович напел".
С соседней ветки
ЦитироватьПри наземных испытаниях бортовая машина работала не более 6 часов, а потом зависала. Последнее изменение ПО произходило уже на Байконуре.
ЦитироватьНу машину делал Аргон. Довольно новая, но троированая и к ней самой по себе вопросов нет. А вот ПО разрабатывали в НПО Л. Людей, которые реально что-то писали 3,5 человека. Вполне грамотные ребята. На них давили сверху. Они просто физически не успели его отработать. Хотя просто нужно было время.
ЦитироватьЦитироватьДело в том что в бортовой машине вообше нет ОС
Получается, на ФГ нет? Синхронная схема организации вычислительного процесса? Выделенные интервалы времени на каждый пакет задач?
Что-то не верится, что при таком процессе возможно программное зависание.
Те задачи, которые обязательно должны быть выполнены, программируются на жесткую сходимость за определенное количество тактов, и им выделяется не менее этого времени.
Те, что не решились - не судьба, они не важны.
Что не так я мыслю?
ЦитироватьВот в этом и преимущество ВМ, что ее можно вылизать и отладить даже и на PC, а потом достаточно легко перенести на другую платформу, тк вся работа там внутри одного процесса.
Это не так. Помимо особенностей платформы, ещё большая вероятность изменения прикладных требований, под которые придётся всё адаптировать. Разные ОС, или их вообще нет. Разные стратегии управления ошибками, выделением памяти и т.п. Код с PC придётся сильно переписывать.
ЦитироватьОС для таких критических систем разумно делать микроядерную - она и делается быстро и тоже легко переносится на другое железо.
Ничего она не переносится. Проблема в вводе-выводе, под которые придётся писать дрова, вникая во все тонкости ОС.
ЦитироватьИ в случае соблюдения УМЕРЕННО сложной технологии Erlang/OTP ГАРАНТИРУЕТ стабильные приложения. -
Ничего оно не гарантирует. Только делает код управляемым. Так это любой интерпретатор сделает. От логических ошибок спасает только что то типа DSL да и то не 100%
avp, все-же вам "Рабинович напел".. Вы сами Erlang/OTP не пробовали.
ЦитироватьЦитироватьВот в этом и преимущество ВМ, что ее можно вылизать и отладить даже и на PC, а потом достаточно легко перенести на другую платформу, тк вся работа там внутри одного процесса.
Это не так. Помимо особенностей платформы, ещё большая вероятность изменения прикладных требований, под которые придётся всё адаптировать. Разные ОС, или их вообще нет. Разные стратегии управления ошибками, выделением памяти и т.п. Код с PC придётся сильно переписывать.
Стратегии управления ошибками, выделением памяти итп зависят не от особенностей платформы а от цели, а цель у нас одна - управляемая надежность.
ЦитироватьЦитироватьОС для таких критических систем разумно делать микроядерную - она и делается быстро и тоже легко переносится на другое железо.
Ничего она не переносится. Проблема в вводе-выводе, под которые придётся писать дрова, вникая во все тонкости ОС.
Вы сами себя понимаете? Если у нас уже есть микроядерная ОС, то во первых её тонкости минимизируются, а во вторых при переносе никаких новых тонкостей со стороны ОС не возникает.
ЦитироватьЦитироватьИ в случае соблюдения УМЕРЕННО сложной технологии Erlang/OTP ГАРАНТИРУЕТ стабильные приложения. -
Ничего оно не гарантирует. Только делает код управляемым. Так это любой интерпретатор сделает.
Нет. Не любой интерпретатор. Только ВМ заточенная на надежность позволяет управлять надежностью, и фактически кроме ВМ Erlang таковая только одна Enterprise Java.
ЦитироватьОт логических ошибок спасает только что то типа DSL да и то не 100%
Функциональные языки максимально близки к декларативным DSL, а конкретно Erlang использует синтаксис очень близкий к Prolog, который самый лучший для логики, тк самый новый и в разработке учли предыдущий опыт при этом не привязываясь к совместимости с более старыми образцами. Например известные проблемы Lisp, которые и породили точку зрения про закат интереса к функциональному подходу.
ЦитироватьС соседней ветки
ЦитироватьПри наземных испытаниях бортовая машина работала не более 6 часов, а потом зависала. Последнее изменение ПО произходило уже на Байконуре.
Ну просто страшные слова вы говорите.
Пускай источник "zorro" расскажет (если сможет), кто ездил на Байконур прожигать программы на собранном и принятом Заказчиком образце БВК.
ЦитироватьС соседней ветки
ЦитироватьПри наземных испытаниях бортовая машина работала не более 6 часов, а потом зависала. Последнее изменение ПО произходило уже на Байконуре.
Если это действительно так, то никакая формальная верификация не поможет. Это банальное 3.14 руководящих лиц. В приличных местах программист имеет права прикасаться к изделию после выдачи его в окончательное тестирование только с согласия как минимум трех ответственных лиц, просмотревших код и с визы начальства, которое за все отвечает.
ЦитироватьЦитироватьС соседней ветки
ЦитироватьПри наземных испытаниях бортовая машина работала не более 6 часов, а потом зависала. Последнее изменение ПО произходило уже на Байконуре.
Если это действительно так, то никакая формальная верификация не поможет. Это банальное 3.14 руководящих лиц. В приличных местах программист имеет права прикасаться к изделию после выдачи его в окончательное тестирование только с согласия как минимум трех ответственных лиц, просмотревших код и с визы начальства, которое за все отвечает.
Слова истинно рафинированного тестера, изолированного от железа, и не знающего, что такое процесс разработки этого железа, вместе с софтом. В курсе, что такое система remote patching, которая применяется даже на аппаратуре, от работы которой зависит в миллион раз больше, чем от ФГ ? Какие там формальные верификации, заседания и визирования, когда нужно на лету, срочно внести изменения в код, а необходимость такого изменения понимает прежде всего разработчик ? Все не ангелы, бывают ошибки, и бывает так, что ошибку, связанную с железом или софтом, заметили прямо у стапелей. Или в процессе работы техники. И которую нужно срочно исправить, скорректировав ПО. А тут вываливается хор импозантных тестеров и говорит "не трожь, мы еще формальную верификацию не завершили". Это не игрушки и картинки, это АМС, которой отправляться в космос через час. И при разработке железа, имеющего на борту софт, программист-разработчик всегда по иерархии выше, чем хоть миллион тестеров. Тестируйте дальше, только при чем тут космос и приборы ?
ЦитироватьЦитироватьЦитироватьС соседней ветки
ЦитироватьПри наземных испытаниях бортовая машина работала не более 6 часов, а потом зависала. Последнее изменение ПО произходило уже на Байконуре.
Если это действительно так, то никакая формальная верификация не поможет. Это банальное 3.14 руководящих лиц. В приличных местах программист имеет права прикасаться к изделию после выдачи его в окончательное тестирование только с согласия как минимум трех ответственных лиц, просмотревших код и с визы начальства, которое за все отвечает.
Слова истинно рафинированного тестера, изолированного от железа, и не знающего, что такое процесс разработки этого железа, вместе с софтом. В курсе, что такое система remote patching, которая применяется даже на аппаратуре, от работы которой зависит в миллион раз больше, чем от ФГ ? Какие там формальные верификации, заседания и визирования, когда нужно на лету, срочно внести изменения в код, а необходимость такого изменения понимает прежде всего разработчик ? Все не ангелы, бывают ошибки, и бывает так, что ошибку, связанную с железом или софтом, заметили прямо у стапелей. Или в процессе работы техники. И которую нужно срочно исправить, скорректировав ПО. А тут вываливается хор импозантных тестеров и говорит "не трожь, мы еще формальную верификацию не завершили". Это не игрушки и картинки, это АМС, которой отправляться в космос через час. И при разработке железа, имеющего на борту софт, программист-разработчик всегда по иерархии выше, чем хоть миллион тестеров. Тестируйте дальше, только при чем тут космос и приборы ?
Пора менять все ГОСТы ЕСПД и Информационная технология под программиста-разработчика :lol:
ЦитироватьВсе не ангелы, бывают ошибки, и бывает так, что ошибку, связанную с железом или софтом, заметили прямо у стапелей. Или в процессе работы техники. И которую нужно срочно исправить, скорректировав ПО. А тут вываливается хор импозантных тестеров и говорит "не трожь, мы еще формальную верификацию не завершили". Это не игрушки и картинки, это АМС, которой отправляться в космос через час. И при разработке железа, имеющего на борту софт, программист-разработчик всегда по иерархии выше, чем хоть миллион тестеров. Тестируйте дальше, только при чем тут космос и приборы ?
Мда. Unispace, Вы прям-таки Коноплёв современности. Нет, я не пытаюсь угадать, что Вы курите.
Рискну напомнить, что ПО предполагалось дописывать в полете совершенно официально - http://phobos.cosmos.ru/index.php?id=315&tx_ttnews[tt_news]=1954&cHash=41734d22a5896097386cc68c6b042e21
Цитировать"27 сентября будет заседание госкомиссии и 29 сентября мы собираемся отправить его ("Фобос-Грунт") на космодром", - сказал Поповкин в кулуарах Второго международного форума "Арктика - территория диалога".
По словам главы Роскосмоса, окно запуска - период, в течение которого может стартовать космический аппарат - с 5 по 20 ноября. Однако, по словам Поповкина, все планы строятся с расчетом на запуск 5 ноября.
"Потому что спутник уникальный, если возникнут какие-то замечания - чтобы мы в это окно поместились", - пояснил глава Роскосмоса. Он добавил, что следующее окно "открывается" только через два года.
"Сегодня есть уверенность, что он стартует в это окно (до 20 ноября)", - сказал глава космического агентства.
На данный момент, рассказал он, пройден практически весь цикл испытаний, отработано программное обеспечение для начального этапа полета.
"Есть проблемы по программе на следующий этап, но эти программы можем заложить в процессе полета", - сказал Поповкин.
Что такое "начальный этап полета" можно понимать по-разному :roll:
А я пожалуй "вступлюсь" за Unispace.
Я считаю что он прав с одной оговоркой - при использовании классической методологии, называемой в последнее время на жаргоне "водопад" так оно обычно и происходит: сначала идут пол года-год или даже больше проектирование ТЗ, возможно с неспешным кодингом, потом начинаются активные работы в режиме с 9 до 18, и за пару недель до сдачи обычно оказывается что ничего не готово и начинаются круглосуточные авральные работы, и всё равно сроки срываются и что-то кое-как работающее сдается в последний момент :lol:
Я лично работал практически со всеми известными методологиями, и реально скажу что "водопад" иначе быть просто не может - практически обязательно будет хоть самый минимальный аврал и уход сроков направо, либо очень жесткое урезание функциональности с потерей существенной части почти готовой работы, либо очень сырой ненадежный проект.
Очевидно что Rapid Application Development (быстрая разработка, например практикуется в разработке сайтов и десктопных приложений) в случае высоконадежных систем не пойдет.
А вот всякие разные Agile (Гибкие) методологии (похоже на идеологию современных телекомов - брать готовую систему и кусочками переделывать под новую задачу) вполне могут сработать если инструментарий достаточно для них подходит - конкретно Erlang/OTP с гибкими реально хорошо работает и получается высоконадежно.
Даже если честно, с Erlang/OTP гибкие методологии получают новый импульс для развития - практически только Erlang/OTP и Enterprise Java поддерживают возможность буквально заменять работающие блоки без перезагрузки всей системы, и на больших системах это выглядит феноменально - самое разрекламированное достижение Erlang/OTP это телефонный коммутатор British Telecom у которого за несколько лет эксплуатации было аж 0.3 секунды необслуживания клиентов - я думаю ни одна АМС до такой цифры не дотягивает.
ЦитироватьЦитироватьВсе не ангелы, бывают ошибки, и бывает так, что ошибку, связанную с железом или софтом, заметили прямо у стапелей. Или в процессе работы техники. И которую нужно срочно исправить, скорректировав ПО. А тут вываливается хор импозантных тестеров и говорит "не трожь, мы еще формальную верификацию не завершили". Это не игрушки и картинки, это АМС, которой отправляться в космос через час. И при разработке железа, имеющего на борту софт, программист-разработчик всегда по иерархии выше, чем хоть миллион тестеров. Тестируйте дальше, только при чем тут космос и приборы ?
Мда. Unispace, Вы прям-таки Коноплёв современности. Нет, я не пытаюсь угадать, что Вы курите.
Обычно сваливание в такие фразы происходит именно у тех, кто этим и озабочен. Не переносите свою жизнь на других, и не пишите в мой адрес всякий шум.
ЦитироватьПора менять все ГОСТы ЕСПД и Информационная технология под программиста-разработчика :lol:
Пора к работе подходить аккуратно и тщательно, а то скоро и советское наследие в космосе начнет проявлять несвойственные расчетным коэффициенты отказа. Главный ГОСТ должен быть в голове, у всех.
Вот датчики
(http://iki.cosmos.ru/innov/img/sd1.jpg)
(http://iki.cosmos.ru/innov/img/bokz.jpg)
ЦитироватьНу условно, компьютер IBM RAD 6000 стоит 200000-300000$, промышленный компьютер такого уровня стоит ну пусть 2000$, а если делать совсем уникальный компьютер с такими дополнительными защитами, он будет стоить еще на пару порядков дороже чем RAD 6000.
Эти защиты по отношению к компьютеру - внешние. Непосредственно в управляемой аппаратуре. И рулить ими можно с любого компа, хоть с писюка.
ЦитироватьА я пожалуй "вступлюсь" за Unispace.
Я считаю что он прав с одной оговоркой - при использовании классической методологии, называемой в последнее время на жаргоне "водопад" так оно обычно и происходит: сначала идут пол года-год или даже больше проектирование ТЗ, возможно с неспешным кодингом, потом начинаются активные работы в режиме с 9 до 18, и за пару недель до сдачи обычно оказывается что ничего не готово и начинаются круглосуточные авральные работы, и всё равно сроки срываются и что-то кое-как работающее сдается в последний момент :lol:
Да, у нас так часто и есть. К сожалению! Финальная часть работ может быть скомкана, по разным причинам. Могут выпростаться всевозможные мелкие, средние проблемы, начинается дергание. Если бы все делалось четко, согласно тем же инструкциям и правилам, то лавинообразного увеличения суеты было бы поменьше. Однако даже все инструкции не могут предусмотреть всего, поэтому и на АМС есть режим изменения кода, и такие же возможности есть на многих сложных системах. Здесь как-то уж много уделяют внимания не процессу (создание), а последующей обработке (тестирование). А при создании таких устройств, как АМС, нельзя эти процессы разделить так же лихо, как при создании прикладного ПО для компьютеров, не имеющего своей основой сложные математические алгоритмы.
ЦитироватьЭти защиты по отношению к компьютеру - внешние. Непосредственно в управляемой аппаратуре. И рулить ими можно с любого компа, хоть с писюка.
Вы имеете в виду, что в каждом исполнительном устройстве будет дешифратор этих кодовых последовательностей?
ЦитироватьЦитироватьЦитироватьС соседней ветки
ЦитироватьПри наземных испытаниях бортовая машина работала не более 6 часов, а потом зависала. Последнее изменение ПО произходило уже на Байконуре.
Если это действительно так, то никакая формальная верификация не поможет. Это банальное 3.14 руководящих лиц. В приличных местах программист имеет права прикасаться к изделию после выдачи его в окончательное тестирование только с согласия как минимум трех ответственных лиц, просмотревших код и с визы начальства, которое за все отвечает.
Слова истинно рафинированного тестера, изолированного от железа, и не знающего, что такое процесс разработки этого железа, вместе с софтом.
Я не тестер. Я ведущий разработчик, который по долгу службы имеет дело с людьми, тестирующими мой продукт. Если для вас такой подход к делу внове - значит вы никогда не работали в большой фирме, ОТВЕЧАЮЩЕЙ за качество выпускаемой продукции. Приведу вам пример: представьте, что токарь подбегает к готовому изделию, прошедшему ОТК и стоящему на старте, выкручивает болт и бежит его перетачивать, уточняя (например) качество поверхности или посадку. Это именно то, что вы предлагаете.
ЦитироватьВ курсе, что такое система remote patching, которая применяется даже на аппаратуре, от работы которой зависит в миллион раз больше, чем от ФГ ? Какие там формальные верификации, заседания и визирования, когда нужно на лету, срочно внести изменения в код, а необходимость такого изменения понимает прежде всего разработчик ? Все не ангелы, бывают ошибки, и бывает так, что ошибку, связанную с железом или софтом, заметили прямо у стапелей. Или в процессе работы техники. И которую нужно срочно исправить, скорректировав ПО.
В курсе, уважаемый. Remote patching ничем не отличается от обычной разработки и проходит такой же путь как и обычное изделие, через тестеров и ЛПР.
ЦитироватьЭто не игрушки и картинки, это АМС, которой отправляться в космос через час. И при разработке железа, имеющего на борту софт, программист-разработчик всегда по иерархии выше, чем хоть миллион тестеров. Тестируйте дальше, только при чем тут космос и приборы ?
Вы сумасшедший. Вас на десять километров нельзя подпускать к ответственной работе. Если вы (и ваша фирма) действительно ТАК подходите к делу, то очень маловероятно что у вас что-то вообще летало дальше чем за бугор. Но в реальности я честно говоря сомневаюсь, что вы вообще имеете какое либо отношение к разработке ответственного (mission critical) ПО, поскольку понятия не имеете о технологическом процессе разработки оного. Журналист, или мечтатель? :D
ЦитироватьЗдесь как-то уж много уделяют внимания не процессу (создание), а последующей обработке (тестирование).
Ну собственно суть гибких методологий в том, что вместо одного длинного цикла "проектирование->создание->доводка" делается много таких-же но коротких циклов длительностью от недели до месяца (каждый коллектив по опыту выбирает удобный период), и каждый раз в середине цикла производится уточнение ВСЕГО ТЗ (в сторону упрощения или усложнения) с учетом опыта очередной решенной задачи.
А тесты только уже инструмент, как для отладки так и для оценки (тесты позволяют судить сколько есть багов и оценивать сколько их еще осталось, и главное измерять, как меняется количество багов от сложности задачи). А главное все-же методология.
ЦитироватьА при создании таких устройств, как АМС, нельзя эти процессы разделить так же лихо, как при создании прикладного ПО для компьютеров, не имеющего своей основой сложные математические алгоритмы.
Ну вы же не хотите сказать, что ПО АМС принципиально сильносвязанная система, части которой нельзя разрабатывать по отдельности? Я думаю что насчет возможности оценки сложности (и времени создания) вы спорить не будете :D
ЦитироватьВы имеете в виду, что в каждом исполнительном устройстве будет дешифратор этих кодовых последовательностей?
Скорей даже - дублированные входящие управляющие линии.
Т.е. у нас фактически получается перенос дубляжа с аппаратного уровня наверх, чтобы он не только отказы оборудования, но и глюки софта отсеивал.
ЦитироватьЦитироватьВы имеете в виду, что в каждом исполнительном устройстве будет дешифратор этих кодовых последовательностей?
Скорей даже - дублированные входящие управляющие линии.
Т.е. у нас фактически получается перенос дубляжа с аппаратного уровня наверх, чтобы он не только отказы оборудования, но и глюки софта отсеивал.
Если я правильно понял, по существу вы добавляете к каждому устройству набор кодов вдобавок к уже имеющемуся адресу.
И по сути получается повышение надежности за счет увеличения числа разрядов адресации и уменьшения вероятности что какой-то адрес будет набран случайно.
Тут есть проблемы:
1. решается только часть глюков - остаются глюки когда программа просто не дошла до вызова устройства и свалилась или пошла не туда.
2. ставится еще одно звено между компьютером и устройством и этим понижается общая надежность.
3. драйвера отлаженные на обычных компьютерах прийдется переделывать под это и такая переделка во первых будет стоить денег а во вторых может внести новые ошибки.
- Собственно, микроядерные ОС тоже решают эту проблему похожим методом - там драйвера обычные программы и работают с устройствами не напрямую а с помощью сообщений ядру, какой бит поднять и какой опустить, и в ядре можно поставить подобные проверки программно.
Похожая система работает и в Erlang/OTP - там вообще сообщения отправляет каждый кому хочет, но при желании легко можно изощриться и средствами функционального языка легко сделать любой мыслимый по изощренности формат сообщения.
То есть с учетом наличия микроядерных ОС получается 4-я проблема, что вы пытаетесь дополнительными сущностями (которые удорожают и утяжеляют систему) решать задачу которая и так решается уже доступными средствами.
Вобщем идея конечно имеет право на жизнь, но только если у нас совсем плохо с вычислительными мощностями, что они не позволяют использовать микроядерную ОС и соответствующие программные проверки, то есть использовать для проверок НАДЕЖНЫЕ И ПРОВЕРЕННЫЕ ресурсы БВК - ОЗУ и защиту памяти.
ЦитироватьНу вы же не хотите сказать, что ПО АМС принципиально сильносвязанная система, части которой нельзя разрабатывать по отдельности? Я думаю что насчет возможности оценки сложности (и времени создания) вы спорить не будете :D
Не так, я хочу сказать, что если прибор содержит встроенное ПО, причем несущее большую специфическую математическую составляющую и сильно интегрированное с конкретным железом, то тестирование трудно отделить от разработки по иерархии, должностям, времени. Грубо говоря, тестирование часто происходит разделением инженерной, алгоритмической группы на подгруппы, с обменом.
Цитировать
Перенервничали ? :) Душ холодный примите. У меня ничего не летало, потому что я работал не в космической области. Просто работало, то железо и софт, которое было создано мной. И работает по сей день. Одна из фирм, в которой я трудился, на сегодня имеет больше 100 тысяч персонала по всему миру. Одним из важнейших условий моей работы на этой фирме было не трендеть, а обеспечивать то самое тестирование и запуск систем. На тот момент времени людей, обученных этому, было у нас в стране человек 50. Вы рассуждаете о вещах, в которых у вас просто нет опыта, это я вам уже написал. И это видно за те самые 10 км. У меня нет опыта разработки систем космических аппаратов, поэтому я тоже могу ошибаться в умозаключениях, выводах или предположениях. Но есть многие вещи, одинаковые для разработчиков любых систем, сходных с системами АМС. Мне интересно побеседовать об этом аппарате, поразмышлять о технических причинах провала миссии, а не спорить о фетише программирования и тестирования. Поэтому прошу впредь не засылать мне свой снобизм пакетами, они будут сброшены. Благо в виртуальном мире для этого не нужно тратить пакеты настоящие, мусорные.
ЦитироватьПеренервничали ? :)
Не расхохотался, увидев вот это:
ЦитироватьЭто не игрушки и картинки, это АМС, которой отправляться в космос через час.
Это нужно в анналы :D А насчет вашего послужного списка - ну трудились, да трудились. Очень правильно, что трудились. Трудиться - вообще хорошо :D
ЦитироватьЦитироватьНу вы же не хотите сказать, что ПО АМС принципиально сильносвязанная система, части которой нельзя разрабатывать по отдельности? Я думаю что насчет возможности оценки сложности (и времени создания) вы спорить не будете :D
Не так, я хочу сказать, что если прибор содержит встроенное ПО, причем несущее большую специфическую математическую составляющую и сильно интегрированное с конкретным железом, то тестирование трудно отделить от разработки по иерархии, должностям, времени.
То есть все-таки сильносвязанная система, которую не получается поделить на части декомпозицией?
- Я понимаю, что иногда в разработке ПО микроконтроллеров бывает нужно утрамбовать матобработку в какое-то ограниченное число циклов , или в ограниченный объем памяти, и там уже декомпозиция ограничивается этим.
Ну так собственно поэтому я и ратую за активное использование центральной ЦВМ, тк у нее обычно мегабайты и мегагерцы и дешевле и легче и надежнее чем в отдельных ЦВМ в каждом приборе, и есть защита памяти.
И просто всё рубится декомпозицией на маленькие субзадачи и работается. И на самых ранних этапах уже становится видно какой будет результат, и можно рано сделать какие-то телодвижения чтобы успеть если не успеваем, и нет авралов и прошивки на космодроме.
ЦитироватьГрубо говоря, тестирование часто происходит разделением инженерной, алгоритмической группы на подгруппы, с обменом.
Ну так и делается. На гражданке тоже не всегда есть возможность выделить отдельного тестировщика - я например консультировал клиента, у которого бухгалтер по совместительству занимается тестированием :D
В гибких методологиях пошли еще дальше - там есть понятие парного программирования - что один человек пишет код а другой юнит-тесты, плюс всегда код обязательно рецензируется минимум одним человеком и ничего не попадает в репозитарий кода без рецензирования.
ЦитироватьТо есть все-таки сильносвязанная система, которую не получается поделить на части декомпозицией?
- Я понимаю, что иногда в разработке ПО микроконтроллеров бывает нужно утрамбовать матобработку в какое-то ограниченное число циклов , или в ограниченный объем памяти, и там уже декомпозиция ограничивается этим.
Ну так собственно поэтому я и ратую за активное использование центральной ЦВМ, тк у нее обычно мегабайты и мегагерцы и дешевле и легче и надежнее чем в отдельных ЦВМ в каждом приборе, и есть защита памяти.
И просто всё рубится декомпозицией на маленькие субзадачи и работается. И на самых ранних этапах уже становится видно какой будет результат, и можно рано сделать какие-то телодвижения чтобы успеть если не успеваем, и нет авралов и прошивки на космодроме.
ЦитироватьГрубо говоря, тестирование часто происходит разделением инженерной, алгоритмической группы на подгруппы, с обменом.
Ну так и делается. На гражданке тоже не всегда есть возможность выделить отдельного тестировщика - я например консультировал клиента, у которого бухгалтер по совместительству занимается тестированием :D
В гибких методологиях пошли еще дальше - там есть понятие парного программирования - что один человек пишет код а другой юнит-тесты, плюс всегда код обязательно рецензируется минимум одним человеком и ничего не попадает в репозитарий кода без рецензирования.
Почему не делится, все делится. Я про другую плоскость. Неотделение создания и проверки. Потому что есть железо, АМС, узкоспециализированное, создаваемое интенсивной, а не экстенсивной работой мозгов. Поэтому в этом случае формализация мало что дает, и тестирующий должен так же хорошо разбираться в системе, как и создающий. Я не разработчик АМС, но предположу, что там просто нельзя использовать один активный обрабатывающий модуль. Телеметрия обязана иметь автономное воплощение, чтобы в худших случаях АМС имела хотя бы ценность тестового образца в реальных условиях космоса. Система радиосвязи - как следствие. Навигация по Солнцу - та же история, подсистема должна иметь прямой аварийный доступ к движкам, чтобы станция жила и работали аккумуляторы. Ваши более дешевые байты и защита памяти не играют в этой идеологии решающую роль, контроллеры телеметрии, радиосвязи и ориентации на Солнце не обязаны при аварийных ситуациях реализовывать накопительную логику (или тактируемый автомат с обратными связями), следовательно, при аппаратном, программном сбое последующий холодный рестарт решает проблему.
Unispace, так извините, телеметрия, радиосвязь, ориентация на Солнце это очень простые с программной точки зрения устройства - там совершенно примитивная логика которая легко решается чуть ли не на отдельных транзисторах, так что и нормально что они отдельные; насчет БОКЗ вопрос сложнее но вобщем тоже там уже готовое устройство лучше по надежности, да и вероятно дешевле, чем тратить ресурсы на интегрировать это всё в центральную ЦВМ :D
А вот скажем исследовательский панорамный радар (не тот который скорость посадки на планету меряет конечно), или система предварительной обработки изображений с панорамной камеры, или система отправки научных данных, это уже устройства которые требуют много ресурсов, но их отключение (деградация скорости или нестабильная работа) по низкому приоритету при выполнении например коррекции скорей всего не будет фатальным для миссии.
Может быть фатальным если например цель миссии было во время коррекции произвести съемку, а циклограмма коррекции съела все ресурсы, но так лажануться чтобы неправильно посчитать потребные ресурсы для ЦЕЛИ миссии нужно очень постараться.
Собственно, опять-же, возвращаясь к нашему дорогому виновнику сей беседы, в нём вообще никакой науки не было, а исключительно вот те самые критичные системы, причем все вроде в максимально автономном исполнении, но это его не спасло.
Цитироватькачество ПО может быть обеспечено не каким-то особым углубленным выбором языка, подхода, платформы, тестирования, а прежде всего человеческим фактором
Характерная ошибка мышления - искусственное противопоставление.
Надо выучить конструкцию "И": И правильный выбор языка, И правильный выбор подхода, И правильный выбор платформы, И правильное тестирование, И человеческий фактор.
В этом случае, возможно, до Марса долетим и даже назад вернёмся.
ЦитироватьРазработка АМС - не та сфера, которая двигает компьютерное железо и софт
Позволю себе не согласиться. Весьма особенная, ответственная сфера с критическими приложениями и существенной спецификой. Очень даже двигает. И аппаратные средства - которые резервируются для повышения надежности - и, соответственно, развивается наука об этом, и программные - напомню и о ПРОЛ2, и о ГРАФИТ-ФЛОКС, и пр.
ЦитироватьВ случае АМС необходимость многозадачности вызывается как раз ограниченными вычислительными ресурсами борта... вообще АМС находятся практически на переднем крае техники и сложность миссий постоянно растет, и вместе с ростом сложности миссий растет и размер и сложность программ (потому что программы уже стали составной частью техники), поэтому необходимо использовать самые современные средства разработки ПО
В целом все правильно написано. Позволю себе также процитировать книгу Д.И.Козлова, Г.П. Аншакова, Я.А. Мостового, А.В. Соллогуба "Управление космическими аппаратами зондирования Земли:Компьютерные технологии " (М.:Машиностроение, 1998).
ЦитироватьНа борту современного космического аппарата на выбор принципа организации вычислительного процесса в БВС влияют такие основные особенности, как:
Цитироватьшаг на пути автоматизированного программирования, когда человек с помощью компьютера ОДНОЗНАЧНО ставит задачу, а компьютер, используя некоторую базу знаний оптимально строит программу для имеющегося в наличии железа
В идеале - да, вот жить бы подобным образом...
Плюс еще - ставить задачу на естественном языке, а интеллектуальная САПР БПО сама осуществляет выделение точной семантики, помогает устраниить противоречивость спецификации и передает далее на автоматическую генерацию управляющей программы на заданном языке для заданной целевой платформы.
ЦитироватьЦитироватьУважаемые, можете просветить: какая аппаратура сейчас применяется для отладки ПО БВК?
Судя по тому что я читаю на этом форуме и по моему личному опыту общения с разработчиками ПО из военки, отлаживается всё это на дремучем кустарном уровне - в обычном дебаггере на ПК
Ну хватит глупости городить :!:
Могу посоветовать почитать, кроме уже процитированной выше, еще книгу Е.А. Микрина из "Энергии" "Бортовые комплексы управлеия космическими аппаратами и проектирование их программного обеспечения" (М.:МГТУ, 2003).
Или вот еще А.А. Колташёва из ОАО ИСС: "Особенности переноса бортовых программ"
http://old.osp.ru/os/2004/04/184172/_p1.html
Не надо считать себя на голову умнее разработчиков из ракетно-космической отрасли.
БПО проходит многоступенчатую отладку: автономную (перевожу на жаргон программистов "общего назначения": unit testing), совместную ("интеграционное"), комплексную.
При этом активно используются средства автоматизации тестрования.
При комплексной отладке происходит сначала моделирование работы комплекса БПО в специальном эмуляторе совместно с комплексом программ-имитационных моделей как физически движения КА и факторов космического пространства, так и бортовых систем (аппаратуры), затем - вообще на специальном отладочном комплексе с использованием реального "железа" - как БЦВМ, так и управляемой БА, происходят завершающие комплексное тестирование и испытания.
Естественно, на всех стадиях разрабатывается специальная стандартизованная документация: "Программа и методика испытаний".
ЦитироватьНадежность софта определяется:
1. Отсутствием ошибок компилятора
2. Корректными алгоритмами, в том числе обработки ошибок, диаграммами работы, структурами данных
3. Внимательным программированием
4. Аппаратной реализацией
Надежность БПО определяется:
1. Процессом/методологией/технологией его разработки на всех стадиях жизненного цикла
2. Личностью разработчика (ков)
3. Взаимопониманием в команде разработчиков между специалистами по аппаратным сресдствам, логике управления и программистами
4. Используемыми языками
5. Устойчивостью к некорректному поведению аппаратуры
6. Возможностью коррекции/замены ПО в процессе полета
7. Отсутствием ошибок в инструментальных программных средствах - компиляторах, системах автоматизированного тестирования, и пр.
8. Многоэтапным тестированием и испытаниями - в том числе в комплексе с моделями, а затем "настоящим" железом
9. Формальными методами верификации - ну, это наше светлое будущее в основном пока :)
Цитироватьavp, все-же вам "Рабинович напел".. Вы сами Erlang/OTP не пробовали.
Без комментариев. Вы ничего не опровергли из того что я говорил про Erlang.
ЦитироватьСтратегии управления ошибками, выделением памяти итп зависят не от особенностей платформы а от цели, а цель у нас одна - управляемая
надежность.
Вы бесконечно далеки от реальной жизни. Одно дело архитектура x86 и другое дело какой нибуть ARM. Виртуальная машина какой бы она не была не может абстрагироваться от низкоуровневых особенностей конкретного железа и ввода-вывод.
ЦитироватьЦитироватьНичего она не переносится. Проблема в вводе-выводе, под которые придётся писать дрова, вникая во все тонкости ОС.
Вы сами себя понимаете? Если у нас уже есть микроядерная ОС, то во первых её тонкости минимизируются, а во вторых при переносе никаких новых тонкостей со стороны ОС не возникает.
Ещё раз повторяю. HAL кто будет переписывать и тестировать? Кто будет кодировать низкоуровневый ввод вывод??? Всё это даёт нехилый abstraction penalty. Толку от этой микро ОС будет около нуля при ограниченности памяти и других ресурсов. Такая ОС должна создаваться и вылизываться десятилетиями при более менее стабильной аппаратной платформе.
ЦитироватьНет. Не любой интерпретатор. Только ВМ заточенная на надежность позволяет управлять надежностью, и фактически кроме ВМ Erlang таковая только одна Enterprise Java.
Что значит "управлять надёжностью"?
Сносить криво ведущий себя код.
Упадёт ваш процесс на Erlang и может быть перезапустится. Возможно и дальше заработает. Но целевая функция будет не выполнена, состояние будет потеряно.
На Яве у вас тупо вылетит исключение и всё. Да ВМ будет жива, но в сейф мод придётся перейти.
Вы смешиваете в одну кучу возможность выстрелить себе в ногу и программные ошибки.
ЦитироватьФункциональные языки максимально близки к декларативным DSL,
Бесконечно далеки. Например SQL близок к функциональному, но ни на каком существующем функциональном языке его не выразишь адекватно без макросов.
Есть например варианты декларативного описания конечных автоматов. Вполне себе DSL. Генерируют высоконадёжный код.
Цитироватьа конкретно Erlang использует синтаксис очень близкий к Prolog,
Может хватит про Erlang? Это язык программирования с динамической типизацией. Этого достаточно чтобы выбросить его в топку. Только жёсткая статическая типизация с случае КА будет приемлимой.
ЦитироватьТут есть проблемы:
1. решается только часть глюков - остаются глюки когда программа просто не дошла до вызова устройства и свалилась или пошла не туда.
2. ставится еще одно звено между компьютером и устройством и этим понижается общая надежность.
3. драйвера отлаженные на обычных компьютерах прийдется переделывать под это и такая переделка во первых будет стоить денег а во вторых может внести новые ошибки.
1. Ну что поделать? Но бездействие как правило менее фатально, чем действие.
2. Не факт. Добавляя одно звено - другие можно убрать.
3. Нет, дрова те же. Идея-то в чём? Чтобы все важные "кнопки" были с предохранителями. Т.е. в драйвер это вносить нельзя. Должно быть два вызова, притом разных функций.
ЦитироватьСобственно, опять-же, возвращаясь к нашему дорогому виновнику сей беседы, в нём вообще никакой науки не было, а исключительно вот те самые критичные системы, причем все вроде в максимально автономном исполнении, но это его не спасло.
Тут ещё такой момент. Я на прошлой странице привёл фото звёздных датчиков - и там видно, что за 15 лет интерфейс не поменялся. Т.е. - он фактически "черный ящик", выдающий весьма ограниченную информацию. Возможности например слить картинку с сенсора и отправить для анализа на Землю - нет.
Т.е. та же ситуация что с нырнувшими глонассами - хоть там в баке система стояла и умная, но наружу выдавала только достижение предустановленных уровней.
ЦитироватьЯ на прошлой странице привёл фото звёздных датчиков - и там видно, что за 15 лет интерфейс не поменялся. Т.е. - он фактически "черный ящик", выдающий весьма ограниченную информацию. Возможности например слить картинку с сенсора и отправить для анализа на Землю - нет.
Даже в Интернет есть примеры кадров с "Ямалов". Так что, заблуждаетесь. А интерфейс там, скорее всего, особо и не менялся - более-менее стандартный (для _любого_ звездного датчика) набор команд и информационных сообщений. Разница только в деталях - у кого-то направляющие косинусы, у кого-то кватернионы на выходе. У кого-то последовательный интерфейс, у кого-то (БОКЗ) - шина.
ЦитироватьА интерфейс там, скорее всего, особо и не менялся - более-менее стандартный (для _любого_ звездного датчика) набор команд и информационных сообщений. Разница только в деталях - у кого-то направляющие косинусы, у кого-то кватернионы на выходе. У кого-то последовательный интерфейс, у кого-то (БОКЗ) - шина.
То, что было нормальным 15 (а то и больше) лет назад - сейчас совершенно ненормально.
Что конкретно "ненормально", поясните, пожалуйста.
Есто опыт работы с современными датчиками других производителей? Поделитесь тогда.
ЦитироватьЦитироватькачество ПО может быть обеспечено не каким-то особым углубленным выбором языка, подхода, платформы, тестирования, а прежде всего человеческим фактором
Характерная ошибка мышления - искусственное противопоставление.
Надо выучить конструкцию "И":
ЦитироватьРазработка АМС - не та сфера, которая двигает компьютерное железо и софт
Позволю себе не согласиться. Весьма особенная, ответственная сфера с критическими приложениями и существенной спецификой. Очень даже двигает. И аппаратные средства - которые резервируются для повышения надежности - и, соответственно, развивается наука об этом, и программные - напомню и о ПРОЛ2, и о ГРАФИТ-ФЛОКС, и пр.
Вы хотите обучить меня булевой алгебре ? :) Так я ее давно знаю, может быть, даже раньше вас изучал :) Что же, мне читать лекцию о приоритетах ? Моя мысль проста, когда бардак начинает пролезать уже туда, где до этого все было еще более-менее, то никакие эрланги и умудренные процедуры тестов не помогут. Все начинается и заканчивается на человеке. Про движение железа и софта не убедили. Работы по обеспечению надежности и резервированию в железе и софте велись еще до запуска первой АМС. В то же время специфические решения, реализуемые в АМС, не столь нужны в компьютерных технологиях массового распространения. Не такая уж это сложная штука - АМС, с точки зрения компьютерных систем. Она может работать дубово, без изысков и копий, обломки которых здесь уже образовали пирамиду, но надежно, и тогда долетит. Именно такой подход часто можено видеть у Запада. Они не витийствуют, создают, может, с огрехамии, но рабочее! А мы потом комплексуем и обсуждаем-обсасываем ошибки. Виндовс содержит много ошибок, но завоевала мир. А мы знаем все ее ошибки наперечет, но и близко не можем создать подобное. На Пионерах, Маринерах были звездные датчики ? Почему они нормально работают на железе, которое в 1000 раз слабее, чем современное, а мы сейчас обсуждаем возможную проблему с этим же современным датчиком ? Эрланги и тесты ПО не помогут ответить на вопрос.
Цитироватькогда бардак начинает пролезать уже туда, где до этого все было еще более-менее, то никакие эрланги и умудренные процедуры тестов не помогут. Все начинается и заканчивается на человеке
все равно стремиться к снижению значимости человеческого фактора стоит. как можно больше должно быть отчуждено от умений, опыта и искусства конкретного "дяди Васи". ясно, что это невозможно, но стремиться надо.
Цитироватьспецифические решения, реализуемые в АМС, не столь нужны в компьютерных технологиях массового распространения
Но при создании БВК АМС и вообще КА - нужны? Мы собираемся строить космические корабли?
ЦитироватьВиндовс содержит много ошибок, но завоевала мир
Просто кое-кто недоучившийся в университете был в нужное время знаком кое с кем. И вообще - гений маркетинга и бизнеса.
Цитироватьвсе равно стремиться к снижению значимости человеческого фактора стоит. как можно больше должно быть отчуждено от умений, опыта и искусства конкретного "дяди Васи". ясно, что это невозможно, но стремиться надо.
Но при создании БВК АМС и вообще КА - нужны? Мы собираемся строить космические корабли?
Просто кое-кто недоучившийся в университете был в нужное время знаком кое с кем. И вообще - гений маркетинга и бизнеса.
На конвейере ширпотреба. Можно отчуждаться. А в специальных или передовых проектах - никак. 100 середнячков не заменят одного талантливого.
Мы говорили о движении компьютерных технологий и роли таких устройств, как АМС. Они не двигатели этих технологий.
Нет, не просто. На одном маркетинге не уедешь в таких областях, были и конкуренты.
ЦитироватьМожет хватит про Erlang? Это язык программирования с динамической типизацией. Этого достаточно чтобы выбросить его в топку. Только жёсткая статическая типизация с случае КА будет приемлимой.
Ну не стоит так критично. Между динамической и статической типизацией есть определенный баланс. При правильном подходе динамическая типизация не мешает разрабатывать надежный код.
По поводу Erlang. В целом то мысль интересная, однако много вопросов по применимости данного чуда. В первую очередь относительно его применимости в критичных ко времени исполнения системах реального времени.
Виртуальная машина, на первый взгляд, хорошо - дополнительный уровень защиты от непредвиденных проколов в ПО. Практика также показала, что ВМ не мешает добиться real time исполнения. Взять ту же Real Time Java, успешно отработавшую на марсоходах. Но, с другой стороны, тот же уровень защиты можно получить используя и дополнительные аппаратные средства (watchdog таймеры, защиту критического кода и данных от перезаписи глючащим процессом). ВМ в этом плане предъявляет меньше требований к аппаратной части, и как следствие может быть дешевле. Плюс все-таки более высокий уровень абстракции в фундаменте ПО систем управления.
Специфика функционального подхода тоже несколько настораживает, но возможно это из-за отсутствия опыта в разработке с его использованием.
ПРОЛ2 тоже интересен, но опять же, он все равно не дает 100% гарантии от ошибок в алгоритмах, а следовательно не позволяет исключить ни одну из обсуждаемых составляющих разработки надежного ПО. Да и задача у него другая была, если я правильно понял, - исключить "чистого" программиста из цикла разработки. Однако программист помимо тупого преобразования спецификаций в код попутно решает еще кучу задач (обработка ошибок, оптимизация, адаптация под аппаратную часть и т.п.), которые для "специалиста", составившего спецификацию, вообще не существуют.
Относительно разгоревшейся здесь дискуссии, сам я считаю, что роль человеческого фактора в разработке ПО еще долго будет ощутимой, а в самом процессе присутствует место таланту и искусству. Однако, на мой взгляд, глупо утверждать, что хороший разработчик ПО просто обязан был сам паять железо, с которым он работает. Так можно и договориться и до того, что если ты не добывал руду для проводников и кристаллы кремния не выращивал, то и написать ничего толкого не сможешь :)
Хочется добавить еще по поводу тестирования. Мнение о том, что тестировщик должен быть таким же специалистом, как и разработчик, считаю ошибочным.
По сути тестировщик является "автоматизатором" процесса тестирования там, где более лучшие варианты автоматизации тестирования не доступны.
Рассуждая в срезе разработки ПО для АМС, предлагаю первым уровнем тестирования считать совокупность математических моделей всех объектов системы. Она дает сумасшедшую гибкость и позволяет полностью автоматизировать тестирование ПО. Следующим уровнем будет КИС, который устраняет недостатки математических моделей, дополняя тестирование реальными процессами. Однако автоматизировать тестирование на КИС уже проблематично. Местами можно поизголяться, например автоматизировать вращение датчиков дополнительными приводами и т.п. Однако вероятность двойной ошибки не нулевая, да и сложность/стоимость такой реализации существенна.
Вот тут и входит в игру тестировщик. Основная его задача - это ОТВЕТСТВЕННОЕ выполнение всего плана тестирования системы. По сути он проходит план шаг за шагом, выполняя предписания (например, позиционируя те или иные датчики в соответствии с описанием текущего шага испытаний) и фиксируя результаты. Сравнивая результаты с ожидаемыми по плану, он выявляет расхождения, информация о которых вносится в итоговый отчет.
План тестирования - это совместный продукт разработчиков и конструкторов. Основная часть составляется на начальном этапе и потом постепенно корректируется по ходу эволюции системы и КИС.
Рабочая схема? Нужен тут супер-спец тестировщик? По-моему, ответы очевидны.
ЦитироватьЦитироватьСудя по тому что я читаю на этом форуме и по моему личному опыту общения с разработчиками ПО из военки, отлаживается всё это на дремучем кустарном уровне - в обычном дебаггере на ПК
Могу посоветовать почитать, кроме уже процитированной выше, еще книгу Е.А. Микрина из "Энергии" "Бортовые комплексы управлеия космическими аппаратами и проектирование их программного обеспечения" (М.:МГТУ, 2003).
Или вот еще А.А. Колташёва из ОАО ИСС: "Особенности переноса бортовых программ"
http://old.osp.ru/os/2004/04/184172/_p1.html
Спасибо за ссылки.
Я про ОАО ИСС знаю и их уважаю. Но я считаю что они оазис в пустыне. РККЭ пока АМС не занимается. (или уже занимается?)
ЦитироватьНе надо считать себя на голову умнее разработчиков из ракетно-космической отрасли.
Я потому и использую специальные инструменты, что считаю себя обычным нормальным человеком, которому свойственно ошибаться :P
А от тех самых, которые отлаживают в дебаггере постоянно слышал аргумент "это не твоего ума дело"..
ЦитироватьЦитироватьПора менять все ГОСТы ЕСПД и Информационная технология под программиста-разработчика :lol:
Пора к работе подходить аккуратно и тщательно, а то скоро и советское наследие в космосе начнет проявлять несвойственные расчетным коэффициенты отказа. Главный ГОСТ должен быть в голове, у всех.
Для формирования "главного ГОСТа" необходимы правила, которыми и руководствуются при разработке РКТ - РК-98-КТ и ГОСТами.
ЦитироватьЦитироватьЦитироватьПора менять все ГОСТы ЕСПД и Информационная технология под программиста-разработчика :lol:
Пора к работе подходить аккуратно и тщательно, а то скоро и советское наследие в космосе начнет проявлять несвойственные расчетным коэффициенты отказа. Главный ГОСТ должен быть в голове, у всех.
Для формирования "главного ГОСТа" необходимы правила, которыми и руководствуются при разработке РКТ - РК-98-КТ и ГОСТами.
Да в ГОСТах и в том же РК-98 все есть. Этими документами не руководствуются в процессе разработки, только в декларативной форме. Я почти уверен, что по проекту Фобос-Грунт была слабая стендовая база. Многое проектировалось "в темную", без возможности натурной отработки. У нас вообще заказчик не понимает зачем нужны стенды и что нормальный полноценный стенды будет стоить не меньше (если не больше) чем сам опытный образец. Заказчику не нужны стенды. Ему нужно летающее железо, а вот взаимосвязь этих двух компонент они не видят. Попробуйте заложить в процесс разработки в статьи затрат какого нибудь изделия пункт - создание испытательного стенда для этого изделия? Заказчик не поймет эти "дополнительные" затраты. Тут очень кстати, была информация про сгнившие полы в одном из НИПов. Мысль, сделать ремонт в голову никому не пришла
ЦитироватьПо поводу Erlang. В целом то мысль интересная, однако много вопросов по применимости данного чуда. В первую очередь относительно его применимости в критичных ко времени исполнения системах реального времени.
Есть вопрос про реальное время.
Вы возможно в курсе, сейчас разделяют два уровня исполнения систем РВ:
1. hard real time - система гарантирует задержку исполнения не более заданной всегда.
2. soft real time - система гарантирует задержку исполнения не более заданной скажем в 90% случаев (в 10% случаев задержка может быть существенно больше).
Вопрос, какой именно уровень исполнения РВ вы считаете необходимым и какой достаточным для АМС и почему?
PS Собственно сейчас в Erlang обычно используется квант 1мс; в Erlang soft real time, то есть могут быть выбросы задержек.
ЦитироватьДля формирования "главного ГОСТа" необходимы правила, которыми и руководствуются при разработке РКТ - РК-98-КТ и ГОСТами.
Для формирования этого ГОСТа заново нужно перестать все в жизни измерять деньгами. Нам много лет внушали в СССр, что Запад - это мир чистогана. Оказалось, что им и не снился наш "чистоган".
ЦитироватьЦитироватьДля формирования "главного ГОСТа" необходимы правила, которыми и руководствуются при разработке РКТ - РК-98-КТ и ГОСТами.
Для формирования этого ГОСТа заново нужно перестать все в жизни измерять деньгами. Нам много лет внушали в СССр, что Запад - это мир чистогана. Оказалось, что им и не снился наш "чистоган".
Деньги за хорошую работу в соответствии с ISO, и премии за качественную работу выполненную раньше срока контракта, и штрафы за невыполнение! Вот Запад. :lol: И репутация, зависящая только от результата :(
ЦитироватьВопрос, какой именно уровень исполнения РВ вы считаете необходимым и какой достаточным для АМС и почему?
Давайте плясать от того, что одна надежная и мощная ЦВМ лучше, чем комплекс из нескольких разнородных/специализированных. Соответственно эта ЦВМ будет решать весь спектр задач по управлению АМС, и как следствие, гарантия задержки исполнения в этом случае далеко не на последнем месте. В частности выработка закона управления исполнительными механизмами и организация контура обратной связи весьма чувствительна к существенным задержкам. Поэтому в идеале должен быть hard real time.
Но в зависимости от специфики не исключено, что провалы soft real time удастся компенсировать за счет изощренности СУ. Главное чтобы эти сложности с лихвой компенсировались преимуществами, которые стоили нам soft real time'а.
ЦитироватьЦитироватьПо поводу Erlang. В целом то мысль интересная, однако много вопросов по применимости данного чуда. В первую очередь относительно его применимости в критичных ко времени исполнения системах реального времени.
Есть вопрос про реальное время.
Вы возможно в курсе, сейчас разделяют два уровня исполнения систем РВ:
1. hard real time - система гарантирует задержку исполнения не более заданной всегда.
2. soft real time - система гарантирует задержку исполнения не более заданной скажем в 90% случаев (в 10% случаев задержка может быть существенно больше).
Вопрос, какой именно уровень исполнения РВ вы считаете необходимым и какой достаточным для АМС и почему?
PS Собственно сейчас в Erlang обычно используется квант 1мс; в Erlang soft real time, то есть могут быть выбросы задержек.
Извините, вставлю пятак. :lol: Любой, на выбор разработчика, при котором управляемый объект удовлетворял бы требованиям предъявляемым к нему, с допустимым (оптимальным) запасом устойчивости к внешним воздействиям и внутренним отказам объекта.
ЦитироватьЦитироватьвсе равно стремиться к снижению значимости человеческого фактора стоит
На конвейере ширпотреба. Можно отчуждаться. А в специальных или передовых проектах - никак
Как.
Цитировать100 середнячков не заменят одного талантливого
Это да.
ЦитироватьИзвините, вставлю пятак. :lol: Любой, на выбор разработчика, при котором управляемый объект удовлетворял бы требованиям предъявляемым к нему, с допустимым (оптимальным) запасом устойчивости к внешним воздействиям и внутренним отказам объекта.
Совершенно верно! Увы природа soft real time затрудняет анализ этих параметров.
ЦитироватьЦитироватьМожет хватит про Erlang? Это язык программирования с динамической типизацией. Этого достаточно чтобы выбросить его в топку
Ну не стоит так критично. Между динамической и статической типизацией есть определенный баланс. При правильном подходе динамическая типизация не мешает разрабатывать надежный код
Дело не просто в надежности. Динамическая типизация - ненужный расход ресурсов. На борту они ограничены (характерны, к примеру, показатели ОЗУ 2 Мбайта).
ЦитироватьСпецифика функционального подхода тоже несколько настораживает
функциональный язык программирования по своей сути не содержит понятия "точка исполнения" программы, что противоречит концепции состояний. А управление БА - это именно состояния. Так что не самое подходящее место для функционального языка - борт КА.
ЦитироватьПРОЛ2 тоже интересен, но опять же, он все равно не дает 100% гарантии от ошибок в алгоритмах
Хммм. Но он позволяет резко снизить количество возможных видов ошибок - подобная формулировка устроит? за счет подъема на "недоступную высоту" проблемно-ориентированного языка. Это причем как раз специально созданное с учетом специфики средство.
Цитироватьзадача у него другая была, если я правильно понял, - исключить "чистого" программиста из цикла разработки. Однако программист помимо тупого преобразования спецификаций в код попутно решает еще кучу задач (обработка ошибок, оптимизация, адаптация под аппаратную часть и т.п.), которые для "специалиста", составившего спецификацию, вообще не существуют
Информации о ПРОЛ2 не столь много имеется. Почему бы не предположить, что создателям удалось решить все перечисленные задачи, переложив их на систему?
ЦитироватьВопрос, какой именно уровень исполнения РВ вы считаете необходимым и какой достаточным для АМС и почему?
Вопросов никаких нет. Яркий пример, когда применимо только жёсткое реальное время.
Некоторые процессы на борту ждать никого не будут, а привести могут к катастрофе.
ЦитироватьДело не просто в надежности. Динамическая типизация - ненужный расход ресурсов. На борту они ограничены (характерны, к примеру, показатели ОЗУ 2 Мбайта).
2 Мбайта это не так уж мало, а оверхед динамической типизации по памяти не очень большой, скажем, 1 байт на примитивные типы или 1 слово на типы, определяемые пользователем. Тут больше страдает производительность из-за неявных преобразований несоответствующих типов. Но этот аспект в большей части в руках разработчика.
Цитироватьфункциональный язык программирования по своей сути не содержит понятия "точка исполнения" программы, что противоречит концепции состояний. А управление БА - это именно состояния.
Да, это меня и смущает.
ЦитироватьТак что не самое подходящее место для функционального языка - борт КА.
Тем не менее на этом языке разрабатывают гораздо более сложные системы, чем расчет примитивных отображений.
Функциональный язык там вроде в основе. Но основная модель разработки - это асинхронные агенты и обмен сообщений между ними. Последнее позволяет реализовать произвольное состояние (с небольшой помощью от ран-тайма по сохранению/восстановлению данных). Тут я не спец и рассуждаю, исходя из общих соображений. Может zyxman прольет свет на этот аспект.
Чистая асинхронная модель, кстати, может быть весьма кстати в данной пердметной области. Ведь управляемые процессы асинхронны по природе.
ЦитироватьХммм. Но он позволяет резко снизить количество возможных видов ошибок - подобная формулировка устроит?
Ну резко снизить количество ошибок могут и более традиционные методы, которые не так кардинально усложняют тот же контроль версий, к примеру. И там, и там главную роль играет отвественность разработчика. Но т.к. закладываться на нее на 100% не позволительно, то все равно придется прибегать ко всему арсеналу. Тогда в чем выгода?
Цитироватьза счет подъема на "недоступную высоту" проблемно-ориентированного языка. Это причем как раз специально созданное с учетом специфики средство.
Тут сложно сказать. Может действительно нашли удачное решение. DSL всегда будут выигрывать во многих аспектах, кроме гибкости.
ЦитироватьИнформации о ПРОЛ2 не столь много имеется. Почему бы не предположить, что создателям удалось решить все перечисленные задачи, переложив их на систему?
Мало данных :) Сроки разработки систем, в которых использовался ПРОЛ2 не то, чтобы маленькие. То что они работают, это факт. Но далеко не факт, что их нельзя было разработать с применением современных технологий за более короткие сроки, и задействуя меньшие ресурсы.
ЦитироватьЦитироватьИзвините, вставлю пятак. :lol: Любой, на выбор разработчика, при котором управляемый объект удовлетворял бы требованиям предъявляемым к нему, с допустимым (оптимальным) запасом устойчивости к внешним воздействиям и внутренним отказам объекта.
Совершенно верно! Увы природа soft real time затрудняет анализ этих параметров.
Не со всем так, внешние воздействия на 90% известны, а внутренние в соответствии с вероятностью отказов СЧ объекта, полученной расчетным и экспериментальным путем. Необходимо адекватно парировать их воздействие на систему с помощью алгоритмов СПО.
Имел в виду, что soft real time приводит к дискретному управлению с периодически падающей (существенно) частотой дискретизации. Как будет анализировать устойчивость?
ЦитироватьИмел в виду, что soft real time приводит к дискретному управлению с периодически падающей (существенно) частотой дискретизации. Как будет анализировать устойчивость?
В зависимости от критичности процесса к быстроте реакции на воздействие или выдачи управляющего воздействия, необходимой точностью выполнения - по приоритетам. Например - точность направления ВКИ и точность удержания направления на Солнце в ПСО. Первая задача решается каждый цикл, вторая - каждый сотый (абстрактно). Точность соответственно пропорциональна.
Цитировать- Собственно, микроядерные ОС тоже решают эту проблему похожим методом - там драйвера обычные программы и работают с устройствами не напрямую а с помощью сообщений ядру, какой бит поднять и какой опустить, и в ядре можно поставить подобные проверки программно.
Осталась мелочь - как проверить проверяющего? ;) Глюки в ПО не более вероятны чем в ядре. Кроме того, что делать с гонками при доступах разных процессов к общему ресурсу? А с взаимным блокированием? Ядро - то может и отловит, но время-то уже уйдет...
Может не стоит так извращаться из-за желание запихнуть весь софт в один процессор. Обычно подобное складывание всех яиц хорошо не заканчивается. :twisted: Вместо того, что-бы для выполнения одной задачи делать отдельный поток в (RT)ОС разумнее для этой задачи сделать отдельный контроллер под размер задачи (естественно с отдельной программой). Физическая разделение памяти до сих пор наиболее эффективный способ ее защиты :) . Как бонус к этому - каждая задача будет меньше, понятнее и портабельнее.
ЦитироватьЦитироватьИмел в виду, что soft real time приводит к дискретному управлению с периодически падающей (существенно) частотой дискретизации. Как будет анализировать устойчивость?
В зависимости от критичности процесса к быстроте реакции на воздействие или выдачи управляющего воздействия, необходимой точностью выполнения - по приоритетам. Например - точность направления ВКИ и точность удержания направления на Солнце в ПСО. Первая задача решается каждый цикл, вторая - каждый сотый (абстрактно). Точность соответственно пропорциональна.
Просто напрашивается разделение алгоритмов по одному/(связанной группе) на отделъный CPU. (Всего лишь мое мнение, этот метод частично использовался при разработке авионики).
Кроме того, отработанные алгоритмы можно "запечатать" и забыть..
Короче, иерархический дизайн.
ЦитироватьЦитироватьЦитироватьИмел в виду, что soft real time приводит к дискретному управлению с периодически падающей (существенно) частотой дискретизации. Как будет анализировать устойчивость?
В зависимости от критичности процесса к быстроте реакции на воздействие или выдачи управляющего воздействия, необходимой точностью выполнения - по приоритетам. Например - точность направления ВКИ и точность удержания направления на Солнце в ПСО. Первая задача решается каждый цикл, вторая - каждый сотый (абстрактно). Точность соответственно пропорциональна.
Просто напрашивается разделение алгоритмов по одному/(связанной группе) на отделъный CPU. (Всего лишь мое мнение, этот метод частично использовался при разработке авионики).
Кроме того, отработанные алгоритмы можно "запечатать" и забыть..
Короче, иерархический дизайн.
ОПЫТ КОНСТРУКТОРА, НАПРАВЛЕНИЕ ПРОЕКТА И ВЫБОР МАТЧАСТИ ДЛЯ РЕАЛИЗАЦИИ, ПОТОМ СПО.
ЦитироватьЦитироватьЦитироватьИмел в виду, что soft real time приводит к дискретному управлению с периодически падающей (существенно) частотой дискретизации. Как будет анализировать устойчивость?
В зависимости от критичности процесса к быстроте реакции на воздействие или выдачи управляющего воздействия, необходимой точностью выполнения - по приоритетам. Например - точность направления ВКИ и точность удержания направления на Солнце в ПСО. Первая задача решается каждый цикл, вторая - каждый сотый (абстрактно). Точность соответственно пропорциональна.
Просто напрашивается разделение алгоритмов по одному/(связанной группе) на отделъный CPU. (Всего лишь мое мнение, этот метод частично использовался при разработке авионики).
Кроме того, отработанные алгоритмы можно "запечатать" и забыть..
Короче, иерархический дизайн.
Таким методом и строили КБО самолетов раньше: МИГ-29, СУ-27.
Там было до 20 вычислителей. И без резервирования: на дублирование уже не было места.
Впечатляет?
ЦитироватьЦитироватьЦитироватьЦитироватьИмел в виду, что soft real time приводит к дискретному управлению с периодически падающей (существенно) частотой дискретизации. Как будет анализировать устойчивость?
В зависимости от критичности процесса к быстроте реакции на воздействие или выдачи управляющего воздействия, необходимой точностью выполнения - по приоритетам. Например - точность направления ВКИ и точность удержания направления на Солнце в ПСО. Первая задача решается каждый цикл, вторая - каждый сотый (абстрактно). Точность соответственно пропорциональна.
Просто напрашивается разделение алгоритмов по одному/(связанной группе) на отделъный CPU. (Всего лишь мое мнение, этот метод частично использовался при разработке авионики).
Кроме того, отработанные алгоритмы можно "запечатать" и забыть..
Короче, иерархический дизайн.
Таким методом и строили КБО самолетов раньше: МИГ-29, СУ-27.
Там было до 20 вычислителей. И без резервирования: на дублирование уже не было места.
Впечатляет?
п/я 1001 :lol:
ЦитироватьТаким методом и строили КБО самолетов раньше: МИГ-29, СУ-27.
Там было до 20 вычислителей. И без резервирования: на дублирование уже не было места.
Впечатляет?
Другая специфика, мне кажется. При попадании снаряда в элемент, управляемый вычислителем, управлять все равно уже нечем (есть резерв вычислителей или нет).
По такому пути продолжают идти и на Т-50. Следите за прессой до 2013 г. - Путину обещали поставить Т-50 в учебные центры.
ЦитироватьЦитироватьДело не просто в надежности. Динамическая типизация - ненужный расход ресурсов. На борту они ограничены (характерны, к примеру, показатели ОЗУ 2 Мбайта).
2 Мбайта это не так уж мало, а оверхед динамической типизации по памяти не очень большой, скажем, 1 байт на примитивные типы или 1 слово на типы, определяемые пользователем. Тут больше страдает производительность из-за неявных преобразований несоответствующих типов. Но этот аспект в большей части в руках разработчика.
Больше всего страдает надежность, поскольку в результате буйного преобразования типов получается неизвестно что. Скажем преобразование вещественного в целое дробная часть отбрасывается. Возможно, в данной задаче подобная потеря точности недопустима, но компилятор/интерпретатор этого не заметит. Так же автоматическое управление памятью вносит непредсказуемые временные задержки, если куча закончилась и надо собирать мусор. А так же потенциальный отказ из-за полного исчерпания динамической памяти. Статическое распределение памяти гарантирует временные задержки и достаточность памяти при компиляции. Многозадачность вносит негарантированный доступ каждой задачи к процессору плюс возможные дедлоки в результате синхронизации задач.
ЦитироватьЦитироватьЦитироватьДело не просто в надежности. Динамическая типизация - ненужный расход ресурсов. На борту они ограничены (характерны, к примеру, показатели ОЗУ 2 Мбайта).
2 Мбайта это не так уж мало, а оверхед динамической типизации по памяти не очень большой, скажем, 1 байт на примитивные типы или 1 слово на типы, определяемые пользователем. Тут больше страдает производительность из-за неявных преобразований несоответствующих типов. Но этот аспект в большей части в руках разработчика.
Больше всего страдает надежность, поскольку в результате буйного преобразования типов получается неизвестно что. Скажем преобразование вещественного в целое дробная часть отбрасывается. Возможно, в данной задаче подобная потеря точности недопустима, но компилятор/интерпретатор этого не заметит. Так же автоматическое управление памятью вносит непредсказуемые временные задержки, если куча закончилась и надо собирать мусор. А так же потенциальный отказ из-за полного исчерпания динамической памяти. Статическое распределение памяти гарантирует временные задержки и достаточность памяти при компиляции. Многозадачность вносит негарантированный доступ каждой задачи к процессору плюс возможные дедлоки в результате синхронизации задач.
Круто, но КА замкнутый объект, с конечным числом, как задач, так и параметров. Можно добиться приведения к 2-3 типам без потери точности и устойчивости объекта
Ну и правильно делают. Я же говорю - вычислитель то продублировать можно, а вот двигатель уже не продублируешь.
А в случае с АМС можно и пожировать. Задача обеспечить максимальную живучесть при столкновении с мусором не стоит. Взять одну троированную ЦВМ, состоящую в придачу из нескольких граней для горячего и холодного резерва. Проще реализуется, чем куча отдельных контроллеров, которые еще нужно согласовать и научить отрабатывать ошибки согласования. Потом поменяли один блок на новый с другим протоколом и айда все связи перелопачивать.
В общем думаю только практика покажет какое решение более удачно. Но для этого нужно больше практики. Я лично склоняюсь к тому, что одна ЦВМ упрощает задачу и обеспечивает большую гибкость.
Если все-таки пытаться обеспечить надежную работу системы на базе soft real time ОС, то можно попробовать рассмотреть два подхода:
1) Разделение ядра на виртуальную машину и "драйвера", имеющие более высокий приоритет, чем ВМ, и решающие отдельные задачи управления/контроля, по мере необходимости.
2) Вынос критичных задач управления в отдельные контроллеры, по возможности минимизируя их количество.
Проект 1992 года - несостоявшийся Алмаз-2
Класс задач контроля и управления бортовой аппаратурой КА:
1.1. Контроль и управление аппаратурой БРТК-АС,
1.2. Контроль и управление аппаратурой БРТК-МС,
1.3. Контроль и управление аппаратурой БРТК-МК,
1.4. Контроль и управление аппаратурой БК,
1.5. Контроль и управление аппаратурой БКЖ (служебные системы),
1.6. Контроль и управление комплексами КА и формирование и вы-
дача на НКУ информации телесигнализации КА,
1.7. Прием от НКУ и исполнение КПИ,
1.8. Управление коррекцией положения КА,
1.9. Ведение бортовой шкалы времени (БШВ) и привязка БШВ к БШВ
соседних КА и СЕВ НКУ.
Класс задач управления функционированием КА, как узла сети свя-
зи системы "МАКСИМУМ":
2.1. Управление доступом абонентов в служебный канал,
2.2. Контроль качества каналов связи,
2.3. Поддержание соединений абонентов с КА (переключение между
подзонами),
2.4. Управление функционированием связной
аппаратуры БРТК-АС,
2.5. Контроль качества каналов связи, поддержание соединений
абонентов и управление функционированием связной аппаратуры БРТК-МС,
2.6. Управление доступом ШС в радиоканал,
2.7. Контроль качества каналов связи,
2.8. Поддержание соединений с ШС,
2.9. Обеспечение связи с НКУ по радиоканалу БРТК-МК,
2.10. Обеспечение связи с РЦО по радиоканалу БРТК-МК,
2.11. Функциональная задача управления коммутацией в БК,
2.12. Установление соединений абонентов сети,
2.13. Поддержание соединений абонентов сети,
2.14. Обеспечение функционирования КА в качестве абонента слу-
жебной сети связи.
Класс задач балистико навигационного обеспечения:
3.1. Определение местоположения АС,
3.2. Определение дальности до соседних КА,
3.3. Определение радиальных скоростей относительно соседних КА,
3.4. Определение дальности до ШС-реперов,
3.5. Определение радиальных скоростей относительно ШС-реперов,
3.6. Определение текущей ориентации КА,
3.7. Определение текущего положения КА,
3.8. Расчет параметров движения КА,
3.9. Прогнозирование сеансов ВТИ по ШС-реперам, интервалов от-
сутствия связи в радиоканалах БРТК-МС и интервалов разгрузки махови-
ков СОС,
3.10. Расчет целеуказаний для антенн БРТК-МС,
3.11. Формирование эфемеридной информации для АС.
ЦитироватьПроект 1992 года - несостоявшийся Алмаз-2
Класс задач контроля и управления бортовой аппаратурой КА:
...
3.11. Формирование эфемеридной информации для АС.
34 задач, непрерывные, периодические и циклические. Решались чуть ли не на х286 процессоре :lol:
ЦитироватьБольше всего страдает надежность, поскольку в результате буйного преобразования типов получается неизвестно что. Скажем преобразование вещественного в целое дробная часть отбрасывается. Возможно, в данной задаче подобная потеря точности недопустима, но компилятор/интерпретатор этого не заметит.
Скорее наоборот, при разработке средствами с динамическими типами такие вещи принимаются как данность. Соответственно правильный цикл разработки подразумевает эффективное обнаружение и устранение таких проблем. А вот статическая проверка типов в этом плане иногда расслабляет - достаточно где-то выполнить ошибочное явное приведение типов, чтобы компилятор не ругался, и забыть о нем через пару часов. В итоге чрезмерная уверенность в жесткой типизации сделает свое черное дело.
ЦитироватьТак же автоматическое управление памятью вносит непредсказуемые временные задержки, если куча закончилась и надо собирать мусор. А так же потенциальный отказ из-за полного исчерпания динамической памяти. Статическое распределение памяти гарантирует временные задержки и достаточность памяти при компиляции.
Здесь не могу ничего сказать, так как нет опыта в работе с автоматическим управлением памятью в ОС РВ. Хотя очевидно, что в этом направлении работы тоже активно ведутся: http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Real-time_garbage_collection
В общем же, ВМ не обязательно подразумевает автоматическое управление памятью. Основная задача, как мне кажется - это упростить реализацию защиты от серьезных непредвиденных ошибок за счет возможности контроллировать корректность каждой операции на уровне байт кода. Это не мешает реализовать неавтоматическое распределение памяти, если язык позволяет (например компилировать С/С++ в байт-код ВМ).
ЦитироватьМногозадачность вносит негарантированный доступ каждой задачи к процессору плюс возможные дедлоки в результате синхронизации задач.
Многозадачность бывает разная. Философия Erlanga отчасти и вызывает у меня интерес тем, что модель асинхронных агентов гарантирует отсутствие разделяемого состояния и как следствие отсутствие дедлоков в классическом их понимании. Но мой мозг уже прожжен традиционными подходами и поэтому пока не может переложить мало-мальски сложную распределенную систему на новую модель.
Цитировать34 задач, непрерывные, периодические и циклические. Решались чуть ли не на х286 процессоре :lol:
Ну так в 1992-м году x286 и был почти пределом совершенства :)
Мы НПО Маш предлагали решать их на R-3000 под VxWorks
Предполагалась совместная работа с Американцами или с Французами
ЦитироватьЦитировать34 задач, непрерывные, периодические и циклические. Решались чуть ли не на х286 процессоре :lol:
Ну так в 1992-м году x286 и был почти пределом совершенства :)
А то! Но решались!
ЦитироватьМы НПО Маш предлагали решать их на R-3000 под VxWorks
Предполагалась совместная работа с Американцами или с Французами
Эх, хороший был бы опыт.
Но полетел 186 со 187. И на Ямал-100. И только в 2000-м.
ЦитироватьЦитироватьЦитироватьЦитироватьДело не просто в надежности. Динамическая типизация - ненужный расход ресурсов. На борту они ограничены (характерны, к примеру, показатели ОЗУ 2 Мбайта).
2 Мбайта это не так уж мало, а оверхед динамической типизации по памяти не очень большой, скажем, 1 байт на примитивные типы или 1 слово на типы, определяемые пользователем. Тут больше страдает производительность из-за неявных преобразований несоответствующих типов. Но этот аспект в большей части в руках разработчика.
Больше всего страдает надежность, поскольку в результате буйного преобразования типов получается неизвестно что. Скажем преобразование вещественного в целое дробная часть отбрасывается. Возможно, в данной задаче подобная потеря точности недопустима, но компилятор/интерпретатор этого не заметит. Так же автоматическое управление памятью вносит непредсказуемые временные задержки, если куча закончилась и надо собирать мусор. А так же потенциальный отказ из-за полного исчерпания динамической памяти. Статическое распределение памяти гарантирует временные задержки и достаточность памяти при компиляции. Многозадачность вносит негарантированный доступ каждой задачи к процессору плюс возможные дедлоки в результате синхронизации задач.
Круто, но КА замкнутый объект, с конечным числом, как задач, так и параметров. Можно добиться приведения к 2-3 типам без потери точности и устойчивости объекта
Можно и гланды удалять через анальное отверстие. Понятно что упорными усилиями добиться работающей программы на не самом лучшем инструментарии. Но я имел ввиду не принципиальную теоретическую невозможность, а лишь то, что все эти малополезные для ПО КА примочки скорее осложняют задачу.
ЦитироватьЦитироватьЦитировать34 задач, непрерывные, периодические и циклические. Решались чуть ли не на х286 процессоре :lol:
Ну так в 1992-м году x286 и был почти пределом совершенства :)
А то! Но решались!
И наверняка без байт-кодов, виртуальных машин, динамического распределения памяти и прочего. Все-таки у меня создалось стойкое мнение, что здесь обитает разработчиков техники, подобной АМС, меньше, чем неразработчиков :)
Ни НПО Маш ни НПО Энергия на R-3000 под VxWorks в 1992-1993 г не решились. Мы все время опаздываем. А потом второпях запускаем через 20 лет.
И совсем не с VxWorks
ЦитироватьВадим Семенов пишет:
ЦитироватьAleks1961 пишет:
ЦитироватьВадим Семенов пишет:
Цитироватьbs пишет:
ЦитироватьДело не просто в надежности. Динамическая типизация ...
Но я имел ввиду не принципиальную теоретическую невозможность, а лишь то, что все эти малополезные для ПО КА примочки скорее осложняют задачу.
Согласен - простота, это надежность и легкость в отработке! Лучше 100 простых алгоритмов, чем один монстр! :lol:
ЦитироватьЦитироватьЦитироватьЦитировать34 задач, непрерывные, периодические и циклические. Решались чуть ли не на х286 процессоре :lol:
Ну так в 1992-м году x286 и был почти пределом совершенства :)
А то! Но решались!
И наверняка без байт-кодов, виртуальных машин, динамического распределения памяти и прочего. Все-таки у меня создалось стойкое мнение, что здесь обитает разработчиков техники, подобной АМС, меньше, чем неразработчиков :)
Жесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:
ЦитироватьЖесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:
А что было после 1994 года ?
ЦитироватьЦитироватьЖесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:
А что было после 1994 года ?
Полное разделение РКОтраслей России и Украины, только КА Океан-О и остался :cry: Потом долгий путь к сотрудничеству..., но как было не вернуть, пока :cry:
ЦитироватьЦитироватьБольше всего страдает надежность, поскольку в результате буйного преобразования типов получается неизвестно что. Скажем преобразование вещественного в целое дробная часть отбрасывается. Возможно, в данной задаче подобная потеря точности недопустима, но компилятор/интерпретатор этого не заметит.
Скорее наоборот, при разработке средствами с динамическими типами такие вещи принимаются как данность. Соответственно правильный цикл разработки подразумевает эффективное обнаружение и устранение таких проблем.
В переводе на русский разработчики будут вынуждены потратить увеличенное количество жопо-часов всматриваясь в код программы, тестируя его (в надежде что наткнуться на все скользкие моменты) и при этом без гарантии что выловят все то, что компилятор мог бы отловить автоматически.
ЦитироватьА вот статическая проверка типов в этом плане иногда расслабляет - достаточно где-то выполнить ошибочное явное приведение типов, чтобы компилятор не ругался, и забыть о нем через пару часов.
Расслябляет отсутсвие необходимости делать преобразование типов вообще. А при строгой типизации всегда есть повод задуматься, допустимо ли оно в данном случае. Даже если разработчик решил что допустимо, это место в программе становится автоматически помеченным явным преобразованием и независимый аудитор кода может легко его обнаружить рассмотреть этот вопрос еще раз.
По большому счету для подобных систем даже традиционные языки со строгой типизацией обладают недостаточно строгой типизацией чтобы компилятор автоматически проверял все то, что он мог бы в принципе проверить.
ЦитироватьЦитироватьТак же автоматическое управление памятью вносит непредсказуемые временные задержки, если куча закончилась и надо собирать мусор. А так же потенциальный отказ из-за полного исчерпания динамической памяти. Статическое распределение памяти гарантирует временные задержки и достаточность памяти при компиляции.
Здесь не могу ничего сказать, так как нет опыта в работе с автоматическим управлением памятью в ОС РВ. Хотя очевидно, что в этом направлении работы тоже активно ведутся: http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Real-time_garbage_collection
Не вижу там никакого решения проблемы. Там лишь написано, что работу сборщика мусора можно ограничивать. А как его ограничишь, если места в куче больше нет, и нужен кусок динамической памяти задаче, которая должна работать в реальном времени? По любому она будет ждать, пока сборщик мусора прочихается.
ЦитироватьВ общем же, ВМ не обязательно подразумевает автоматическое управление памятью.
Нк обязательно. И куча для даного рода задач не нужна. И даже стек не нужен и нежелателен. (возможно переполнение стека) Достаточно статического распределения памяти на этапе компиляции.
ЦитироватьОсновная задача, как мне кажется - это упростить реализацию защиты от серьезных непредвиденных ошибок за счет возможности контроллировать корректность каждой операции на уровне байт кода. Это не мешает реализовать неавтоматическое распределение памяти, если язык позволяет (например компилировать С/С++ в байт-код ВМ).
Мне байт-код представляется неактуальным. Байт-код это всего лишь еще один ассемблер (некоей виртуальной машины) в который генерит код компилятор. Ничего принципиального полезного он не добавляет. Байт-код и виртуальная машина нужны для портабельности уже скомпиленной программы. Но в данном случае это совершенно не актуально. Ну и С/C++ не самый лучший язык по причине весьма вольной работы с указателями.
ЦитироватьМногозадачность бывает разная. Философия Erlanga отчасти и вызывает у меня интерес тем, что модель асинхронных агентов гарантирует отсутствие разделяемого состояния и как следствие отсутствие дедлоков в классическом их понимании. Но мой мозг уже прожжен традиционными подходами и поэтому пока не может переложить мало-мальски сложную распределенную систему на новую модель.
Если там есть обмен сообщениями, то дедлоки могут быть. Задача А ожидает сообщения от задачи Б и засыпает. В это время задача Б начинает ждать сообщения от задачи А но никогда его не дождется. Понятно, что реальная цепочка может быть более чем из двух звеньев и весьма трудно обнаружима.
ЦитироватьИ наверняка без байт-кодов, виртуальных машин, динамического распределения памяти и прочего. Все-таки у меня создалось стойкое мнение, что здесь обитает разработчиков техники, подобной АМС, меньше, чем неразработчиков :)
Да да, когда-то настоящие разработчики, прокалывая перфокарты, смеялись над неразработчиками, вводящими шестнадцатеричные дампы.
Какой смысл доказывать, что можно все, что угодно разработать на ассемблере и запустить на 186-м? Это и ежу понятно, как и сопутствующая низкая эффективность, да и об этом ли речь на данный момент? Мы жестко отстаем по космическим программам и разработкам. При этом еще имеем копеечный бюджет. А хочется все сделать покруче и побыстрее.
Именно поэтому и начали появляться вопросы и идеи насчет более эффективных средств разработки. Что плохого в том, что современная аппаратная часть позволяет не считать циклы, а довериться работающему "как часы" планировщику? Какой смысл чахнуть годами над ассемблером, если можно получить качественную реализацию на С++ на порядок быстрее?
Надо смотреть шире. Методологии разработки ПО развиваются очень быстро. Но так уж сложилось, что в некоторых отраслях они развиваются разными путями. Но это не значит, что если где-то до сих пор считают циклы, то там нельзя успешно применить методы, успешно осовенные в других отраслях, где циклы давно уже никто не считает.
ЦитироватьЖесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:
Вот это правильно, про циклы я не упомянул. Еще один момент, который может проверять компилятор правильно сконструированного языка - что каждый цикл либо гарантированно заканчивается за конечное число итераций либо имеет в явном виде счетчик итераций. Если цикл не завершился за разумное число итераций, происходит выход из цикла и программист должен написать какой-то код, как поступать в этом случае.
ЦитироватьНадо смотреть шире. Методологии разработки ПО развиваются очень быстро. Но так уж сложилось, что в некоторых отраслях они развиваются разными путями. Но это не значит, что если где-то до сих пор считают циклы, то там нельзя успешно применить методы, успешно осовенные в других отраслях, где циклы давно уже никто не считает.
Ээ, вы не так восприняли. Я не за ассемблер, а за разумное соответствие задачам инструментария. Меня никто не убедит, даже разработчики ФГ (хотя, надеюсь, и не стали бы), что там позарез нужна динамическая память, сборщики мусора, виртуальные машины и прочее. Я вообще удивляюсь, что тут так много этому уделяют внимания. Ощущение, что и на этом форуме сисадмины и кодировщики ширпотребконвейера от программистики занимают немалое место. Диалог между реальными инженерами-программистами-разработчиками протекал бы совсем по-иному. Оставляю себе право на ошибку :)
ЦитироватьЦитироватьЖесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:
Вот это правильно, про циклы я не упомянул. Еще один момент, который может проверять компилятор правильно сконструированного языка - что каждый цикл либо гарантированно заканчивается за конечное число итераций либо имеет в явном виде счетчик итераций. Если цикл не завершился за разумное число итераций, происходит выход из цикла и программист должен написать какой-то код, как поступать в этом случае.
Переход к решению следующей задачи если они не связанны, с записью в ТМИ о нерешенной. И на стенде будут знать что и как. От-латка продолжится! :lol:
ЦитироватьВзять одну троированную ЦВМ, состоящую в придачу из нескольких граней для горячего и холодного резерва. Проще реализуется, чем куча отдельных контроллеров, которые еще нужно согласовать и научить отрабатывать ошибки согласования. Потом поменяли один блок на новый с другим протоколом и айда все связи перелопачивать.
Взаимодействие контроллеров всё-таки более предсказуемо по последствиям, чем взаимодействие находящихся в общей памяти программ.
А протоколы надо использовать стандартные и массово используемые (а следовательно вылизанные), чем изобретать велосипед непредсказуемой кривизны.
ЦитироватьЦитироватьНадо смотреть шире. Методологии разработки ПО развиваются очень быстро. Но так уж сложилось, что в некоторых отраслях они развиваются разными путями. Но это не значит, что если где-то до сих пор считают циклы, то там нельзя успешно применить методы, успешно осовенные в других отраслях, где циклы давно уже никто не считает.
Ээ, вы не так восприняли. Я не за ассемблер, а за разумное соответствие задачам инструментария. Меня никто не убедит, даже разработчики ФГ (хотя, надеюсь, и не стали бы), что там позарез нужна динамическая память, сборщики мусора, виртуальные машины и прочее. Я вообще удивляюсь, что тут так много этому уделяют внимания. Ощущение, что и на этом форуме сисадмины и кодировщики ширпотребконвейера от программистики занимают немалое место. Диалог между реальными инженерами-программистами-разработчиками протекал бы совсем по-иному. Оставляю себе право на ошибку :)
Ругаются на стенде, при анализе результатов, а до этого инженеры-программисты живут в другом мире! :shock:
ЦитироватьЦитироватьЦитироватьЖесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:
Вот это правильно, про циклы я не упомянул. Еще один момент, который может проверять компилятор правильно сконструированного языка - что каждый цикл либо гарантированно заканчивается за конечное число итераций либо имеет в явном виде счетчик итераций. Если цикл не завершился за разумное число итераций, происходит выход из цикла и программист должен написать какой-то код, как поступать в этом случае.
Переход к решению следующей задачи если они не связанны, с записью в ТМИ о нерешенной. И на стенде будут знать что и как. От-латка продолжится! :lol:
А в реальном полете по крайне мере не повлияет на выполнение остальных задач. Может быть бесконечный цикл вызван каким-то конкретным редким сочетанием входных данных, которые при отладке на земле не встретились.
ЦитироватьПо большому счету для подобных систем даже традиционные языки со строгой типизацией обладают недостаточно строгой типизацией чтобы компилятор автоматически проверял все то, что он мог бы в принципе проверить.
Золотые слова! Именно об этом я и говорю. Т.е. по факту даже при статической типизации нужны средства контроля (аудит, тестирование, и т.п.). Но тогда нет никакого выигрыша :)
ЦитироватьНе вижу там никакого решения проблемы. Там лишь написано, что работу сборщика мусора можно ограничивать. А как его ограничишь, если места в куче больше нет, и нужен кусок динамической памяти задаче, которая должна работать в реальном времени? По любому она будет ждать, пока сборщик мусора прочихается.
Наверное считаете, что сборщик мусора работает только, когда куча исчерпана? Это было бы глупо. Сборщик мусора - параллельная задача, выполняемая периодически при определенных условиях. Если при этом она еще и гарантирует в разумных пределах выполнение других задач, работающих с кучей, то все относительно красиво.
ЦитироватьНк обязательно. И куча для даного рода задач не нужна. И даже стек не нужен и нежелателен. (возможно переполнение стека) Достаточно статического распределения памяти на этапе компиляции.
Статическое распределение страдает неэффективностью и переполнение статически распределенных блоков возможно ровно настолько, насколько возможно переполнение стека. Что же теперь, можно сделать вывод, что оно нежелательно для данного рода задач?
ЦитироватьБайт-код и виртуальная машина нужны для портабельности уже скомпиленной программы.
Это один аспект байт-кода. Я рассматриваю его в совершенно другом аспекте - ВМ, выполняя байт-код, имеет возможность обеспечить безопасность (исключить переполнение стека, обращение по указателю вне сегмента данных, и т.п.). Т.е. байт-код позволяет использовать более простую аппаратную реализацию (т.е. процессор без страничной защиты к примеру).
ЦитироватьНо в данном случае это совершенно не актуально. Ну и С/C++ не самый лучший язык по причине весьма вольной работы с указателями.
Что вольного в работе с указателями на С++? Ассемблер тогда вообще кошмар наяву :)
ЦитироватьЕсли там есть обмен сообщениями, то дедлоки могут быть. Задача А ожидает сообщения от задачи Б и засыпает. В это время задача Б начинает ждать сообщения от задачи А но никогда его не дождется. Понятно, что реальная цепочка может быть более чем из двух звеньев и весьма трудно обнаружима.
Бесспорно, однако в этой модели потоки сообщений наглядны и позволяют выполнять детальный анализ, возможно даже формальный. Надо покопать.
ЦитироватьЦитироватьЦитироватьЦитироватьЖесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:
Вот это правильно, про циклы я не упомянул. Еще один момент, который может проверять компилятор правильно сконструированного языка - что каждый цикл либо гарантированно заканчивается за конечное число итераций либо имеет в явном виде счетчик итераций. Если цикл не завершился за разумное число итераций, происходит выход из цикла и программист должен написать какой-то код, как поступать в этом случае.
Переход к решению следующей задачи если они не связанны, с записью в ТМИ о нерешенной. И на стенде будут знать что и как. От-латка продолжится! :lol:
А в реальном полете по крайне мере не повлияет на выполнение остальных задач. Может быть бесконечный цикл вызван каким-то конкретным редким сочетанием входных данных, которые при отладке на земле не встретились.
Редкое сочетание входных данных это случай! Но в другой ветке уже писал о фильтрации ИД при начале работы СПО, модулей и тд
ЦитироватьВзять одну троированную ЦВМ
Про троированную ЦВМ было бы интересно почитать, например на ту которая на КК Союз применяется. Что там представляет одельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".
ЦитироватьЦитироватьВзять одну троированную ЦВМ
Про троированную ЦВМ было бы интересно почитать, например на ту которая на КК Союз применяется. Что там представляет одельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".
2 из 3 и третий не в счет, в этот раззз. По времени, величине и как в алгоритме :!: И так всегда :!: Третий лишний :!:
ЦитироватьА в реальном полете по крайне мере не повлияет на выполнение остальных задач. Может быть бесконечный цикл вызван каким-то конкретным редким сочетанием входных данных, которые при отладке на земле не встретились.
Вот читаю о дедлоках, циклах в АМС, которая имеет всего-то несколько процессоров и весьма ограниченное количество событий. И думаю, что же это было бы с системой, в которой за секунду генерируются сотни тысяч внешних и внутренних событий и информационных связей. И работает, с тысячами процессоров, с иерархией этих процессоров и процессов. Без виртуальных машин. Без Эрлангов. Сложность этой системы такова, что не было даже возможности априорно рассчитать время доставки внутреннего сообщения, а при наступлении какой-либо проблемы обработки данных эту систему часто просто оставляли работать, не трогая, и она "приходила в себя". Наверное, при создании АМС не нужно умножать сущности и сложности без надобности.
ЦитироватьЦитироватьПо большому счету для подобных систем даже традиционные языки со строгой типизацией обладают недостаточно строгой типизацией чтобы компилятор автоматически проверял все то, что он мог бы в принципе проверить.
Золотые слова! Именно об этом я и говорю. Т.е. по факту даже при статической типизации нужны средства контроля (аудит, тестирование, и т.п.). Но тогда нет никакого выигрыша :)
Я говорю о другом - о том что при разработке правильного языка и компилятора ситуацию можно было бы еще улучшить.
ЦитироватьЦитироватьНе вижу там никакого решения проблемы. Там лишь написано, что работу сборщика мусора можно ограничивать. А как его ограничишь, если места в куче больше нет, и нужен кусок динамической памяти задаче, которая должна работать в реальном времени? По любому она будет ждать, пока сборщик мусора прочихается.
Наверное считаете, что сборщик мусора работает только, когда куча исчерпана? Это было бы глупо. Сборщик мусора - параллельная задача, выполняемая периодически при определенных условиях. Если при этом она еще и гарантирует в разумных пределах выполнение других задач, работающих с кучей, то все относительно красиво.
Я так не считаю, но параллельная работа сборзика мусора не гаратирует, что мусор будет собран к тому моменту как понадобится динамическая память.
ЦитироватьЦитироватьНк обязательно. И куча для даного рода задач не нужна. И даже стек не нужен и нежелателен. (возможно переполнение стека) Достаточно статического распределения памяти на этапе компиляции.
Статическое распределение страдает неэффективностью и переполнение статически распределенных блоков возможно ровно настолько, насколько возможно переполнение стека. Что же теперь, можно сделать вывод, что оно нежелательно для данного рода задач?
Эффективность по объемам памяти в данном случае не главное. Там не такие объемы данных, чтобы они стали проблемой. А переполнения там быть не может в принципе просто потому что все данные имеют фиксированный размер.
ЦитироватьЦитироватьБайт-код и виртуальная машина нужны для портабельности уже скомпиленной программы.
Это один аспект байт-кода. Я рассматриваю его в совершенно другом аспекте - ВМ, выполняя байт-код, имеет возможность обеспечить безопасность (исключить переполнение стека, обращение по указателю вне сегмента данных, и т.п.). Т.е. байт-код позволяет использовать более простую аппаратную реализацию (т.е. процессор без страничной защиты к примеру).
Не может ВМ ничего исключить. Она может лишь отловить эту ситуацию и застрелиться. Потому как что делать, если стек переполнился один хрен никто не знает.
ЦитироватьЧто вольного в работе с указателями на С++?
То что любое число может интерпретироваться как указатель.
ЦитироватьАссемблер тогда вообще кошмар наяву :)
А я и не предлагаю все писать на ассемблере.
ЦитироватьРугаются на стенде, при анализе результатов, а до этого инженеры-программисты живут в другом мире! :shock:
Да я отлично знаю этот мир, там точно не ведут таких пространных диспутов о программировании, хоть и программируют тоже :)
ЦитироватьЦитироватьЦитироватьВзять одну троированную ЦВМ
Про троированную ЦВМ было бы интересно почитать, например на ту которая на КК Союз применяется. Что там представляет одельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".
2 из 3 и третий не в счет, в этот раззз. По времени, величине и как в алгоритме :!: И так всегда :!: Третий лишний :!:
При отказе 1 канала, один из оставшийся в резерв и летим на одном и тд.
ЦитироватьЦитироватьЦитироватьВзять одну троированную ЦВМ
Про троированную ЦВМ было бы интересно почитать, например на ту которая на КК Союз применяется. Что там представляет одельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".
2 из 3 и третий не в счет, в этот раззз. По времени, величине и как в алгоритме :!: И так всегда :!: Третий лишний :!:
Ну это то понятно. Вопрос в том, что потом происходит с третим процессором. Выключение? Загрузка состояния соседнего и продолжение работы втроем? И вообще, что именно сравнивается? Каждое состояние шины данных каждого модуля в каждый момент? Операции записи в порты? Просто абстрактный компаратор, в который каждый из модулей отсылает некоторою информацию для сравнения аналогичной у соседей?
ЦитироватьА в реальном полете по крайне мере не повлияет на выполнение остальных задач. Может быть бесконечный цикл вызван каким-то конкретным редким сочетанием входных данных, которые при отладке на земле не встретились.
Разве эта проблема вообще актуальна в нормальной ОС РВ? Одна задача зациклилась (не говорю, что это должна быть штатная ситуация) - остальные нормально работают. Вытесняющая многозадачность с приоритезацией работает. В минимальном варианте параллельно работают дежурные задачи, которые позволяют провести перезагрузку.
ЦитироватьЦитироватьА в реальном полете по крайне мере не повлияет на выполнение остальных задач. Может быть бесконечный цикл вызван каким-то конкретным редким сочетанием входных данных, которые при отладке на земле не встретились.
Вот читаю о дедлоках, циклах в АМС, которая имеет всего-то несколько процессоров и весьма ограниченное количество событий. И думаю, что же это было бы с системой, в которой за секунду генерируются сотни тысяч внешних и внутренних событий и информационных связей. И работает, с тысячами процессоров, с иерархией этих процессоров и процессов. Без виртуальных машин. Без Эрлангов. Сложность этой системы такова, что не было даже возможности априорно рассчитать время доставки внутреннего сообщения, а при наступлении какой-либо проблемы обработки данных эту систему часто просто оставляли работать, не трогая, и она "приходила в себя". Наверное, при создании АМС не нужно умножать сущности и сложности без надобности.
Так и я о том, что не нужно все это в данном случае. Зато весьма не помешали бы другие инструменты, повышающие надежность кода. Но поскольку их нет (видимо область достаточно узкая и специфичная, чтобы разработчики языков и компиляторов ею озаботились) то программируют на том, на чем есть. На языках "общего пользования". Типа Модулы-2 на ИСС. Не самый плохой выбор из существующего.
Про троированную ЦВМ было бы интересно почитать, например на ту, которая на КК Союз применяется. Что там представляет отдельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".
Посмотрите в Политехническом музее, или в Виртуальном компьютерном музее, или на сайте НИИ Аргон. "Аргон-16" полетел в последний раз с людьми на МКС. За 35 лет работы в космосе ни одного отказа.
ЦитироватьЯ вообще удивляюсь, что тут так много этому уделяют внимания. Ощущение, что и на этом форуме сисадмины и кодировщики ширпотребконвейера от программистики занимают немалое место. Диалог между реальными инженерами-программистами-разработчиками протекал бы совсем по-иному. Оставляю себе право на ошибку
Скажем так - когда-то объектно-ориентированное программирование казалось системным программистам сферическими конями в вакууме. Где мы были тогда, и где мы сейчас? Простая методология, а какой качественный скачок.
Я лишь пытаюсь протолкнуть идею о том, что не все новшества ущербны. Надо анализировать и сравнивать преимущества/недостатки.
Человек поделислся своим опытом работы с Erlang и его тут же запинали, без какого-либо анализа. Не по инженерному это :)
Для космической БЦВМ не так важно, как быстро она считает, а то как долго и без отказов она летает!
ЦитироватьВзаимодействие контроллеров всё-таки более предсказуемо по последствиям, чем взаимодействие находящихся в общей памяти программ.
Спорно.
ЦитироватьА протоколы надо использовать стандартные и массово используемые (а следовательно вылизанные), чем изобретать велосипед непредсказуемой кривизны.
Протоколы стандартизированы только на самом низком уровне. Дальше кто в лес, кто по дрова. Возьмем те же датчики ориентации. Как здесь уже писали - одни выдают направляющие косинусы, другие кватернионы. Переход с одних на другие в коде микроконтроллера и на языке высокого уровня - небо и земля. Сложность сопряжения и тестирования отличается на порядок.
ЦитироватьЦитироватьА в реальном полете по крайне мере не повлияет на выполнение остальных задач. Может быть бесконечный цикл вызван каким-то конкретным редким сочетанием входных данных, которые при отладке на земле не встретились.
Разве эта проблема вообще актуальна в нормальной ОС РВ? Одна задача зациклилась (не говорю, что это должна быть штатная ситуация) - остальные нормально работают. Вытесняющая многозадачность с приоритезацией работает. В минимальном варианте параллельно работают дежурные задачи, которые позволяют провести перезагрузку.
Это если от нее другие задачи не зависят. И это не есть хорошо, сваливаться в защищенный режим от каждого чиха. Может быть в данном случае было бы уместно выбросить данный конкретный набор данных и попытаться продолжить со следующим. Может быть задача ожидает данных от звездного датчика, а они почему-то не поступают. И в данном случае можно попробовать его перезапустить, щекнув питанием. Да мало ли. Вобщем, в любом случае, если что-то идет не по плану практически всегда есть набор какие-то разумных действий, которые можно предпринять, вместо того, чтобы уходить в тупую задумчивость.
ЦитироватьПро троированную ЦВМ было бы интересно почитать, например на ту, которая на КК Союз применяется. Что там представляет отдельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".
Посмотрите в Политехническом музее, или в Виртуальном компьютерном музее, или на сайте НИИ Аргон. "Аргон-16" полетел в последний раз с людьми на МКС. За 35 лет работы в космосе ни одного отказа.
А что там смотреть? Красивые фото? Описание логики работы в сети я не видел.
ЦитироватьВот читаю о дедлоках, циклах в АМС, которая имеет всего-то несколько процессоров и весьма ограниченное количество событий. И думаю, что же это было бы с системой, в которой за секунду генерируются сотни тысяч внешних и внутренних событий и информационных связей. И работает, с тысячами процессоров, с иерархией этих процессоров и процессов. Без виртуальных машин. Без Эрлангов. Сложность этой системы такова, что не было даже возможности априорно рассчитать время доставки внутреннего сообщения, а при наступлении какой-либо проблемы обработки данных эту систему часто просто оставляли работать, не трогая, и она "приходила в себя". Наверное, при создании АМС не нужно умножать сущности и сложности без надобности.
Ну вот, а ведь интересно было бы узреть эту систему под управлением Эрланга, при которой вообще не было бы проблем с обработкой данных :)
ЦитироватьЯ говорю о другом - о том что при разработке правильного языка и компилятора ситуацию можно было бы еще улучшить.
Это уже тема DSL. Тема отдельная и заслуживающая внимания сама по себе.
ЦитироватьЯ так не считаю, но параллельная работа сборзика мусора не гаратирует, что мусор будет собран к тому моменту как понадобится динамическая память.
Но средняя и максимальная задержка в таком крайнем случае все-же поддается расчетам.
ЦитироватьЭффективность по объемам памяти в данном случае не главное. Там не такие объемы данных, чтобы они стали проблемой. А переполнения там быть не может в принципе просто потому что все данные имеют фиксированный размер.
По аналогии могу сказать, что переполнения стека не может быть в принципе, т.к. все выделяемые на стеке данные имеют фиксированный размер. Улавливаете?
ЦитироватьНе может ВМ ничего исключить. Она может лишь отловить эту ситуацию и застрелиться. Потому как что делать, если стек переполнился один хрен никто не знает.
Вот именно, что она может максимально корректно отработать такую ситуацию. Запустить задачу защищенного режима или процесс горячего перезапуска. И все это на простейшем процессоре без сложной системы исключений.
ЦитироватьТо что любое число может интерпретироваться как указатель.
Если 0 - это любое число, то да :) Куда же подевалась жесткая типизация? Не забываем, что С++ - это язык со строгой типизацией.
ЦитироватьДа я отлично знаю этот мир, там точно не ведут таких пространных диспутов о программировании, хоть и программируют тоже :)
Им просто нужно почаще общаться с "неразработчиками" :lol:
ЦитироватьПротоколы стандартизированы только на самом низком уровне. Дальше кто в лес, кто по дрова. Возьмем те же датчики ориентации. Как здесь уже писали - одни выдают направляющие косинусы, другие кватернионы. Переход с одних на другие в коде микроконтроллера и на языке высокого уровня - небо и земля. Сложность сопряжения и тестирования отличается на порядок.
Если есть только 2 формата, то какие проблемы ? Обязать выдавать по опции на этапе производства либо один, либо другой, либо оба. Написать утилиты конвертации. Если производство - у нас, конечно. Вот это и будет полезным делом, межотраслевая стандартизация. Что, так трудно создать в космической отрасли аналог IEEE или ITU ? Или там тоже у нас победил принцип либерализма, пиши-верти что хочешь, пусть другие разбираются и едят. Так виртуальная память тут не поможет, только реальная, в мозгах, и еще разум :)
ЦитироватьНу это то понятно. Вопрос в том, что потом происходит с третим процессором. Выключение? Загрузка состояния соседнего и продолжение работы втроем? И вообще, что именно сравнивается? Каждое состояние шины данных каждого модуля в каждый момент? Операции записи в порты? Просто абстрактный компаратор, в который каждый из модулей отсылает некоторою информацию для сравнения аналогичной у соседей?
Троирование на уровне логических элементов И-НЕ на кристалле процессора. Дальше троирование + резервирование ЦВМ "гранями" - одна активна, две в горячем резерве, одна в холодном. В простейшем случае - грань сбойнула, забыли про нее. Вводим одну из холодного резерва и работаем на 3-х оставшихся. И так дальше до одной. Можно помутить с восстановлением и диагностикой. Если диагностика прошла, вернуть в холодный резерв.
ЦитироватьНу вот, а ведь интересно было бы узреть эту систему под управлением Эрланга, при которой вообще не было бы проблем с обработкой данных :)
Сию минуту! Внесу предложение, пусть перепишут миллионы строк кода под Эрланг, вот уж тогда местным НОТ-тестерам будет поле развернутсья :) В системе этой и так никаких серьезных проблем нет, работает себе и работает :) Просто ее создавали те, кто не привык растекаться атомарным слоем по тарелке :)
ЦитироватьЦитироватьДа я отлично знаю этот мир, там точно не ведут таких пространных диспутов о программировании, хоть и программируют тоже :)
Им просто нужно почаще общаться с "неразработчиками" :lol:
С целью ? :) Если это НЕ-разработчики, то смысла нет :)
ЦитироватьИли там тоже у нас победил принцип либерализма,
Ну за что боролись... :)
Межотраслевая стандартизация уж больно далеко за рамками досягаемости программистов. И слишком уж это запредельный аргумент в пользу микроконтроллеров.
Гибкость и эффективность на местах все-таки сподручней будут, чем надежды на никак от тебя не зависящие стандарты.
Тут еще такая важная вещь - кадры... Они разные, и таких которых хотелось бы побольше, их очень мало. Приходится работать с теми, кто есть.
Поэтому еще один важный аспект методологии разработки - это насколько эффективно она позволяет использовать программистов не самого высокого уровня под управлением более опытных спецов.
Очевидно, что компилируемые языки высокого уровня со строгой типизацией выигрывают как минимум по нагрузке на аудит. Отсутствие необходимости считать циклы тоже не маленький плюс. Какие еще критерии можно добавить? Что-то уже туго соображаю. Скоро вставать :)
ЦитироватьЦитироватьДело не просто в надежности. Динамическая типизация - ненужный расход ресурсов. На борту они ограничены (характерны, к примеру, показатели ОЗУ 2 Мбайта).
2 Мбайта это не так уж мало, а оверхед динамической типизации по памяти не очень большой, скажем, 1 байт на примитивные типы или 1 слово на типы, определяемые пользователем. Тут больше страдает производительность из-за неявных преобразований несоответствующих типов. Но этот аспект в большей части в руках разработчика.
Замечание по памяти актуально - по опыту динамические языки используют при том-же алгоритме ее в разы больше чем строго типизированные.
Но нюанс что на функциональных намного удобнее реализуются изощренные алгоритмы, которые могут экономить и память и мегагерцы.
Конкретно ВМ Erlang на 2 Мбайтах запускали точно.
ЦитироватьЦитироватьфункциональный язык программирования по своей сути не содержит понятия "точка исполнения" программы, что противоречит концепции состояний. А управление БА - это именно состояния.
Да, это меня и смущает.
ЦитироватьТак что не самое подходящее место для функционального языка - борт КА.
Тем не менее на этом языке разрабатывают гораздо более сложные системы, чем расчет примитивных отображений.
Функциональный язык там вроде в основе. Но основная модель разработки - это асинхронные агенты и обмен сообщений между ними. Последнее позволяет реализовать произвольное состояние (с небольшой помощью от ран-тайма по сохранению/восстановлению данных). Тут я не спец и рассуждаю, исходя из общих соображений. Может zyxman прольет свет на этот аспект.
Обязательно. Только сейчас ищу/придумываю достойную задачу.
Вообще отсутствие состояний в Erlang принципиальная основа идеологии. То есть буквально считается, что возвращаемое кодом значение должно зависеть только от входного значения и никаких внутренних состояний.
И таким образом существенно облегчается проблема тестирования, тк уменьшается пространство состояний.
Состояния реализуются хитро, используя асинхронность, легковесность процессов и сообщения.
Плюс есть несколько уровней БД:
1. Простейшая система ключ-значение внутри каждого процесса
2. Несколько вариантов таблиц вроде классических хешей и массивов, работающие внутри ВМ
3. Распределенная СУБД с оптимистичным названием Mnesia :wink: - должна тут всем понравиться - её можно запустить на нескольких ВМ, и она будет автоматически поддерживать горячую синхронизацию всех собственных копий, то есть если у вас какая-то нода по какой-то причине отключилась от сети, то при последующем подключении она автоматически засинхронизирует свои таблицы с другими нодами.
Ок, попробую сразу к делу.
Я сейчас напишу упрощенный эмулятор ракетного двигателя на сжатом газе.
Двигатель имеет состояния: on; off; offToOn; onToOff
двигатель управляется сообщениями: on, off.
-module(eng).
-export([mstart/0]).
mstart() ->
off().
%% end.
off() ->
receive
on -> offToOn();
_Other -> {error, unknown_msg}
end.
on() ->
receive
off -> onToOff();
_Other -> {error, unknown_msg}
end.
offToOn() ->
receive
after 1000 -> on()
end.
onToOff() ->
receive
after 1000 -> off()
end.
after это таймаут в миллисекундах.
Дальше можем попробовать сделать автомат состояний бака и доработать двигатель чтобы он регулярно сообщал баку что откушал у того сколько-то топлива, ну и "наверх", что тяга столько-то :wink:
ЦитироватьЦитироватьЯ так не считаю, но параллельная работа сборзика мусора не гаратирует, что мусор будет собран к тому моменту как понадобится динамическая память.
Но средняя и максимальная задержка в таком крайнем случае все-же поддается расчетам.
Максимальная возможная обычно слишком велика, чтоб быть приемлемой для задач реального времени.
ЦитироватьЦитироватьЭффективность по объемам памяти в данном случае не главное. Там не такие объемы данных, чтобы они стали проблемой. А переполнения там быть не может в принципе просто потому что все данные имеют фиксированный размер.
По аналогии могу сказать, что переполнения стека не может быть в принципе, т.к. все выделяемые на стеке данные имеют фиксированный размер. Улавливаете?
Зато количество выделяемых на стеке данных не фиксировано. Улавливаете? :)
ЦитироватьЦитироватьНе может ВМ ничего исключить. Она может лишь отловить эту ситуацию и застрелиться. Потому как что делать, если стек переполнился один хрен никто не знает.
Вот именно, что она может максимально корректно отработать такую ситуацию. Запустить задачу защищенного режима или процесс горячего перезапуска. И все это на простейшем процессоре без сложной системы исключений.
Это не максимально корректно, а сваливание в защитный режим и перезагрузку от каждого бага, вместо того чтобы устранить сами баги еще на этапе разработки ПО и по возможности их источники выбором адекватных инструментов программирования. С шансами провалить миссию болтаясь в защитном режиме вместо выполнения задачи да и вовсе потерять аппарат. Это же не то же самое, что окошки под виндос программировать. Там упала задача да и хрен с ней, еще раз запустим. Компьютер от этого не потерян.
ЦитироватьЦитироватьТо что любое число может интерпретироваться как указатель.
Если 0 - это любое число, то да :)
0 любое, и любое другое число тоже любое.
ЦитироватьКуда же подевалась жесткая типизация? Не забываем, что С++ - это язык со строгой типизацией.
Вот такая в С++ жеская типизация. Я ж говорю, языки "общего назначения" оставляют желать лучшего. А С++ и подавно. Они представляют собой компромисс, в частности чтобы не слишком осложнять жизнь писателям окошек и позволять программирование в стиле "сначала как руки упали, а потом как пошло".
ЦитироватьЦитироватьНу это то понятно. Вопрос в том, что потом происходит с третим процессором. Выключение? Загрузка состояния соседнего и продолжение работы втроем? И вообще, что именно сравнивается? Каждое состояние шины данных каждого модуля в каждый момент? Операции записи в порты? Просто абстрактный компаратор, в который каждый из модулей отсылает некоторою информацию для сравнения аналогичной у соседей?
Троирование на уровне логических элементов И-НЕ на кристалле процессора. Дальше троирование + резервирование ЦВМ "гранями" - одна активна, две в горячем резерве, одна в холодном. В простейшем случае - грань сбойнула, забыли про нее. Вводим одну из холодного резерва и работаем на 3-х оставшихся. И так дальше до одной. Можно помутить с восстановлением и диагностикой. Если диагностика прошла, вернуть в холодный резерв.
Сомнительно что это так, объяснять почему лень. И вообще я бы предпочел не домыслы, а ссылку на реальную информацию.
ЦитироватьЦитироватьИли там тоже у нас победил принцип либерализма,
Ну за что боролись... :)
Межотраслевая стандартизация уж больно далеко за рамками досягаемости программистов. И слишком уж это запредельный аргумент в пользу микроконтроллеров.
Гибкость и эффективность на местах все-таки сподручней будут, чем надежды на никак от тебя не зависящие стандарты.
Это не в пользу микроконтроллеров, это вообще и просто - в пользу :) И зря вы думаете, что стандартизация за рамками программистов и разработчиков. Как раз эти разработчики и основывают такие институты и документы стандартизации. Кому, как не им, понимать важность этого дела, чтобы избежать изобретения очередного велосипеда по заданию начальства. Что у нас меняется в звездном небе ? Ничего. Сенсоры принципиально иные ? Нет. Значит, по моему мнению, уже мог быть стандарт с условным названием ICS45, описывающий алгоритм системы звездной ориентации, математически выверенный и на уровне мета-языка. Бери и реализуй. То же самое с аппаратной частью, датчик такой-то, исполнительный механизм такой-то ? Для него стандартизован такой-то интерфейс, бери и реализуй, повышай модульность всей платформы.
ЦитироватьЦитироватьВзять одну троированную ЦВМ
Про троированную ЦВМ было бы интересно почитать, например на ту которая на КК Союз применяется. Что там представляет одельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".
Троирование с голосованием не единственный и не всегда оптимальный вариант.
Есть еще вариант коррекции ошибок - просто над вычислительными блоками стоят блоки коррекции ошибок, корректирующие вычисления по таблице истинности блока. Естественно, вычислительных блоков имеется избыточное количество и когда исчерпывается возможность блока коррекции корректировать ошибки, то ошибающийся блок совсем отключается.
ЦитироватьТут еще такая важная вещь - кадры... Они разные, и таких которых хотелось бы побольше, их очень мало. Приходится работать с теми, кто есть.
Их было бы побольше, по крайней мере на одного, если бы у нас поняли, что кроме денег и работы еще и окружение нужно создать хорошее, для отдыха и той же работы :) Вот в Сколково там кого-то зовут. Представьте, человек живет в Швейцарии, на берегу озера, чисто, красиво, несуетливо, небыдливо, цивилизованно. Все условия для труда и отдыха. Тут ему говорят, езжай к нам, мы тебе денег дадим в 3 раза больше. Какой идиот найдется ехать из Швейцарии в Москвабад, где просто не понимают, что такое комфорт и набор параметров нормального уровня жизни ? Там этот набор трансформировался в сингулярность монеты. Цивилизованный человек существовать в этой сингулярности не сможет.
ЦитироватьЦитироватьВот читаю о дедлоках, циклах в АМС, которая имеет всего-то несколько процессоров и весьма ограниченное количество событий. И думаю, что же это было бы с системой, в которой за секунду генерируются сотни тысяч внешних и внутренних событий и информационных связей. И работает, с тысячами процессоров, с иерархией этих процессоров и процессов. Без виртуальных машин. Без Эрлангов. Сложность этой системы такова, что не было даже возможности априорно рассчитать время доставки внутреннего сообщения, а при наступлении какой-либо проблемы обработки данных эту систему часто просто оставляли работать, не трогая, и она "приходила в себя". Наверное, при создании АМС не нужно умножать сущности и сложности без надобности.
Ну вот, а ведь интересно было бы узреть эту систему под управлением Эрланга, при которой вообще не было бы проблем с обработкой данных :)
Вообще-то Erlang разработали в фирме Ericsson, когда обнаружили сложность разработки нового поколения АТС, управляемых компьютерами.
А что есть АТС - фактически это контактное поле на число абонентов, некоторое количество сервисных устройств (вроде дешифраторов тонального набора) и некоторое количество управляющих всем этим компьютеров с программами.
То есть например коммутатор на миллион абонентов это миллион помноженный на число сервисных функций конечных автоматов. Не совсем простых конечных автоматов. Взаимодействующих асинхронно конечных автоматов.
Когда-то мне давали пример сложной системы, где получилось ЕМНИС около 1.5млн строк кода на С++, но надежной работы добиться не удалось; параллельно успешно сделали систему выполнявшую ту-же задачу на Erlang и она успешно пошла в работу.
ЦитироватьВот такая в С++ жеская типизация. Я ж говорю, языки "общего назначения" оставляют желать лучшего. А С++ и подавно. Они представляют собой компромисс, в частности чтобы не слишком осложнять жизнь писателям окошек и позволять программирование в стиле "сначала как руки упали, а потом как пошло".
Я видел и Modula и Ada. Собственно я немножко с VHDL имел дело, который по сути подмножество Ada.
Так вот по-моему чуть не Дейкстра шутил, что Ada это как программирование видят военные :D Перебор вобщем - нормального программиста сложно заставить в такой формальной среде корректно работать.
ЦитироватьКогда-то мне давали пример сложной системы, где получилось ЕМНИС около 1.5млн строк кода на С++, но надежной работы добиться не удалось; параллельно успешно сделали систему выполнявшую ту-же задачу на Erlang и она успешно пошла в работу.
Ну вы просто как рекламный агент этого Эрланга или Эрикссона, или человек, получивший корочку по программированию на этом Эрланге :) Я поверю, что там это полезно, только в АМС зачем ? В фирмах, проектирующих сложные распределенные системы, могут использовать свои, почти внутрикорпоративные языки программирования. Так что, теперь за ними всеми гоняться ? :)
ЦитироватьНу вы просто как рекламный агент этого Эрланга или Эрикссона, или человек, получивший корочку по программированию на этом Эрланге :)
Эрикссон уже давно Эрлангом не занимается.
А мне лично обидно что высоконадежные большие системы сейчас делаются чаще всего на Enterprise Java, которая намного менее элегантна чем Erlang мягко говоря.
Даже чуть по другому скажу: хотя я всей душой за либеральную демократию, мне очень нравится, как иногда красиво решали задачи в СССР - показывали действительно системный подход.
А эти самые Enterprise Java, Modula, Ada неоригинальны и как раз по-западному - вот решили что нужно ужесточить типизацию и закрутили её по самое нехочу, ну и вобщем и с остальным там то же самое - заставили вобщем программиста - творческого человека строем ходить.
Я думаю что можно такой-же надежности достичь и без такой строгости.
ЦитироватьЯ думаю что можно такой-же надежности достичь и без такой строгости.
Вот вам пример попыток обеспечения надежности нашим вариантом системного подхода, раскрытым во всей силе. Я склоняюсь к тому, что этот подход в нашей стране - максимально верный, сильно опережающий по результатам всевозможные ухищрения с тестами. Как это ни печально.
http://www.youtube.com/watch?v=Wg9bpPf_AZM
ЦитироватьЧистая асинхронная модель, кстати, может быть весьма кстати в данной пердметной области. Ведь управляемые процессы асинхронны по природе
Вы не правы. Как раз наоборот. В основе управления КА лежит циклограмма. Т.е. по классификации систем реального времени на "управляемые событиями" (асинхронные) и "управляемые временем" (синхронные) система управления КА как раз синхронная
Цитироватьрезко снизить количество ошибок могут и более традиционные методы
Ну я уже выше писал про "И". Для повышения надежности ПО БВС КА необходимо применять по возможности ВСЕ известные методы. Цена вопроса слишком велика :(
ЦитироватьТогда в чем выгода?
Выгода от чего? От "программирования без программистов"?
ЦитироватьСроки разработки систем, в которых использовался ПРОЛ2 не то, чтобы маленькие. То что они работают, это факт. Но далеко не факт, что их нельзя было разработать с применением современных технологий за более короткие сроки, и задействуя меньшие ресурсы
Факт - увы! - в том, что программа Буран закрыта много лет назад. :(
Можно ли было без ПРОЛ2 быстрее и проще сделать?
Думаю, нужно все-таки относиться к создателям его (неглупым весьма и весьма людям) с большим доверием. Вообще говоря, декларировалось, что им удалось повысить производительность труда при создании комплекса программ для Бурана в 10 раз!
ЦитироватьРешались чуть ли не на х286 процессоре :lol:
Вы полагаете, это смешно?
ЦитироватьМы НПО Маш предлагали решать их на R-3000 под VxWorks
Простите, можно вопрос? "Мы" - это кто?
Цитироватьеще один важный аспект методологии разработки - это насколько эффективно она позволяет использовать программистов не самого высокого уровня под управлением более опытных спецов
Вот! А я о чем!
Кстати, по поводу того что ООП - "гигантский скачок", не все согласны. В том числе - не последние люди в программировании.
ЦитироватьЦитироватьРешались чуть ли не на х286 процессоре :lol:
Вы полагаете, это смешно?
Через 20 лет - да, глядя на некоторые события сегодення! :lol: Там было еще -
А то! Но решались! Задачи на борту КА :!:
Например КА Океан-О http://ruscosmos.narod.ru/KA/okean/okean10.htm
ЦитироватьЦитироватьМы НПО Маш предлагали решать их на R-3000 под VxWorks
Простите, можно вопрос? "Мы" - это кто?
Группа специалистов в НИИ Аргон
ЦитироватьМногозадачность бывает разная. Философия Erlanga отчасти и вызывает у меня интерес тем, что модель асинхронных агентов гарантирует отсутствие разделяемого состояния и как следствие отсутствие дедлоков в классическом их понимании.
Это да, но тут появляется новая грабля - у каждого агента есть очередь сообщений. Которая даёт недетерминизм, т.к. является скрытым состоянием. Простейший пример - очередь разгребается медленнее чем в неё пихают сообщения.
ЦитироватьЦитироватьМногозадачность бывает разная. Философия Erlanga отчасти и вызывает у меня интерес тем, что модель асинхронных агентов гарантирует отсутствие разделяемого состояния и как следствие отсутствие дедлоков в классическом их понимании.
Это да, но тут появляется новая грабля - у каждого агента есть очередь сообщений. Которая даёт недетерминизм, т.к. является скрытым состоянием. Простейший пример - очередь разгребается медленнее чем в неё пихают сообщения.
Одна из краеугольных проблем реального времени :)
ЦитироватьПо аналогии могу сказать, что переполнения стека не может быть в принципе, т.к. все выделяемые на стеке данные имеют фиксированный размер.
Стэк кстати как элемент недетерминизма тоже можно исключить - явно запретив рекурсивный вызов процедур и выделить статически места под локальные переменные.
ЦитироватьНу я уже выше писал про "И". Для повышения надежности ПО БВС КА необходимо применять по возможности ВСЕ известные методы. Цена вопроса слишком велика :(
Количество использумых методов напрямую связано с количеством людей в наличии. Если ПО разрабатывают 3.5 человека, то почти никакие методы применены не будут, т.к. будут расцениваться как лишняя нагрузка.
ЦитироватьЦитироватьЦитироватьРешались чуть ли не на х286 процессоре :lol:
Вы полагаете, это смешно?
Через 20 лет - да, глядя на некоторые события сегодення! :lol: Там было еще - А то! Но решались! Задачи на борту КА :!:
Я имел в виду, что, возможно, нет смысла гнаться за огромным быстродействием управляющих ЦВМ КА.
И что ничего особо страшного в параметрах 286 нет.
ЦитироватьЦитироватьЦитироватьЦитироватьРешались чуть ли не на х286 процессоре :lol:
Вы полагаете, это смешно?
Через 20 лет - да, глядя на некоторые события сегодення! :lol: Там было еще - А то! Но решались! Задачи на борту КА :!:
Я имел в виду, что, возможно, нет смысла гнаться за огромным быстродействием управляющих ЦВМ КА.
И что ничего особо страшного в параметрах 286 нет.
Согласен. Но это было 20 лет тому назад... :D
ЦитироватьЗато количество выделяемых на стеке данных не фиксировано. Улавливаете?
Нет, нет. Мой намек был более тонким. Речь о том, что таким же образом глюк в коде может привести к переполнению массива, который распределен был статически, со всеми вытекающими последствиями.
ЦитироватьЭто не максимально корректно, а сваливание в защитный режим и перезагрузку от каждого бага, вместо того чтобы устранить сами баги еще на этапе разработки ПО
Тут должен пояснить, что я рассматриваю ситуацию, когда код вылизан идеально. И речь идет о каких-то совершенно неожиданных ситуациях. Никто не говорит, что ВМ хороша, т.к. писать можно как ляжет душа. Нет. Исходная посылка - код вылизан, отлажен, оттестирован. Но что-то происходит уже в полете и система дает серьезный сбой. Задача отработать такую ситуацию надежно и максимально корректно. В этом плане и рассматриваем.
Цитировать0 любое, и любое другое число тоже любое. Вот такая в С++ жеская типизация. Я ж говорю, языки "общего назначения" оставляют желать лучшего. А С++ и подавно.
Абсурд! Произвольное число (кроме 0, и то уже в С++0x есть nullptr) без явного приведения к указателю в С++ невозможно. Похоже, что про С++ вы знаете лишь по наслышке.
ЦитироватьСомнительно что это так, объяснять почему лень. И вообще я бы предпочел не домыслы, а ссылку на реальную информацию.
История появления бортовых ЭВМ ряда "АРГОН" (http://www.argon.ru/?q=node/20)
Еще советую книгу "БСУ КА" МОКБ "Марс".
ЦитироватьЦитироватьЦитироватьЦитироватьЦитироватьРешались чуть ли не на х286 процессоре :lol:
Вы полагаете, это смешно?
Через 20 лет - да, глядя на некоторые события сегодення! :lol: Там было еще - А то! Но решались! Задачи на борту КА :!:
Я имел в виду, что, возможно, нет смысла гнаться за огромным быстродействием управляющих ЦВМ КА.
И что ничего особо страшного в параметрах 286 нет.
Согласен. Но это было 20 лет тому назад... :D
Производительность вычислителей на необитамых КА всегда сдерживает объем решаемых задач. И причины понятны: стойкость к ВВФ и радиации, габариты, потребляемая мощность и отвод тепла.
ЦитироватьКак раз эти разработчики и основывают такие институты и документы стандартизации. Кому, как не им, понимать важность этого дела, чтобы избежать изобретения очередного велосипеда по заданию начальства.
Практика показывает, что не все так просто. Много ли тут найдется разработчиков, причастных к промышленным и международным стандартам и много ли стандартов удалось создать мужикам из НПОЛ?
ЦитироватьЦитироватьМногозадачность бывает разная. Философия Erlanga отчасти и вызывает у меня интерес тем, что модель асинхронных агентов гарантирует отсутствие разделяемого состояния и как следствие отсутствие дедлоков в классическом их понимании.
Это да, но тут появляется новая грабля - у каждого агента есть очередь сообщений. Которая даёт недетерминизм, т.к. является скрытым состоянием. Простейший пример - очередь разгребается медленнее чем в неё пихают сообщения.
Во первых, у любой системы управления есть допустимый диапазон скорости изменения управляемого объекта, за пределами которого не обеспечивается достаточная скорость реагирования.
Во вторых, конкретно в случае Erlang принципиально заложена возможность масштабировать скорость распараллеливанием обрабатывающих задач (то есть буквально можно сделать обработку очереди параллельно несколькими задачами), и по крайней мере на уровне языка возможность масштабирования бесконечная (конечно ограничивать будут доступное железо итп, но программу можно наращивать сколько угодно).
ЦитироватьТам этот набор трансформировался в сингулярность монеты. Цивилизованный человек существовать в этой сингулярности не сможет.
Не сможет. Но это уже совсем другая тема.
ЦитироватьЦитироватьЦитироватьЦитироватьЦитироватьЦитироватьРешались чуть ли не на х286 процессоре :lol:
Вы полагаете, это смешно?
Через 20 лет - да, глядя на некоторые события сегодення! :lol: Там было еще - А то! Но решались! Задачи на борту КА :!:
Я имел в виду, что, возможно, нет смысла гнаться за огромным быстродействием управляющих ЦВМ КА.
И что ничего особо страшного в параметрах 286 нет.
Согласен. Но это было 20 лет тому назад... :D
Производительность вычислителей на необитамых КА всегда сдерживает объем решаемых задач. И причины понятны: стойкость к ВВФ и радиации, габариты, потребляемая мощность и отвод тепла.
О СПО речь, о СПО :!: :lol:
И я про СПО. Десятки МГц частота процессора и несколько МБ памяти - вот и весь ресурс для СПО. Такие машины были на американских наземных комплексах 20 лет назад. Можно посмотреть в архивах какое там было СПО.
Новое (для нас) - хорошо забытое старое (для американцев).
ЦитироватьВы не правы. Как раз наоборот. В основе управления КА лежит циклограмма. Т.е. по классификации систем реального времени на "управляемые событиями" (асинхронные) и "управляемые временем" (синхронные) система управления КА как раз синхронная
Для РБ соглашусь, а для КА типа АМС скорее как раз имеем систему, управляемую событиями. Отдельные циклограммы режимов увязываются в работу последовательностью событий (ориентация на солнце выполнена, стабилизация остаточного вращения выполнена, ориентация по звездам выполнена и т.п.). Логично? Временные задержки здесь определяются начальными условиями, которые не известны. Как их положить на циклограмму? Нельзя.
ЦитироватьВыгода от чего? От "программирования без программистов"?
Имел в виду выгоду от перехода на ПРОЛ2, на методологию, которая все равно не позволяет исключить традиционные методы контроля качества. Вот если бы она позволила заметно сократить сроки разработки, но не из чего делать такие выводы, как я уже говорил.
ЦитироватьДумаю, нужно все-таки относиться к создателям его (неглупым весьма и весьма людям) с большим доверием. Вообще говоря, декларировалось, что им удалось повысить производительность труда при создании комплекса программ для Бурана в 10 раз!
Отношусь к ним с большим уважением! Даже наметил себе более детальное изучение основы их методологии, как только разгружусь от текучки.
ЦитироватьКстати, по поводу того что ООП - "гигантский скачок", не все согласны. В том числе - не последние люди в программировании.
Ну тут можно бесконечно спорить. Плюс еще субъективное понятие последнего места в программировании. ООП - это инструмент, и как любой инструмент им надо уметь пользоваться. Если не последнию люди в программировании не согласны с тем, что ООП позволяет резко повысить качество ПО по таким параметрам как модульность, сцепление, связность, повторное использование, сопровождаемость, то им не мешает подумать над этим как следует еще пару раз.
Для применения ООП приходится смотреть на задачи под другим углом. Очевидно, что нужен сдвиг восприятия задач и для разробтки на Erlang, т.к. он имеет мало общего и с процедурным, и с ООП подходами.
Есть и наш примеры уникальности: Аргон-15А:
10. Описание: машина одноадресная, параллельного действия. Архитектура и структура специализированные, оптимизированные для решения задач управления. Система команд включает команды вычислений синуса, косинуса и квадратного корня. Обмен информацией с внешними абонентами осуществляется каналами ввода-вывода.
Представление чисел - с фиксированной точкой.
Разрядность чисел - 16 разрядов (слово), 32 разряда (двойное слово), разрядность команд - 19 разрядов. Число команд - 71.
Время выполнения операций (мкс): сложения - 5, вычисления синуса, косинуса, квадратного корня - от 16 до 30.
Объем ОЗУ - 4 Кб, ДЗУ - 64 Кб, ДЗУ со сменой информации - 256 байт.
Система прерываний - 4 уровня. Число каналов ввода- вывода - 2.
Скорость обмена (кб/с): ввод - 200, вывод - 400
И посмотрите какой объем СПО решается А-15А на МИГ-31.
Но это смгла сделать только большая кооперация уникальных программистов за 5 лет. И летает МИГ-31 на боевое дежурство уже 25 лет
ЦитироватьЭто да, но тут появляется новая грабля - у каждого агента есть очередь сообщений. Которая даёт недетерминизм, т.к. является скрытым состоянием. Простейший пример - очередь разгребается медленнее чем в неё пихают сообщения.
Верно, но как я уже писал, такие проблемы видны невооруженным глазом. Потоки сообщений легко визуализируются на схемах и поддаются анализу намного легче, чем борьба за традиционные мониторы.
ЦитироватьДля РБ соглашусь, а для КА типа АМС
А Вы что, имеете отношение к упралению и РБ, и КА? 8)
Цитироватьскорее как раз имеем систему, управляемую событиями
Ну-ну 8)
ЦитироватьИмел в виду выгоду от перехода на ПРОЛ2, на методологию, которая все равно не позволяет исключить традиционные методы контроля качества. Вот если бы она позволила заметно сократить сроки разработки, но не из чего делать такие выводы, как я уже говорил
Как это не из чего? Прямо заявлялось, что главной целью было повышение производительности труда - и что задача была успешно решена.
ЦитироватьЕсли не последнию люди в программировании не согласны с тем, что ООП позволяет резко повысить качество ПО по таким параметрам как модульность, сцепление, связность, повторное использование, сопровождаемость, то им не мешает подумать над этим как следует еще пару раз
А еще лучше - Вам прочитать то, что они написали - подумав и не раз - на эту тему. И попробовать осмыслить.
ЦитироватьРазве эта проблема вообще актуальна в нормальной ОС РВ? Одна задача зациклилась (не говорю, что это должна быть штатная ситуация) - остальные нормально работают. Вытесняющая многозадачность с приоритезацией работает. В минимальном варианте параллельно работают дежурные задачи, которые позволяют провести перезагрузку.
Менеджер виртуальной памяти зациклился и? Синий экран Винды?
ЗЫ. А вообще - таймер горячей собаки ;) великолепно решает эту проблему...
ЦитироватьМежотраслевая стандартизация уж больно далеко за рамками досягаемости программистов. И слишком уж это запредельный аргумент в пользу микроконтроллеров.
Гибкость и эффективность на местах все-таки сподручней будут, чем надежды на никак от тебя не зависящие стандарты.
Порочный подход. Стандарты не должны мешать разработчику, а обязаны помогать. Для этого в узких областях пишут стандарты сами разработчики. Задача стандарта - не гадать что там с той стороны по интерфейсу приходит...
ЦитироватьА Вы что, имеете отношение к упралению и РБ, и КА? 8)
Не имею, поэтому теоретизирую на основе доступной информации. Циклограмма по определению - точное расписание комманд. От этого и плясал.
ЦитироватьКак это не из чего? Прямо заявлялось, что главной целью было повышение производительности труда - и что задача была успешно решена.
Хорошо, что заявлялось. Но не надо забывать как давно это было и относительно какого уровня (доисторического) производительности была успешна решена задача!
ЦитироватьА еще лучше - Вам прочитать то, что они написали - подумав и не раз - на эту тему. И попробовать осмыслить.
Подкиньте указатель на эти монументальные труды - с удовольствием ознакомлюсь.
ЦитироватьМенеджер виртуальной памяти зациклился и? Синий экран Винды?
Что такое система с миллиардами возможных вариантов состояний и "менеджер виртуальной памяти"? Ни в какое сравнение. Вылизать последний реально и не сложно.
ЦитироватьЗЫ. А вообще - таймер горячей собаки ;) великолепно решает эту проблему...
На каждый таймер собаки найдется цикл, который будет его сбрасывать :wink:
ЦитироватьНа каждый таймер собаки найдется цикл, который будет его сбрасывать :wink:
Поэтому по всей видимости нужна иерархическая система контроля.
Уж извините, но сами знаете где :D и на эту проблему обратили внимание и сделали механизм задач-супервизоров: есть задачи-работники, которые выполняют работу, и есть задачи-супервизоры, которые выполняют какую-то логику обработки сбоев задач-работников.
Как тут уже отмечалось, принципиально отвергается хранение внутри кода состояний (для хранения состояний есть СУБД), и также важное правило что при всех не заложенных в ТЗ ситуациях просто идем на исключение, а дальше обрабатывает соответствующий супервизор (система иерархическая, то есть супервизор сам может быть воркером для другого, вышестоящего супервизора). Плюс в той самой библиотеке OTP заложены два момента:
1. заложено понимание и обработка того, что какие-то воркеры должны запускаться в строго определенной последовательности.
2. сама библиотека имеет встроенный механизм подсчета частоты исключений, что при слишком большом количестве исключений в единицу времени отключается механизм автоматического перезапуска и переходит на обработку особой ситуации. Соответственно, если обработчик на этом уровне не предусмотрен то идем по исключению на уровень выше и так хоть до самого верхнего уровня.
PS Насчет Erlang и ООП: одна из первых реализаций ООП в Smalltalk как раз была реализована через передачу сообщений, без разделяемой памяти.
ЦитироватьЦитироватьЗато количество выделяемых на стеке данных не фиксировано. Улавливаете?
Нет, нет. Мой намек был более тонким. Речь о том, что таким же образом глюк в коде может привести к переполнению массива, который распределен был статически, со всеми вытекающими последствиями.
Выход за границы массива совершенно отдельная проблема. Впрочем, разумно устроенный язык и компилятор мог бы отлавливать такие ситуации еще на этапе компиляции.
ЦитироватьЦитироватьЭто не максимально корректно, а сваливание в защитный режим и перезагрузку от каждого бага, вместо того чтобы устранить сами баги еще на этапе разработки ПО
Тут должен пояснить, что я рассматриваю ситуацию, когда код вылизан идеально. И речь идет о каких-то совершенно неожиданных ситуациях. Никто не говорит, что ВМ хороша, т.к. писать можно как ляжет душа. Нет. Исходная посылка - код вылизан, отлажен, оттестирован. Но что-то происходит уже в полете и система дает серьезный сбой. Задача отработать такую ситуацию надежно и максимально корректно. В этом плане и рассматриваем.
Вот чтоб код был по возможности безошибочным и нужен правильно устроенный язык и компилятор со всеми возможными проверками. А не писать как попало, оставляя кучу багов в надежде что в случае чего аппарат свалится в защитный режим и не умрет окончательно.
ЦитироватьЦитировать0 любое, и любое другое число тоже любое. Вот такая в С++ жеская типизация. Я ж говорю, языки "общего назначения" оставляют желать лучшего. А С++ и подавно.
Абсурд! Произвольное число (кроме 0, и то уже в С++0x есть nullptr) без явного приведения к указателю в С++ невозможно. Похоже, что про С++ вы знаете лишь по наслышке.
Возможно. Например, вы можете прибавить к указателю любое число, без всякого явного приведения. Похоже про С++ по наслышке знаете как раз вы :)
ЦитироватьЦитироватьСомнительно что это так, объяснять почему лень. И вообще я бы предпочел не домыслы, а ссылку на реальную информацию.
История появления бортовых ЭВМ ряда "АРГОН" (http://www.argon.ru/?q=node/20)
Спасибо за ссылку, тем более что она опровергает то что вы ранее писали :wink: Никакой троированной логики на кристалле там нет, есть 3 независимых канала с одинарной логикой. Но вообще интересно. Судя по тому что там написано, на старых моделях применялось мажоритирование на уровне выдачи управляющих команд в окружающий мир и промежуточная синхронизация по желанию ПО. На последних моделях уже мажоритирование на уровне системной шины.
ЦитироватьЕще советую книгу "БСУ КА" МОКБ "Марс".
С удовольствием бы почитал, если подскажете, где найти ее в интернете. Бумажную версию я вряд ли достану.
ЦитироватьВыход за границы массива совершенно отдельная проблема. Впрочем, разумно устроенный язык и компилятор мог бы отлавливать такие ситуации еще на этапе компиляции.
Культ компилятора - это хорошо. Но он не ясновидец и понятия не имеет, какие значения могут принимать переменные в процессе работы того или иного алгоритма. Не может он отлавливать такие ситуации. Уж скорее он спрогнозирует переполнение стека (при условии, что нет рекурсии), т.к. размеры передаваемых данных и вложенность вызовов известны на этапе компиляции.
ЦитироватьВот чтоб код был по возможности безошибочным и нужен правильно устроенный язык и компилятор со всеми возможными проверками. А не писать как попало, оставляя кучу багов в надежде что в случае чего аппарат свалится в защитный режим и не умрет окончательно.
Да хватит уже мечтать :) Компилятор не может анализировать семантику. Никакие проверки в нем не спасут вас от ошибок. Не в компиляторе сила, а в грамотной методологии разработки, которая охватывает все ее этапы, последовательно и неумолимо не оставляя места ошибкам в конечном продукте.
ЦитироватьВозможно. Например, вы можете прибавить к указателю любое число, без всякого явного приведения. Похоже про С++ по наслышке знаете как раз вы.
Ну уж нет, не съезжайте. Этот разговор был в контексте преобразования типов. А индексация указателя и преобразование произвольного числа в указатель - это две разные вещи.
ЦитироватьСпасибо за ссылку, тем более что она опровергает то что вы ранее писали Wink Никакой троированной логики на кристалле там нет, есть 3 независимых канала с одинарной логикой. Но вообще интересно.
Пожалуйста. Ну я дал первое, что попалось по этой тематике. Троирование на низком уровне реально применялось. В частности такое решение использовалось в ЦВМ БИУС НК, но это военная аппаратура с другими критерями (те, которые я изучал и про кристаллы родом не слышали :) ). Я по доброте душевной экстраполировал и на космическую аппаратуру. Но видимо в Аргоне решили, что троирования по шине будет достаточно. Судя по результатам, не ошиблись.
ЦитироватьС удовольствием бы почитал, если подскажете, где найти ее в интернете. Бумажную версию я вряд ли достану.
Попробуйте здесь (http://epizodsspace.no-ip.org/bibl/bortovye/01-2010pdf.html).
Сорок лет прошло, а темы не меняются. :roll:
ЦитироватьЦитироватьВыход за границы массива совершенно отдельная проблема. Впрочем, разумно устроенный язык и компилятор мог бы отлавливать такие ситуации еще на этапе компиляции.
Культ компилятора - это хорошо. Но он не ясновидец и понятия не имеет, какие значения могут принимать переменные в процессе работы того или иного алгоритма.
А должен иметь понятие. Естественно, не при помощи ясновидения, а потому что программист сообщил. При наличии соотвествующего языка. К сожалению, существующие широкораспространенные языки этого не позволяют. В них можно только сообщить компилятору, что переменная будет целого типа, а в каких пределах будет ее значение - нет.
ЦитироватьУж скорее он спрогнозирует переполнение стека (при условии, что нет рекурсии), т.к. размеры передаваемых данных и вложенность вызовов известны на этапе компиляции.
И это тоже. Отсутсвие рекурсии вполне проверяется при компиляции. На таких условиях можно даже стек разрешить :)
ЦитироватьЦитироватьВот чтоб код был по возможности безошибочным и нужен правильно устроенный язык и компилятор со всеми возможными проверками. А не писать как попало, оставляя кучу багов в надежде что в случае чего аппарат свалится в защитный режим и не умрет окончательно.
Да хватит уже мечтать :) Компилятор не может анализировать семантику.
Может. Абсолютно все он не проанализирует, панацеи не сущствует, но значительно сократить количество ошибок, ликвидировать целые классы оных он вполне может.
ЦитироватьЦитироватьВозможно. Например, вы можете прибавить к указателю любое число, без всякого явного приведения. Похоже про С++ по наслышке знаете как раз вы.
Ну уж нет, не съезжайте. Этот разговор был в контексте преобразования типов. А индексация указателя и преобразование произвольного числа в указатель - это две разные вещи.
Вы сами выдумываете некие утверждения (приписывая их мне почему-то) и сами же опровергаете. Извините, ваши утверждения я отстаивать не буду :)
ЦитироватьЦитироватьС удовольствием бы почитал, если подскажете, где найти ее в интернете. Бумажную версию я вряд ли достану.
Попробуйте здесь (http://epizodsspace.no-ip.org/bibl/bortovye/01-2010pdf.html).
Спасибо.
Цитироватьне надо забывать как давно это было и относительно какого уровня (доисторического) производительности была успешна решена задача!
Производительность - имелась в виду производительность труда программистов. Она за эти годы чудесным образом не возрастала.
ЦитироватьПопробуйте здесь (http://epizodsspace.no-ip.org/bibl/bortovye/01-2010pdf.html).
bs, спасибо большое!
Как жаль, что они ничего практически про ПО не написали в этой ценнейшей книге. :cry:
ЦитироватьПодкиньте указатель на эти монументальные труды - с удовольствием ознакомлюсь
К сожалению, пока в электронном виде "монументальных трудов" не нашел.
Но, может, эта ссылка поможет начать?
http://blogerator.ru/page/oop_why-objects-have-failed
В частности, приводится мнение вроде не последних людей в мире программирования - Ричарда Столлмэна, Александра Степанова, Никлауса Вирта.
В бумажном виде читал мнение Святослава Лаврова - человека, кстати, одновременно "своего" и для космической отрасли, и для программирования.
Вот небезынтересное исследование:
http://www.csm.ornl.gov/~v8q/Homepage/Papers%20Old/spetep-%20printable.pdf
Для интересующихся теорией и практикой
http://sunnyday.mit.edu/ :twisted:
ЦитироватьЦиклограмма по определению - точное расписание комманд. От этого и плясал
На борту АМС все равно выполняются динамичные операции - например, включение и выключение двигателя должно осуществиться в строго заданные моменты времени. И ни о каком "мягком" реальном времени или асинхронном режиме говорить не приходится. Можно улететь совсем не куда предполагали.
ЦитироватьЦитироватьЦиклограмма по определению - точное расписание комманд. От этого и плясал
На борту АМС все равно выполняются динамичные операции - например, включение и выключение двигателя должно осуществиться в строго заданные моменты времени. И ни о каком "мягком" реальном времени или асинхронном режиме говорить не приходится. Можно улететь совсем не куда предполагали.
Смотря для каких режимов - например время выдачи ВКИ и время выдачи команды ДМТ в ПСО и ИНО для ФГ имеют наверно разный приоритет и важность.
ЦитироватьЦитироватьМенеджер виртуальной памяти зациклился и? Синий экран Винды?
Что такое система с миллиардами возможных вариантов состояний и "менеджер виртуальной памяти"? Ни в какое сравнение. Вылизать последний реально и не сложно.
Дык задача на каждое состояние как правило проще менеджера виртуальной памяти. Кроме того, требования к надежности менеджера на несколько порядков выше чем к надежности каждой задачи.
ЦитироватьЦитироватьЗЫ. А вообще - таймер горячей собаки ;) великолепно решает эту проблему...
На каждый таймер собаки найдется цикл, который будет его сбрасывать :wink:
Не каждую собаку так можно обмануть. Современных собак можно настроить на сброс в течение строго определенного интервала времени...
ЦитироватьЦитироватьЦиклограмма по определению - точное расписание комманд. От этого и плясал
На борту АМС все равно выполняются динамичные операции - например, включение и выключение двигателя должно осуществиться в строго заданные моменты времени. И ни о каком "мягком" реальном времени или асинхронном режиме говорить не приходится. Можно улететь совсем не куда предполагали.
Блок управления двигателем должен иметь свой контроллер который имеет собственные часы реального времени периодически подстраиваемые с бортовыми часами. Борт просто должен указать блоку управления двигателем в какой момент времени его запустить и через сколько остановить. Отдельный контроллер с детской памятью (меньше 4кБ) и смешной тактовой (8МГц) сможет отработать циклограмму с микросекундной точностью.
:!:
ЗЫ. Кстати, при этом борт может закладывать циклограмму блоку управления двигателем абсолютно асинхронно.
ЦитироватьПроизводительность - имелась в виду производительность труда программистов. Она за эти годы чудесным образом не возрастала.
Ну тут я склонен не согласиться, ибо учитываю не только космическую отрасль.
Цитироватьbs, спасибо большое!
Как жаль, что они ничего практически про ПО не написали в этой ценнейшей книге.
Не за что. Увы про ПО там действительно мало, и это о чем-то говорит.
ЦитироватьК сожалению, пока в электронном виде "монументальных трудов" не нашел.
Но, может, эта ссылка поможет начать?
Спасибо! На монументальные труды можно сослаться и в бумажном варианте.
ЦитироватьНа борту АМС все равно выполняются динамичные операции - например, включение и выключение двигателя должно осуществиться в строго заданные моменты времени. И ни о каком "мягком" реальном времени или асинхронном режиме говорить не приходится. Можно улететь совсем не куда предполагали.
А вот почему, скажем, то же включение двигателя должно выполняться строго по времени? Не от недостатка ли сложившегося подхода? Мне как человеку, свободному от устоявшихся взглядов в этой области, гораздо логичнее было бы думать, что включение двигателя должно выполняться по информации с датчиков ориентации и положения в пространстве. Ведь сворачивая всю эту информацию в единственный параметр "время", мы вносим в него еще и погрешность расчетов.
ЦитироватьСмотря для каких режимов - например время выдачи ВКИ и время выдачи команды ДМТ в ПСО и ИНО для ФГ имеют наверно разный приоритет и важность.
И что? Система должна быть настроена на поддержку самого "жесткого" из возможных режимов.
ЦитироватьЦитироватьПроизводительность - имелась в виду производительность труда программистов. Она за эти годы чудесным образом не возрастала.
Ну тут я склонен не согласиться, ибо учитываю не только космическую отрасль
Не может быть! Вы нашли "серебряную пулю"! Немедленно поделитесь!
Цитироватьпочему, скажем, то же включение двигателя должно выполняться строго по времени?
Просто это определяется путем баллистических расчетов - сколько должен отработать двигатель. Летит оно...
ЦитироватьА вот почему, скажем, то же включение двигателя должно выполняться строго по времени? Не от недостатка ли сложившегося подхода? Мне как человеку, свободному от устоявшихся взглядов в этой области, гораздо логичнее было бы думать, что включение двигателя должно выполняться по информации с датчиков ориентации и положения в пространстве. Ведь сворачивая всю эту информацию в единственный параметр "время", мы вносим в него еще и погрешность расчетов.
Потому, что время это наиболее точно измеряемая на борту величина. Положение в пространстве на орбите для аппарата двигающегося со скоростью 8 км/с точно вычислить не так просто как кажется... Верстовых столбов там нет... ;)
ЦитироватьПотому, что время это наиболее точно измеряемая на борту величина. Положение в пространстве на орбите для аппарата двигающегося со скоростью 8 км/с точно вычислить не так просто как кажется... Верстовых столбов там нет... ;)
ИМХО, тут не надо путать...
Время включения - рассчитывается заранее и вполне может быть рассчитано на основе показаний датчиков. Коррекция как правило проводится определённой точке орбиты (например в апогее) - и надо просто вычислить когда она. И соотвествующе установить таймер включения.
А вот время работы - вполне можно и слегка менять прямо в процессе, учитывая показания акселерометров.
Поддерживаю TAU: Не может быть! Вы нашли "серебряную пулю"! Немедленно поделитесь!
Еще раз советую Всем прочитать bruks_frederik_mificheskii_chelovekomesyac_ili_kak_sozdayutsya_programmnye_sistemy.
Это должна быть настольная книга разработчиков больших систем. Актуальность книги - история разработки программного обеспечения фирмой IBM. Уже больше 25-лет ее перечитываю перед началом сложных проектов или в запутанных ситуациях при разработке.
И еще раз по поводу Циклограмм
Проект 1992 года - несостоявшийся Алмаз-2
Класс задач контроля и управления бортовой аппаратурой КА:
1.1. Контроль и управление аппаратурой БРТК-АС,
1.2. Контроль и управление аппаратурой БРТК-МС,
1.3. Контроль и управление аппаратурой БРТК-МК,
1.4. Контроль и управление аппаратурой БК,
1.5. Контроль и управление аппаратурой БКЖ (служебные системы),
1.6. Контроль и управление комплексами КА и формирование и выдача на НКУ информации телесигнализации КА,
1.7. Прием от НКУ и исполнение КПИ,
1.8. Управление коррекцией положения КА,
1.9. Ведение бортовой шкалы времени (БШВ) и привязка БШВ к БШВ соседних КА и СЕВ НКУ.
Класс задач управления функционированием КА, как узла сети связи системы "МАКСИМУМ":
2.1. Управление доступом абонентов в служебный канал,
2.2. Контроль качества каналов связи,
2.3. Поддержание соединений абонентов с КА (переключение между подзонами),
2.4. Управление функционированием связной аппаратуры БРТК-АС,
2.5. Контроль качества каналов связи, поддержание соединений
абонентов и управление функционированием связной аппаратуры БРТК-МС,
2.6. Управление доступом ШС в радиоканал,
2.7. Контроль качества каналов связи,
2.8. Поддержание соединений с ШС,
2.9. Обеспечение связи с НКУ по радиоканалу БРТК-МК,
2.10. Обеспечение связи с РЦО по радиоканалу БРТК-МК,
2.11. Функциональная задача управления коммутацией в БК,
2.12. Установление соединений абонентов сети,
2.13. Поддержание соединений абонентов сети,
2.14. Обеспечение функционирования КА в качестве абонента служебной сети связи.
Класс задач балистико-навигационного обеспечения:
3.1. Определение местоположения АС,
3.2. Определение дальности до соседних КА,
3.3. Определение радиальных скоростей относительно соседних КА,
3.4. Определение дальности до ШС-реперов,
3.5. Определение радиальных скоростей относительно ШС-реперов,
3.6. Определение текущей ориентации КА,
3.7. Определение текущего положения КА,
3.8. Расчет параметров движения КА,
3.9. Прогнозирование сеансов ВТИ по ШС-реперам, интервалов отсутствия связи в радиоканалах БРТК-МС и интервалов разгрузки маховиков СОС,
3.10. Расчет целеуказаний для антенн БРТК-МС,
3.11. Формирование эфемеридной информации для АС.
Распределение такого объема задач по циклограмме наверно плохо поддается автоматизации.
И весь этот комплекс задач предполагалось решать на аппаратуре, аналогичной сегодняшнему БВК ФГ.
ЦитироватьЦитироватьЦитироватьЦиклограмма по определению - точное расписание комманд. От этого и плясал
На борту АМС все равно выполняются динамичные операции - например, включение и выключение двигателя должно осуществиться в строго заданные моменты времени. И ни о каком "мягком" реальном времени или асинхронном режиме говорить не приходится. Можно улететь совсем не куда предполагали.
Блок управления двигателем должен иметь свой контроллер который имеет собственные часы реального времени периодически подстраиваемые с бортовыми часами. Борт просто должен указать блоку управления двигателем в какой момент времени его запустить и через сколько остановить. Отдельный контроллер с детской памятью (меньше 4кБ) и смешной тактовой (8МГц) сможет отработать циклограмму с микросекундной точностью.
:!:
Было уже такое в истории больших компьютеров.
Собственно, PIC, который потом стал выпускать Микрочип, вначале был универсальным сопроцессором ввода/вывода в мейнфрейме.
Правда цель была чуть другая - разгрузить центральный процессор от выполнения задач управления периферией, но фактически это направление постепенно привело к интеллектуальным периферийным устройствам, таким как например контроллер жесткого диска, который по сути работает в риалтайме по жесткой циклограмме, но с ЦП общается абстракциями - командами примитивизированными почти до уровня ОЗУ ("считать блок информации по адресу"; "записать блок информации по адресу").
Только одно отличие, что в гражданских компьютерах в результате развития периферийных сопроцессоров вместо УНИВЕРСАЛЬНЫХ периферийных процессоров появилось множество СПЕЦИАЛИЗИРОВАННЫХ периферийных процессоров, жестко заточенных на какие-то задачи и без возможности перепрограммирования.
Кстати, было и несколько попыток "второго пришествия" универсальных периферийных процессоров в персоналки, но не прижилось как раз ввиду необходимости для них внедрять дополнительные технологии разработки ПО (нанимать отдельных людей, платить за обучение итп), при отсутствии коммерческой выгоды от этого, а вот на суперкомпьютерах эта тема вполне жива.
И еще кстати - на микрокомпьютерах сразу пошли другим путем - там наоборот всё что могли исполняли на центральном процессоре, потому что периферийные процессоры были очень дорогие.
- Были удивительные решения, вплоть до использования ЦП для риалтаймового создания видеосигнала, у которого довольно жесткие требования к точности циклограммы :D
А уже потом, со временем, когда плата стала дороже чем БИС, стали постепенно внедрять специализированные контроллеры - вначале формирование видео, потом часы и дисковод, потом аудио и жесткий диск, а сейчас уже и клавиатуры с макросами появились.
ЦитироватьЗЫ. Кстати, при этом борт может закладывать циклограмму блоку управления двигателем абсолютно асинхронно.
Точно!
Artemkad писал(а):
Блок управления двигателем должен иметь свой контроллер который имеет собственные часы реального времени периодически подстраиваемые с бортовыми часами. Борт просто должен указать блоку управления двигателем в какой момент времени его запустить и через сколько остановить. Отдельный контроллер с детской памятью (меньше 4кБ) и смешной тактовой (8МГц) сможет отработать циклограмму с микросекундной точностью.
Этот блок придется тоже резервировать, размещать, тратить на него энергию, тратить ресурсы БВК на снхронизацию, и т.д. и т.п.
ЦитироватьЭтот блок придется тоже резервировать, размещать, тратить на него энергию, тратить ресурсы БВК на снхронизацию, и т.д. и т.п.
Можно действительно встроить в БВК универсальный периферийный контроллер.
Вообще хорошо-бы посмотреть циклограммы типичных задач решаемых БВК - у меня есть подозрение, что типичные задачи управления АМС можно решать очень примитивными конечными автоматами, а может быть такие автоматы даже уже существуют в виде готовых чипов и вообще ничего не нужно изобретать, а просто взять готовое и применить.
ЦитироватьЦитироватьСмотря для каких режимов - например время выдачи ВКИ и время выдачи команды ДМТ в ПСО и ИНО для ФГ имеют наверно разный приоритет и важность.
И что? Система должна быть настроена на поддержку самого "жесткого" из возможных режимов.
Не обязательно, но "жесткий", например, считать в режиме "двойной точности"
ЦитироватьНе может быть! Вы нашли "серебряную пулю"! Немедленно поделитесь!
Так, спокойствие! Ничего я не нашел :)
Я просто окинул взором прогресс в области разработки ПО за последние 20 лет, не говоря уже о том, что точка отсчета в предыдущем моем сообщении уходила намного глубже в колодец времени.
Так вот, за последние 20 лет у программистов появился такой арсенал аппаратно-программных средств, который раньше им просто не снилися. Сейчас удобнейшие системы контроля конфигураций и версий, удаленная отладка, компиляция миллионов строк кода за доли секунды, онлайн докуменация, визуализация диаграмм, системы коллаборации и прочие технологические достижения считаются обычным делом в жизни разработчика. А что было тогда? И такой разрыв никак не отразился на производительности? Не может быть!
Заметьте, что я упомянул лишь технологические новшества. А ведь соотвественно адаптировались и методы разработки, да и новых появилось не мало.
Так что "серебряная пуля" не при чем.
ЦитироватьПросто это определяется путем баллистических расчетов - сколько должен отработать двигатель. Летит оно...
Это уже к вопросу о выключении двигателя. Но и здесь этот момент удобно было бы представить как асинхронное событие таймера :wink:
ЦитироватьЦитироватьЦитироватьЦиклограмма по определению - точное расписание комманд. От этого и плясал
На борту АМС все равно выполняются динамичные операции - например, включение и выключение двигателя должно осуществиться в строго заданные моменты времени. И ни о каком "мягком" реальном времени или асинхронном режиме говорить не приходится. Можно улететь совсем не куда предполагали.
Блок управления двигателем должен иметь свой контроллер который имеет собственные часы реального времени периодически подстраиваемые с бортовыми часами. Борт просто должен указать блоку управления двигателем в какой момент времени его запустить и через сколько остановить. Отдельный контроллер с детской памятью (меньше 4кБ) и смешной тактовой (8МГц) сможет отработать циклограмму с микросекундной точностью.
:!:
ЗЫ. Кстати, при этом борт может закладывать циклограмму блоку управления двигателем абсолютно асинхронно.
А если выключение двигателя должно производится еще и по достигнутой дельта-V с акселерометров? (это точнее, поскольку тяга двигателя и масса аппарата скорее всего известны с меньшей точностью). При этом нужно следить за ориентацией и аварийно отключить двигатель, если правильная ориентация потеряна. Во многих случаях для поддрежания ориентации требуется рулить самим маршевым двигателем. Возможно, нужно следить за уровнем топлива в баках, как для равномерной выработки (и регулировать при этом соотношение компонентов) так и общее количество на предмет предельного расхода на данную операцию и минимальных допустимых остатков после. Вобщем либо ЦП все таки работает в рилтайме либо получается дубль ЦП со всеми связями со зведными датчиками, акселерометрами, гироскопами, датчиками уровня и расхода топлива etc. А зачем?
ЦитироватьА если выключение двигателя должно производится еще и по достигнутой дельта-V с акселерометров? (это точнее, поскольку тяга двигателя и масса аппарата скорее всего известны с меньшей точностью). При этом нужно следить за ориентацией и аварийно отключить двигатель, если правильная ориентация потеряна. Во многих случаях для поддрежания ориентации требуется рулить самим маршевым двигателем. Возможно, нужно следить за уровнем топлива в баках, как для равномерной выработки (и регулировать при этом соотношение компонентов) так и общее количество на предмет предельного расхода на данную операцию и минимальных допустимых остатков после. Вобщем либо ЦП все таки работает в рилтайме либо получается дубль ЦП со всеми связями со зведными датчиками, акселерометрами, гироскопами, датчиками уровня и расхода топлива etc. А зачем?
Никаких проблем. Контроллер управления двигателя циклично выдает широтно-модулированные стробы, между которыми вполне в состоянии слушать команды БВК через тот же UART. Контроллер двигателя после завершения выдачи управляющих импульсов на железо выдает сигнал готовности к приему данных. БВК получил этот сигнал выдает очередную команду контроллеру двигателя, которую тот исполняет или немедленно, или во время следующего периода. Длина периода может быть достаточно малой - от миллисекунд до десятков миллисекунд.
ЦитироватьЦитироватьА если выключение двигателя должно производится еще и по достигнутой дельта-V с акселерометров? (это точнее, поскольку тяга двигателя и масса аппарата скорее всего известны с меньшей точностью). При этом нужно следить за ориентацией и аварийно отключить двигатель, если правильная ориентация потеряна. Во многих случаях для поддрежания ориентации требуется рулить самим маршевым двигателем. Возможно, нужно следить за уровнем топлива в баках, как для равномерной выработки (и регулировать при этом соотношение компонентов) так и общее количество на предмет предельного расхода на данную операцию и минимальных допустимых остатков после. Вобщем либо ЦП все таки работает в рилтайме либо получается дубль ЦП со всеми связями со зведными датчиками, акселерометрами, гироскопами, датчиками уровня и расхода топлива etc. А зачем?
Никаких проблем. Контроллер управления двигателя циклично выдает широтно-модулированные стробы, между которыми вполне в состоянии слушать команды БВК через тот же UART. Контроллер двигателя после завершения выдачи управляющих импульсов на железо выдает сигнал готовности к приему данных. БВК получил этот сигнал выдает очередную команду контроллеру двигателя, которую тот исполняет или немедленно, или во время следующего периода. Длина периода может быть достаточно малой - от миллисекунд до десятков миллисекунд.
Это ничего не меняет. В вашей версии БВК также обязан работать в рилтайме.
ЦитироватьЦитироватьЦитироватьА если выключение двигателя должно производится еще и по достигнутой дельта-V с акселерометров? (это точнее, поскольку тяга двигателя и масса аппарата скорее всего известны с меньшей точностью). При этом нужно следить за ориентацией и аварийно отключить двигатель, если правильная ориентация потеряна. Во многих случаях для поддрежания ориентации требуется рулить самим маршевым двигателем. Возможно, нужно следить за уровнем топлива в баках, как для равномерной выработки (и регулировать при этом соотношение компонентов) так и общее количество на предмет предельного расхода на данную операцию и минимальных допустимых остатков после. Вобщем либо ЦП все таки работает в рилтайме либо получается дубль ЦП со всеми связями со зведными датчиками, акселерометрами, гироскопами, датчиками уровня и расхода топлива etc. А зачем?
Никаких проблем. Контроллер управления двигателя циклично выдает широтно-модулированные стробы, между которыми вполне в состоянии слушать команды БВК через тот же UART. Контроллер двигателя после завершения выдачи управляющих импульсов на железо выдает сигнал готовности к приему данных. БВК получил этот сигнал выдает очередную команду контроллеру двигателя, которую тот исполняет или немедленно, или во время следующего периода. Длина периода может быть достаточно малой - от миллисекунд до десятков миллисекунд.
Это ничего не меняет. В вашей версии БВК также обязан работать в рилтайме.
Да на здоровье. Выдал команды в буфер контроллера UART и пошел себе дальше. А уже контроллер UART отвечает за их передачу. Латентность безусловно будет, но если, напримет, 10 миллисекунд нас устроит - пусть себе будет.
ЦитироватьА если выключение двигателя должно производится еще и по достигнутой дельта-V с акселерометров? (это точнее, поскольку тяга двигателя и масса аппарата скорее всего известны с меньшей точностью). При этом нужно следить за ориентацией и аварийно отключить двигатель, если правильная ориентация потеряна. Во многих случаях для поддрежания ориентации требуется рулить самим маршевым двигателем. Возможно, нужно следить за уровнем топлива в баках, как для равномерной выработки (и регулировать при этом соотношение компонентов) так и общее количество на предмет предельного расхода на данную операцию и минимальных допустимых остатков после. Вобщем либо ЦП все таки работает в рилтайме либо получается дубль ЦП со всеми связями со зведными датчиками, акселерометрами, гироскопами, датчиками уровня и расхода топлива etc. А зачем?
А вы не могли-бы указать примерные требования по задержкам по каждой из приведенных управляемых систем?
- Сколько допустимая задержка выключения по дельта-V, сколько по аварийной ориентации, сколько руления маршевым двигателем, сколько за уровнем топлива?
И второй вопрос: насколько там сложные вычисления?
Да, и к вопросу про сборщик мусора: вообще у него очевидно есть производительность обеспечиваемая при его работе как фоновой задачи без потерь скорости реакции системы, а у конкретного счетного/управляющего алгоритма очевидно есть скорость выделения/освобождения памяти.
Причем для алгоритма реализованного на функциональном языке для конкретного набора данных скорость выделения/освобождения памяти очень предсказуема (напомню, что у чисто функциональных языков вообще нет никаких сторонних эффектов - всё происходящее определяют только входные параметры), следовательно при загрузке меньше определенного и достаточно хорошо предсказуемого предела система на базе функционального языка с риалтаймовым сборщиком мусора будет надежно реагировать риалтаймово.
PS Я понимаю что тут многие не всё могут сказать. Поэтому я попробую сообразить примеры сам, но всё-же подсказки не помешают.
Цитировать(напомню, что у чисто функциональных языков вообще нет никаких сторонних эффектов - всё происходящее определяют только входные параметры)
Когда ваша функциональная программа управляет сфероконем в вакууме - да. А в реальности есть шина и другие общие ресурсы. В этот момент заканчивается красивая функциональная модешь и начинаются некрасивые сторонние эффекты :D
ЦитироватьКогда ваша функциональная программа управляет сфероконем в вакууме - да. А в реальности есть шина и другие общие ресурсы. В этот момент заканчивается красивая функциональная модешь и начинаются некрасивые сторонние эффекты :D
Нет, уж очень разного порядка величины на уровне работы ПО и шины. Думаю, при рассмотрении первых, последними можно пернебречь. Вот задержки обработки команд аппаратной частью уже вполне существенны. Но здесь, по-моему, и интересен хороший асинхронный подход для борьбы с ними.
ЦитироватьЦитироватьА если выключение двигателя должно производится еще и по достигнутой дельта-V с акселерометров? (это точнее, поскольку тяга двигателя и масса аппарата скорее всего известны с меньшей точностью). При этом нужно следить за ориентацией и аварийно отключить двигатель, если правильная ориентация потеряна. Во многих случаях для поддрежания ориентации требуется рулить самим маршевым двигателем. Возможно, нужно следить за уровнем топлива в баках, как для равномерной выработки (и регулировать при этом соотношение компонентов) так и общее количество на предмет предельного расхода на данную операцию и минимальных допустимых остатков после. Вобщем либо ЦП все таки работает в рилтайме либо получается дубль ЦП со всеми связями со зведными датчиками, акселерометрами, гироскопами, датчиками уровня и расхода топлива etc. А зачем?
А вы не могли-бы указать примерные требования по задержкам по каждой из приведенных управляемых систем?
- Сколько допустимая задержка выключения по дельта-V, сколько по аварийной ориентации, сколько руления маршевым двигателем, сколько за уровнем топлива?
И второй вопрос: насколько там сложные вычисления?
Да, и к вопросу про сборщик мусора: вообще у него очевидно есть производительность обеспечиваемая при его работе как фоновой задачи без потерь скорости реакции системы, а у конкретного счетного/управляющего алгоритма очевидно есть скорость выделения/освобождения памяти.
Причем для алгоритма реализованного на функциональном языке для конкретного набора данных скорость выделения/освобождения памяти очень предсказуема (напомню, что у чисто функциональных языков вообще нет никаких сторонних эффектов - всё происходящее определяют только входные параметры), следовательно при загрузке меньше определенного и достаточно хорошо предсказуемого предела система на базе функционального языка с риалтаймовым сборщиком мусора будет надежно реагировать риалтаймово.
PS Я понимаю что тут многие не всё могут сказать. Поэтому я попробую сообразить примеры сам, но всё-же подсказки не помешают.
В системе ориентации, по современным масштабам вычислительной техники, ни насколько не сложные вычисления. Машина в 400 Кгц (Салют-4) вполне успешно справлялась (Сесат, например) и справлялась бы на новых КА. 10 - 20 Мгц (причем, среди них и импортная 16-ти разрядная!) прекрасно справляются сейчас. Причём, ПО системы ориентации по вычислениям - самое сложное после баллистики :). Но там время совсем уж некритично. Помниться, при первом же запуске нашего ПО системы ориентации на Салют-32 сразу нашли аппаратный косяк с плавающей точной. Раньше этого никто просто не использовал. А разработчики не тестировали, как обычно в отрасли, нах*й никому ничего не надо. Когда проблема появится, тогда и будем её решать.. В сущности, ПО системы ориентации сейчас - это простой контроллер и любой программист с практическим опытом работы, например, на Си/Си++, который на хорошем счету в любой современный конторе, сделает за предоставляемые сроки эту задачу предоставляемыми средствами в совершенно безупречном виде по сравнению с тем, как оно делается и в каком виде выходит в лёт сейчас. А вот обратное совершенно невернО. Нужны в этой области и специальные знания, конечно, но это не относится к программированию, да и можно работать в тандеме. Все имеющиеся проблемы, которые я видел на практике, надуманы, обусловлены технологией разработки 50-ых годов и социальными факторами. Сказанное относится только к бортовому ПО системы ориентации и только к тем КА, к которым имел отношение. Про иное не знаю. Любопытно еще, что мощность вычислителя, например, одного известного мне звездного датчика (не БОКЗ), как минимум, в 4-8 раз больше мощности всего бортового компьютера :)
Пример из реальной жизни. КА, с очень высокой централизацией, почти все вычислительные задаци на процессоре БЦВМ, некоторые телеметрические параметры собираются на 100 герцах, общее их количество - порядка 10 тысяч.
При этом наихудшая загрузка 20-мегагерцового ERC32 - 44%
Типичная - менее 20%
ЦитироватьВсе имеющиеся проблемы, которые я видел на практике, надуманы, обусловлены технологией разработки 50-ых годов и социальными факторами.
Вот! Зацеплюсь за эту фразу в контексте своих рассуждений. Похоже, что технологии разработки в других отраслях ушли далеко вперед, а космическая по большей части варилась в своем соку. Когда космос был лидером науки и техники, это было приемлемо. Но сейчас, увы, баланс сил изменился.
ЦитироватьЛюбопытно еще, что мощность вычислителя, например, одного известного мне звездного датчика (не БОКЗ), как минимум, в 4-8 раз больше мощности всего бортового компьютера :)
Хм. А за счет чего? И как с надежностью?
ЦитироватьХм. А за счет чего? И как с надежностью?
За счет этого (кажется, к железу прямого отношения не имею): http://www.module.ru/ruproducts/proc/nm6403.shtml. 2 штуки в вычислителе, не резерв, задействованы обе.
Как с надёжностью? Поживём - увидим.. Переживём - учтём :)
ЦитироватьЦитироватьВсе имеющиеся проблемы, которые я видел на практике, надуманы, обусловлены технологией разработки 50-ых годов и социальными факторами.
Вот! Зацеплюсь за эту фразу в контексте своих рассуждений. Похоже, что технологии разработки в других отраслях ушли далеко вперед, а космическая по большей части варилась в своем соку. Когда космос был лидером науки и техники, это было приемлемо. Но сейчас, увы, баланс сил изменился.
Совершенно верно.
Цитировать2 штуки в вычислителе, не резерв, задействованы обе.
Как с надёжностью? Поживём - увидим.. Переживём - учтём :)
Характеристики не плохие, но как же рад. стойкость и все такое?
ЦитироватьЦитировать2 штуки в вычислителе, не резерв, задействованы обе.
Как с надёжностью? Поживём - увидим.. Переживём - учтём :)
Характеристики не плохие, но как же рад. стойкость и все такое?
Не знаю. Занимаюсь только реализацией мат. модели (не автор модели!) оптики прибора, алгоритмов и ПЗС.
ЦитироватьЦитироватьЦитироватьВсе имеющиеся проблемы, которые я видел на практике, надуманы, обусловлены технологией разработки 50-ых годов и социальными факторами.
Похоже, что технологии разработки в других отраслях ушли далеко вперед
Совершенно верно.
Позволю себе высказать следующее замечание.
У каждой методологии есть своя область применения. Не стоит пытаться перевозить пассажиров на БелАЗах.
В космической отрасли есть весьма существенная специфика, в силу которой созданное для других отраслей может быть в ней неприменимо.
Здесь, кажется, в силу этой специфики даже раздавались призывы все для борта писать вручную на ассемблере и без операционной системы - "чтобы не утратить контроль над кодом", кажется. Я лично с данным призывом не согласен, но специфика есть, согласитесь.
Еще что хочу сказать. Безусловно, последствия реформ для отрасли стали весьма тяжелыми. :(
Но не следует считать, что все аюсолютно беспросветно, на разных предприятиях ситуация своя.
Мне кажется, что и графическое программирование языков ГРАФИТ-ФЛОКС ( http://store.oberoncore.ru/lib/image/drakon/list2.png ), и декларативное ПРОЛ2 ( http://mywebs.su/blog/soft/4346.html ), и бортовые интерпретаторы ДКД и СЕАНС - "бортовые экспертные системы реального времени" ( http://www.laspace.ru/rus/cmi04_10.pdf ) являются в определенном смысле "передовыми" решениями, "ушедшими далеко вперед".
Если мы посмотрим за рубеж - увидим, что и у них космические предприятия используют проблемно-ориентированные языки (HAL/S), графическое программирование (Grafcet http://www.cours.polymtl.ca/ele4202/PDF/grafcetIEEE.pdf ) и формальную верификацию программ (Spin http://spinroot.com/gerard/pdf/gluck_holz.pdf )- что относится, безусловно, к "передовым методологиям".
Не пора ли прошивку научных КА переводить на open source ?
Правильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.
ЦитироватьЕсли мы посмотрим за рубеж - увидим, что и у них космические предприятия используют проблемно-ориентированные языки (HAL/S), графическое программирование (Grafcet http://www.cours.polymtl.ca/ele4202/PDF/grafcetIEEE.pdf ) и формальную верификацию программ (Spin http://spinroot.com/gerard/pdf/gluck_holz.pdf )- что относится, безусловно, к "передовым методологиям".
Про FEAVER для SPIN интересный доумент, надо будет покурить его в менее спешной манере.
В остальном сказать сложно. Что конкретно из себя представлял ПРОЛ2 и ФЛОКС, пока разобраться не смог. Информации не густо.
ЦитироватьПравильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.
Ну шутки шутками, а идея, на мой взгляд, не лишенная смысла.
Была бы какая-никакая платформа в открытом доступе для решения и моделирования типовых задач на КА, уже можно было бы и предметные исследования вести. Анализировать альтернативные подходы и сравнивать результаты с эталонной базой.
ЦитироватьЭтот блок придется тоже резервировать, размещать, тратить на него энергию, тратить ресурсы БВК на снхронизацию, и т.д. и т.п.
Затраты энергии на подобный блок - 100мкА без ухищрений. Хотя я бы смог вписать и в 10мкА. Что касается резервирования... Тогда уж и двигатель надо обязательно резервировать! Уж он-то вряд-ли более надежен чем эта электроника.
ЦитироватьПравильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.
"Это неправильные пчелы и у них неправильный мёд" (с)
Во первых, в 2Мб вполне втискиваются не только ядра open source ОС, а и достаточно полноценные системы - во всяких разных домашних роутерах и WiFi точках доступа обычно как раз столько ресурсов, и чаще всего применяется как раз MIPS :D (я имею в виду не старые компьютеры а маленькие коробочки, массово производимые в Азии).
Во вторых, кроме Linux есть еще несколько веток BSD (FreeBSD - самая распространенная, NetBSD - поддерживает больше всех архитектур), которые намного лучше Linux по качеству кода и по продуманности системы; а также есть микроядерная ОС Minix.
Я лично имею опыт создания таких "наносистем" из обычных дистрибутивов, так что задавайте вопросы если кому интересно.
ЦитироватьА если выключение двигателя должно производится еще и по достигнутой дельта-V с акселерометров? (это точнее, поскольку тяга двигателя и масса аппарата скорее всего известны с меньшей точностью). При этом нужно следить за ориентацией и аварийно отключить двигатель, если правильная ориентация потеряна. Во многих случаях для поддрежания ориентации требуется рулить самим маршевым двигателем. Возможно, нужно следить за уровнем топлива в баках, как для равномерной выработки (и регулировать при этом соотношение компонентов) так и общее количество на предмет предельного расхода на данную операцию и минимальных допустимых остатков после. Вобщем либо ЦП все таки работает в рилтайме либо получается дубль ЦП со всеми связями со зведными датчиками, акселерометрами, гироскопами, датчиками уровня и расхода топлива etc. А зачем?
С акселерометров дельта-V точно получить сложно т.к. выдают они ускорение которое надо еще интегрировать. Естественно любая ошибка датчика при интегрировании будет накапливаться. Но и тут никаких проблем быть не должно. Борт вполне может до отсечки давать блоку управления двигателем ожидаемую поправку времени отключения. Т.е. по текущим показателям датчиков и требуемому импульсу бортом ведется расчет требуемого момента отсечки. Плюс именно коррекции(в дополнении к заложенной циклограмме) - даже если в критический момент времени борт накроется медным тазом(будет занят чем-то еще) двигатели отработают по последним корректным данным.
Касаемо потери ориентации... А что мешает его таки аварийно отключить? Этот момент полностью асинхронный и не суть важно при аварии на сколько он опоздает. Более того, имея классический способ обмена а-ля CAN-шина все двигатели могут начать отработку аварийной циклограммы одновременно.
ЦитироватьКонтроллер управления двигателя циклично выдает широтно-модулированные стробы, между которыми вполне в состоянии слушать команды БВК через тот же UART. Контроллер двигателя после завершения выдачи управляющих импульсов на железо выдает сигнал готовности к приему данных.
Не надо. Современный контроллер эти две задачи способен делать одновременно - и стробы и прием ведется параллельно достаточно простой периферией без участия ядра контроллера. Ядро работает по событиям прерываний уже пришедших символов или корректирует величину в компараторе таймера.
ЗЫ. Кстати тут ИМХО больше подходит не UART, а CAN. http://ru.wikipedia.org/wiki/Controller_Area_Network
ЦитироватьЦитироватьА если выключение двигателя должно производится еще и по достигнутой дельта-V с акселерометров? (это точнее, поскольку тяга двигателя и масса аппарата скорее всего известны с меньшей точностью). При этом нужно следить за ориентацией и аварийно отключить двигатель, если правильная ориентация потеряна. Во многих случаях для поддрежания ориентации требуется рулить самим маршевым двигателем. Возможно, нужно следить за уровнем топлива в баках, как для равномерной выработки (и регулировать при этом соотношение компонентов) так и общее количество на предмет предельного расхода на данную операцию и минимальных допустимых остатков после. Вобщем либо ЦП все таки работает в рилтайме либо получается дубль ЦП со всеми связями со зведными датчиками, акселерометрами, гироскопами, датчиками уровня и расхода топлива etc. А зачем?
С акселерометров дельта-V точно получить сложно т.к. выдают они ускорение которое надо еще интегрировать. Естественно любая ошибка датчика при интегрировании будет накапливаться. Но и тут никаких проблем быть не должно. Борт вполне может до отсечки давать блоку управления двигателем ожидаемую поправку времени отключения. Т.е. по текущим показателям датчиков и требуемому импульсу бортом ведется расчет требуемого момента отсечки. Плюс именно коррекции(в дополнении к заложенной циклограмме) - даже если в критический момент времени борт накроется медным тазом(будет занят чем-то еще) двигатели отработают по последним корректным данным.
Касаемо потери ориентации... А что мешает его таки аварийно отключить? Этот момент полностью асинхронный и не суть важно при аварии на сколько он опоздает. Более того, имея классический способ обмена а-ля CAN-шина все двигатели могут начать отработку аварийной циклограммы одновременно.
Это тем не менее не снимает необходимости для центрального компьютера работать в реальном масштабе времени чтобы постоянно корректировать таймер. Что касается наличия аппаратного таймера, то он полезен. Как дополнительная мера безопасносности. Автоматически выключит двигатель по истечении времени, если вдруг во время выполнения операции центральный проц сдохнет или уйдет в глубокую задумчивость.
ЦитироватьДа, и к вопросу про сборщик мусора: вообще у него очевидно есть производительность обеспечиваемая при его работе как фоновой задачи без потерь скорости реакции системы, а у конкретного счетного/управляющего алгоритма очевидно есть скорость выделения/освобождения памяти.
С динамической памятью есть еще одна засада: При статическом распределении памяти значение любой переменной при необходимости можно поменять в полете простой командой с земли - "записать по такому-то адресу такое-то значение". Адреса всех переменных заранее известны. Столь же легко получить значение любой переменной для "разбора полетов" на земле. В случае динамического распределения памяти потребуется сложная система команд, в первом приближении требуется отдельная команда на каждую переменную.
ЦитироватьС динамической памятью есть еще одна засада: При статическом распределении памяти значение любой переменной при необходимости можно поменять в полете простой командой с земли - "записать по такому-то адресу такое-то значение".
Интересный и серьезный аргумент. Но думаю при желании можно реализовать достаточно простой механизм и в динамике. На вскидку - состояние системы сериализуется. На выходе компактная последовательность параметров, структура которой известна. Удобно для получения диагностического дампа, а также для коррекции произвольной переменной состояния системы путем: сериализации состояния на борту, внесения изменения в последовательность по относительному адресу, десериализации с обновлением состояния измененными данными.
При узком канале связи с землей через малонаправленную антенну, особенно при значительном удаленнии получение полного дампа может быть весьма длительным. Да и анализировать дамп кучи более трудоемко.
ЦитироватьНе пора ли прошивку научных КА переводить на open source ?
RTEMS используется в БЦВК уже нескольких летающих аппаратов
ЦитироватьЭто тем не менее не снимает необходимости для центрального компьютера работать в реальном масштабе времени чтобы постоянно корректировать таймер.
Зачем? Все основные вычисления делаются еще до запуска двигателя. После - только коррекция. По большому счету борт может вообще после запуска ничего не считать и аппарат тем не менее с некоторой точностью будет на траектории. Расчеты после запуска это желательно, но не обязательно (изначально в космонавтике траекторные расчеты аппаратов производились на земле). Это-же и относится к двигателям ориентации - компенсирующий возмущение импульс (по сути - время включения двигателя) может быть вычислен еще до запуска двигателя.
Все коррекции работы двигателей нужны только как результат изменений параметров работы двигателей и параметров аппарата (к примеру массы). Но это не реалтаймовые величины.
ЦитироватьПравильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.
А почему так мало? Могли бы и побольше воткнуть, чай память нынче недорогая - даже космического исполнения защищённая от радиации.
Но в 2Мб вполне войдёт vxWorks, который использует NASA и который доступен коммерчески (с исходниками). Не хочется vxWorks - есть QNX, который делают канадцы и который стоит внутри бортовых компьютеров многих автомобилей. Обе жёстко-realtime'овые с очень хорошими показателями латентности.
Вот тут список клиентов vxWorks: http://www.windriver.com/customers/customer-success/aerospace-defense/
Не нравятся оба варианта? Есть L4 Microkernel - это ядро с формально
математически доказаной корректностью поведения.
А ассемблерщиков и прочих любителей играться с регистрами напрямую - уволить и отправить на пенсию. Вместо них нанять специалистов, разбирающихся в создании надёжного ПО.
ЦитироватьС динамической памятью есть еще одна засада: При статическом распределении памяти значение любой переменной при необходимости можно поменять в полете простой командой с земли - "записать по такому-то адресу такое-то значение". Адреса всех переменных заранее известны. Столь же легко получить значение любой переменной для "разбора полетов" на земле. В случае динамического распределения памяти потребуется сложная система команд, в первом приближении требуется отдельная команда на каждую переменную.
Вообще-то я уже писал, что в динамическом Erlang состояния вообще не хранятся в переменных, тк переменные состояния процесса очень затрудняют тестирование и приводят к труднопредсказуемым эффектам.
И поэтому там состояния требующие надежности хранения хранятся в СУБД, память которой вполне может быть распределена статически.
И далее вместо одной команды изменения ячейки потребуется скомандовать СУБД изменить ячейку и затем стандартным сообщением перезагрузить код, состояние которого определяется этой ячейкой.
Суть в том, что с системой с более высоким уровнем абстракции ВСЯ работа ведется не с машинными словами а с более высокоуровневыми сущностями - с ячейками СУБД, с сообщениями, с скомпилированными модулями.
ЦитироватьЦитироватьПравильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.
А почему так мало? Могли бы и побольше воткнуть, чай память нынче недорогая - даже космического исполнения защищённая от радиации.
А как насчет вероятностного увеличения абсолютного количества сбойных вентилей и ячеек при увеличении объема памяти, что отразится на надежности системы ? И снижение надежности будет в прямой зависимости от абсолютного количества сбоев, потому что архитектура процессора еще не обладает свойствами голографии. С коррекцией на резервирование. А как насчет экстренной необходимости перезагрузки полного дампа ПО при ограниченных информационных скоростях канала связи, когда чем меньше объем, тем лучше ? Не хотел тут писать, но сил нет читать иных умников настольного программирования :)
ЦитироватьЦитироватьЦитироватьПравильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.
А почему так мало? Могли бы и побольше воткнуть, чай память нынче недорогая - даже космического исполнения защищённая от радиации.
А как насчет вероятностного увеличения абсолютного количества сбойных вентилей и ячеек при увеличении объема памяти, что отразится на надежности системы ? И снижение надежности будет в прямой зависимости от абсолютного количества сбоев, потому что архитектура процессора еще не обладает свойствами голографии. С коррекцией на резервирование. А как насчет экстренной необходимости перезагрузки полного дампа ПО при ограниченных информационных скоростях канала связи, когда чем меньше объем, тем лучше ? Не хотел тут писать, но сил нет читать иных умников настольного программирования :)
Про ассемблер. Все как в этом мире. Чтобы чему-то научиться, нужно начинать с азов, с основ. Человек, начинавший программировать на асме, всегда будет программировать намного тщательнее, умнее и оптимальнее на любом языке, чем младой кодировщик, разговаривающий на языке очень высокого уровня :) Я лучше взял бы человека лет 40, начинавшего на МК-61, чем 25летнего, не видевшего ничего глубже окошек VC :)
ЦитироватьЧтобы чему-то научиться, нужно начинать с азов, с основ.
Правильно, основа всего математика.
ЦитироватьЧеловек, начинавший программировать на асме, всегда будет программировать намного тщательнее, умнее и оптимальнее на любом языке, чем младой кодировщик, разговаривающий на языке очень высокого уровня :)
Не согласен. Тут как раз нередко "специалист подобен флюсу" - слишком сильная ориентация на ассемблер приводит к однобокости - ибо человеческий мозг ограничен и за деревьями человек перестает видеть лес.
Возможно баланс тут возможен. Но лично я еще не встречал ни одного человека, который действительно хороший ассемблерщик (действительно понимает как работает железо), без ущерба высокоуровневому абстрагированию.
Ну то есть при социалистической интенсивности труда такие люди очень даже возможны, а при капиталистической просто специализация не позволяет быть одновременно и низкоуровневовым и высокоуровневовым.
ЦитироватьНе согласен. Тут как раз нередко "специалист подобен флюсу" - слишком сильная ориентация на ассемблер приводит к однобокости - ибо человеческий мозг ограничен и за деревьями человек перестает видеть лес..
Да какой специалист и однобокость. Я про другое говорю. Учиться надо на основах, а не обязательно работать на них дальше. Кто знает основы, тот и все остальное освоит без проблем. Почему это нас учили сначала в машинных кодах программировать, когда уже были и языки высокого уровня ? Потому что так нужно. А потом и до высоких дело дошло. Еще такое дело. Если человек витает в окошках и ничего не знает о том, как на самом деле все происходит, он свою же программу или подобную не сможет даже в дебаге низкоуровневом изучать. Например, при реверсе из соседнего источника, поиске проблем. Нет листинга - и привет. Пусть это разделение труда, но не всегда оно возможно. Много пены нынче, нахватаются, книжечку прочитают - уже программисты :) Вот до чего довела всеобщая компьютеризация :)
ЦитироватьА как насчет вероятностного увеличения абсолютного количества сбойных вентилей и ячеек при увеличении объема памяти, что отразится на надежности системы? А как насчет...
А как насчет увеличения сложности миссий?
- Я тут упоминал задачу коммутатор АТС на несколько миллионов абонентов.
Сложность в том, что в отличие от НЫНЕШНИХ АМС коммутатор должен не просто включиться и постепенно подключать к себе абонентов с нуля, а должен как можно быстрее перебрать на себя старых абонентов с других систем, которые строились постепенно десятилетиями.
То есть там наверное уже нет чисто аналоговых АТС, но есть несколько поколений цифровых, работающие на собственных стандартах.
И соответственно, есть ОГРОМНЫЙ зоопарк самого разнообразного оборудования, которого настолько много что быстро его заменить невозможно чисто физически. Точнее, старое оборудование постепенно заменяется по мере выработки ресурса, но система должна работать непрерывно и при этом риалтаймово.
К АМС аналогия с АТС относится достаточно прямо - буквально только пару лет назад были эксперименты с первыми созвездиями спутников ДЗЗ и с взаимодействием нескольких АМС, а до того практически все ДЗЗ/АМС работали изолированно и практически у каждого, был свой отдельный ЦУП.
Но ведь ситуация будет развиваться - посмотрите - сейчас практически все спутниковые организации имеют по крайней мере один проект сети спутников или сети АМС, и даже есть проект АМС, представляющей собой сеть микроспутников.
Причем явно наблюдается постоянное увеличение САС, и мы видим что например те-же "Вояджеры" уже несколько раз хотели закрыть, потому что они отнимают ресурсы которые могли-бы быть использованы с другими АМС.
И всё это ИМХО идет к тому, что аналогично с АТС мы в обозримый период времени прийдем к тому, что будет стоять задача интегрировать какую-то "древнюю" АМС/ДЗЗ/ДЗЛ, построенную по "старым" стандартам в новую спутниковую сеть и максимально эту "древнюю" машину использовать, а затем подключать к этой сети еще и еще машины.
ЦитироватьЦитироватьА как насчет вероятностного увеличения абсолютного количества сбойных вентилей и ячеек при увеличении объема памяти, что отразится на надежности системы? А как насчет...
А как насчет увеличения сложности миссий?
У вас мысли расползаются :) Мы о конкретной АМС, ее миссия четко задана. Была. Не нужно там ничего перемудривать. Физика есть физика, уменьшение проектной нормы в кристаллах и увеличение активных элементов уменьшает надежность в условиях космоса. В какую космическую сеть вы собрались встроить аппарат, миссия и время жизни которого строго ограничены 2-3 годами. А коммутатор может работать 30 лет. Вот вам лишь бы поспорить, давайте, завязывайте с этой порочной практикой :) Одна из причин, по которой я ушел из наших НИИ и промышленности, не к ночи, это сидящие там дяди с безумными глазами, рисующие сотни картинок пустых на листах и болеющие гигантизмом. Гигантизм обладает способностью из горы родить одну малую мышь. Новому - да, оптимуму -да, гигантизму - нет. Так и голосуйте :)
ЦитироватьУчиться надо на основах, а не обязательно работать на них дальше. Кто знает основы, тот и все остальное освоит без проблем. Почему это нас учили сначала в машинных кодах программировать, когда уже были и языки высокого уровня ?
Вас могли учить ассемблеру по разным причинам - от недостатка матчасти ВУЗа до отсталости преподавателей.
- Ассемблеры ведь тоже разные есть, как и ЯВУ между прочим. - Я знаю немало людей отлично владеющих ассемблером х86, но им например крайне сложно объяснить ЦСП - они его понимают конечно, но то что они проектируют выглядит как полет бегемота.
А вот если человек в достаточно молодом возрасте достаточно имел дело с машинами вроде PDP, Vax, m68k, там уже совсем другая ситуация наблюдается - там ведь есть богатый простор для оптимизации и для изощрений и это развивает мозг и позволяет лучше и быстрее воспринимать новое и эффективнее новое использовать.
То же и с ЯВУ - люди всю жизнь прожившие что на Java, что на C++ без серьезного опыта с такими языками как Lisp, Fort (ну пусть хоть Perl или Ruby) тоже в итоге оказываются ограничены.
У меня когда-то была очень занятная беседа - я несколько часов не мог человеку с огромным опытом C++ объяснить, как работает динамическая типизация в ВМ - он просто не мог пустить в свое сознание понятие, что можно работать не с байтами и словами процессора а с более высокоуровневыми абстракциями, и что эти абстракции могут в ВМ приобретать совершенно немыслимые для сишника свойства.
ЦитироватьЦитироватьУчиться надо на основах, а не обязательно работать на них дальше. Кто знает основы, тот и все остальное освоит без проблем. Почему это нас учили сначала в машинных кодах программировать, когда уже были и языки высокого уровня ?
Вас могли учить ассемблеру по разным причинам - от недостатка матчасти ВУЗа до отсталости преподавателей..
Финиш. Полный. Посмотрите, что входило в программу 0608, пардон. Я только за время учебы уже успел изучить 4 ассемблера и, конечно, архитектур разных процессоров, было нужно по работе, кроме Си и Паскаля. Развивать тему не хочется.
ЦитироватьЦитироватьА как насчет увеличения сложности миссий?
Мы о конкретной АМС, ее миссия четко задана. Была.
Ну уже не совсем. Дай Бог конечно чтобы эта АМС свою миссию выполнила, но мы думаю тут не ради только её а и чтобы чего-то наработать для будущего.
Я думаю если-бы такие разговоры велись в 90-х не только в курилках, то сейчас была-бы несколько иная ситуация.
ЦитироватьНе нужно там ничего перемудривать. Физика есть физика, уменьшение проектной нормы в кристаллах и увеличение активных элементов уменьшает надежность в условиях космоса.
Сейчас программистов учат "не пишите сразу оптимизированно - пишите сразу просто и понятно, а потом запускайте бенчмарки и если видите потребность - тогда и занимайтесь оптимизацией".
Суть в том, что "ПРАКТИКА критерий истины".
Так и тут ваши теории оторваны от практики - на американских АМС давно уже ставят RISC процессоры с высокой степенью интеграции, и эти АМС успешно выполняют свои миссии, а нашей АМС большая проектная норма не помогла.
ЦитироватьВ какую космическую сеть вы собрались встроить аппарат, миссия и время жизни которого строго ограничены 2-3 годами. А коммутатор может работать 30 лет.
Никто не знает, сколько будет работать "Вояджер" - а уже больше 30 лет.
Вообще мы пришли к интересной тенденции, которую вы похоже не заметили - сейчас миссии АМС постоянно удлиняются и постоянно отдаляется срок получения результатов - например "Кассини" практически 10 лет летел и практически ничего от него не было, а потом успех с "Гюйгенс". А сколько лет будет лететь миссия к Плутону? А как насчет изучения облака Оорта? - Там как раз и нужно будет чего-то сооружать, которое будет в полете саморемонтироваться и переконфигурироваться.
И тут есть неприятный такой момент, ИМЕННО что миссии ДОЛЖНЫ усложняться - такой возможности обойти всех на кривой козе как была попытка Ф-Г уже может и не быть, тк может оказаться что ввиду длительности самого процесса подготовки к запуску следующей АМС уже не будет смысла в тех экспериментах что МЫ можем следать, тк их уже сделают другие страны.
АМС это как спорт - тут интересны только призовые места, а какое-нить надцатое место не оправдывает затраты.
- Это сейчас мы якобы четвертые после США,ЕС и Японии, а что будет когда подтянутся Китай, Индия, Бразилия? - Думаю тогда на этом форуме останутся только ностальгирующие да занимающиеся практическим применением в ДЗЗ и связи, тк остальной космос просто оставят без финансирования.
ЦитироватьВот вам лишь бы поспорить, давайте, завязывайте с этой порочной практикой :) Одна из причин, по которой я ушел из наших НИИ и промышленности, не к ночи, это сидящие там дяди с безумными глазами, рисующие сотни картинок пустых на листах и болеющие гигантизмом.
Я не болею гигантизмом. Потому что для меня критерий истины практика. И вам того-же желаю :wink:
ЦитироватьЦитироватьЦитироватьПравильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.
А почему так мало? Могли бы и побольше воткнуть, чай память нынче недорогая - даже космического исполнения защищённая от радиации.
А как насчет вероятностного увеличения абсолютного количества сбойных вентилей и ячеек при увеличении объема памяти, что отразится на надежности системы ?
А так. В память встраиваются системы коррекции ошибок и пишутся коды коррекции, которые могут исправлять однобитовые ошибки. В случае многобитовых ошибок страница памяти помечается как сбойная (о чём сообщается операционной системе) - если страница принадлежит некритичному процессу, то всё просто продолжит спокойно работать дальше, а страница будет исключена из списка доступных. Потом земля уже разберётся в спокойной обстановке.
Если страница критична, то система просто уйдёт в перезагрузку. Этот механизм даже уже в обычных "гражданских" серверных процессорах есть ( http://lwn.net/Articles/348886/ ).
Дополнительно, надёжность собственно системы контроля достаточно велика, так как там совсем немного аппаратной логики. Получается, что безопаснее использовать систему коррекции ошибок + куча памяти, чем немного памяти, но без коррекции ошибок.
ЦитироватьА как насчет экстренной необходимости перезагрузки полного дампа ПО при ограниченных информационных скоростях канала связи, когда чем меньше объем, тем лучше ? Не хотел тут писать, но сил нет читать иных умников настольного программирования :)
Есть старые байки о том, как НАСА патчили в полёте код Вояджера. Так там код написан был на диалекте ЛИСПа. И ничего.
Если на аппарате нормальная база, то можно организовать достаточно функциональный безопасный режим, так что засылаемый код сможет использовать его сервисы.
ЦитироватьУ вас мысли расползаются :) Мы о конкретной АМС, ее миссия четко задана. Была. Не нужно там ничего перемудривать. Физика есть физика, уменьшение проектной нормы в кристаллах и увеличение активных элементов уменьшает надежность в условиях космоса. В какую космическую сеть вы собрались встроить аппарат, миссия и время жизни которого строго ограничены 2-3 годами.
Вообще-то, у НАСА сейчас совершенно серьёзные планы по созданию межпланетной коммункационной сети. До какой-то степени они уже работают - с Марсом у нас сейчас устойчивый канал в 8Мбит. Так что Opportunity не надо будет напрямую до Земли стучаться, достаточно достать ближайший спутник.
Асссемблер один, ассемблер другой... Предлагать писать код АМС на ассемблере может или замшелый пень, или сознательный вредитель. Программирование на ассемблере отнимает драгоценное время высококвалифицированных разработчиков на полную чепуху вроде выписывания условия обработки стека или выхода из цикла.
Для примера: ПО Mars Science Laboratory написано на С, содержит 2.5 миллиона строк кода и исполняет порядка 130 конкурентных процессов одновременно. Вы ЭТО собрались писать на ассемблере? :D
ЦитироватьА так. В память встраиваются системы коррекции ошибок и пишутся коды коррекции, которые могут исправлять однобитовые ошибки. В случае многобитовых ошибок страница памяти помечается как сбойная (о чём сообщается операционной системе) - если страница принадлежит некритичному процессу, то всё просто продолжит спокойно работать дальше, а страница будет исключена из списка доступных. Потом земля уже разберётся в спокойной обстановке.
.
Вот же давал себе слово не вступать в этот раздел :) Быстрее бы разобрались с ФГ, и я уйду. Заниматься ликбезом не входит в мои планы. Почитайте, что такое коды команд, адресное пространство, область кода, счетчик команд, как устроена память, что такое вентили и почему всю систему нельзя считать одной большой самовосстанавливающейся матрицей, из-за чего и применяют то самое дублирование и троирование :)
Беда, совсем беда.... и так давно понятно, но когда сталкиваешься напрямую, становится не по себе. Хорошо, что еще кто-то понимает, что нет несокрушимой никаким силами ОС, что работает она в тех же битах памяти, которые могут выйти из строя, и что PC - это не черный ящик, который работает на уровне ООП. Пока такие люди есть, АМС еще будут летать.
:)
ЦитироватьДа какой специалист и однобокость. Я про другое говорю. Учиться надо на основах, а не обязательно работать на них дальше. Кто знает основы, тот и все остальное освоит без проблем. Почему это нас учили сначала в машинных кодах программировать, когда уже были и языки высокого уровня ? Потому что так нужно.
Нет, потому что по-другому не умели. Программирование за эти годы ушло даааааалеко вперёд. Сейчас знание ассемблера нужно для:
1) Очень низкоуровневых вещей в ядре ОС.
2) Коротких вставки для оптимизации.
3) Очень ограниченных архитектур.
4) Написания компиляторов и других инструментальных систем.
Из этого списка к космическому аппарату применимо только 4) и даже пункт 1 можно избежать. Сколь-либо больше ассемблерные программы не имеют смысла вообще.
В современном программировании (и даже не космическом!) главное уже не скорость работы, а надёжность. Мы за многие годы выяснили, что человек не умеет писать программы без ошибок, и чем на более низком уровне - тем всё хуже.
Потому НАСА и другие товарищи вкладываются не в обучение ассемблерщиков, которые имеют интимные отношения напрямую с железом, а в методы формальной верификации кода и методологию создания надёжного ПО. Так чтобы минимизировать влияние неизбежных человеческих ошибок.
Для примера, код Шаттла - это 20 миллионов строк кода. Его писали ДВЕ независимые команды, не общающиеся друг с другом и работающие только со спецификациями на функции. В результате это получился самый надёжный код в истории.
ЦитироватьЯ не болею гигантизмом. Потому что для меня критерий истины практика. И вам того-же желаю :wink:
Скажите прямо, пока я еще на форуме, вы что-то создали своим руками ? От задумки, квадратов, моделирования алгоритмов на языке высокого уровня, до железа+программ, до тестов образцов, испытаний ? Я - да. И сейчас, если я не выполню очень практические дела, сам, то не получу на кусок хлеба. Это к вашему вопросу о практике. Вашим RISC-процессорам лет 30. Еще важно то, что вам могут просто не продать не то что готовые современные схемы, годные для космоса, но даже болванки. А своего передового производства у нас нет. Поэтому нужно делать на чем есть.
Я уверен, что бортовая машина ФГ не является тонким местом в смысле увеличения сложности миссии, как вы тут пытаетесь представить. Не майтесь мурой, хотя такие призывы на форуме могут быть бесполезными. Всегда найдутся не слышащие и не видящие, что пишут другие, тут уже примеры имеются, яркие. Писать умеют, читать - нет. Я думал, на техническом форуме более адекватные люди, чем на мейлахру, однако и тут хватает психов. Поговорим об общих делах ФГ в другой ветке.
ЦитироватьВот же давал себе слово не вступать в этот раздел :) Быстрее бы разобрались с ФГ, и я уйду. Заниматься ликбезом не входит в мои планы. Почитайте, что такое коды команд, адресное пространство, область кода, счетчик команд, как устроена память, что такое вентили и почему всю систему нельзя считать одной большой самовосстанавливающейся матрицей, из-за чего и применяют то самое дублирование и троирование :)
Дублирование и троирование - это способ восстановления после аппаратных ошибок. Оно ну никак не поможет от программных, от которых гораздо лучше помогает использование нормальной базовой системы и инструментальных средств.
Опять же, уходите от вопроса: "почему нельзя поставить больше памяти". Возможность возникновения ошибки в памяти КА - это совершенно штатная ситуация. И надеяться, что уменьшение объёма памяти от неё спасёт - это ненадёжно.
В любом случае нужна система самодиагностики и коррекции ошибок, а раз она есть, то добавление дополнительной памяти не приведёт к изменению характеристик надёжности (количество вентилей в системе коррекции не изменится существенно).
Это реально работает. Gravity Probe B, летавшая через самую гущу радиационных поясов на полярной орбите корректировала по несколько десятков однобитовых ошибок в день и изредка натыкалась на многобитовую.
Вот тут замечательный список: http://en.wikipedia.org/wiki/Gravity_Probe_B_mission_timeline
ЦитироватьСкажите прямо, пока я еще на форуме, вы что-то создали своим руками ? От задумки, квадратов, моделирования алгоритмов на языке высокого уровня, до железа+программ, до тестов образцов, испытаний ? Я - да.
ЦитироватьВ наше время никому нельзя доверять, даже самому себе. Мне - можно
:mrgreen:
ЦитироватьДублирование и троирование - это способ восстановления после аппаратных ошибок. Оно ну никак не поможет от программных, от которых гораздо лучше помогает использование нормальной базовой системы и инструментальных средств.
Не, я пас. Я умею общаться с теми, кто слышит :) Вы вообще понимаете, что все на кристаллах состоит из элементарных физических активных единиц, и все они в равной степени подвергаются воздействию ? И эти единицы не знают, что ее величество ОС беспокоить никак нельзя. Увеличение сбоев в матрице памяти будет устранено системой коррекции ошибок, но кто будет устранять сбойные вентили или транзисторы в физической системе этой коррекции - это вам не кадр информации, дополнительных линиях, системе адресации и контроля записи/чтения матрицы ? Для этого и используется троирование по шине, контроль более простой системой над более сложной, неравенство вероятностей сбоя обеспечивает логичность такого подхода. Это я не говорю еще об уменьшении проектной нормы. Про качество кристаллов уже сказал. До встреч :)
ЦитироватьДублирование и троирование - это способ восстановления после аппаратных ошибок.
Эт Вы зря. "Горячее" дублирование и троирование - это способ не замечать аппаратных ошибок
ЦитироватьУвеличение сбоев в матрице памяти будет устранено системой коррекции ошибок, но кто будет устранять сбойные вентили или транзисторы в физической системе этой коррекции - это вам не кадр информации, дополнительных линиях, системе адресации и контроля записи/чтения матрицы ?
Вам стоит понять, что во ВСЕХ инженерных системах будут какие-то критичные части. Это просто факт жизни. Необходимо количество таких частей сводить к абсолютному минимуму.
Проблема в том, что часто приходится идти на компромисы - увеличение надёжности одной системы влечёт уменьшение надёжности другой. И как раз увеличение надёжности аппаратной части с помощью (чрезмерного!) её упрощения неизбежно влечёт за собой увеличение сложности программной части и уменьшение её надёжности.
А история уже показала, что как раз программная часть является намного более опасной с точки зрения ошибок. И если можно увеличить её надёжность путём небольшого уменьшения надёжности аппаратуры, то это надо делать. Тем более, что космическое железо более-менее уже устоялось и его надёжность не вызывает проблем.
Более того, дополнительная память не будет лежать на критическом пути. Потому влияние её на надёжность будет минимально.
А программирование логики КА напрямую на ассемблере без защиты памяти - это вообще сумасшествие, так как делает ВЕСЬ программный код критичным. И это не шутка - из-за глупой программной ошибки мы потеряли "Фобос-1" и скорее всего "Фобос-2".
ЦитироватьЦитироватьДублирование и троирование - это способ восстановления после аппаратных ошибок.
Эт Вы зря. "Горячее" дублирование и троирование - это способ не замечать аппаратных ошибок
Не то чтобы "не замечать" - отказ одного из канала будет точно заметен :) А скорее способ сделать отказ одного канала некритичным.
Но от программных ошибок оно таки не спасает никак.
ЦитироватьУвеличение сбоев в матрице памяти будет устранено системой коррекции ошибок, но кто будет устранять сбойные вентили или транзисторы в физической системе этой коррекции
Дайте ссылочку на источник этого утверждения.
Я конечно могу ошибаться, но ЕМНИС коррекции не важно, где случился сбойный вентиль - в проверяемой/корректируемой системе или в корректирующей - МАТЕМАТИКА устраняет все сбои без разбора где именно они произошли и вопрос только в количестве допустимых для конкретной математики сбоев.
- А по сути нашего обсуждения этой коррекции хватает на функционирование БВК с защитой памяти и с десятками мегабайтов ОЗУ возле Юпитера, где радиация намного жестче чем возле Марса.
ЦитироватьЦитироватьУвеличение сбоев в матрице памяти будет устранено системой коррекции ошибок, но кто будет устранять сбойные вентили или транзисторы в физической системе этой коррекции
Дайте ссылочку на источник этого утверждения.
Я конечно могу ошибаться, но ЕМНИС коррекции не важно, где случился сбойный вентиль - в проверяемой/корректируемой системе или в корректирующей - МАТЕМАТИКА устраняет все сбои без разбора г.
Вы несете такую чушь, простите. Вы просто не понимаете разницу между логически-математическим уровнем исправления ошибок и физическим. Я не буду вам объяснять дальше. Самовосстанавливающиеся от ошибок на физическом уровне дискретные схемы есть только в фантастике. Если вы хотите внедрить свой Эрланг в НПОЛ и предложить свои знания на этот счет, обратитесь туда напрямую, здесь какой толк о нем писать. Я знаю другой язык подобного уровня, применяемый в очень сложных системах, вам его название, возможно, ничего не скажет. Теперь каждый будет пихать свое видение в этот ФГ ? :) Непродуктивно.
Задача бортовой машины - обеспечивать необходимые функции при заданном уровне надежности. Если это обеспечивается с 2 Мб, то зачем ставить больше, чтобы увеличивать вероятность проблем ? Не умножайте сущности без надобности. Это привычка всех программеров на коленке, которые не связаны четкими ТЗ на конкретное железо, видят перед собой PC, где бездонные терабайты и большие скорости. В железе рамки часто куда более жесткие, и нужно уметь оптимально распорядиться теми ресурсами, которые есть и ограничены. У американцев, японцев есть технологические линии по производству наилучших кристаллов, а у нас этого нет.
Цитировать
Всегда есть люди, читающие по диагонали. Здесь такие же даже не поняли мысль, которую я высказал много раз, у них внутри сверхценные идеи, которые мешают читать и думать. Если за столько строк они не поняли, что я не ратую писать на асме, а за то, чтобы писать аккуратно, оптимально и эффективно, не впадая в гигантизмы. А асм полезен, потому что помогает приучиться к такому подходу и не терять связь с железом. При этом асм вовсе не обязан быть средством разработки, оставаясь неким базовым знанием. О чем еще тут говорить ? Трите свои сверхценные идеи дальше :)
ЦитироватьВсегда есть люди, читающие по диагонали
Все люди субъективны, и все люди ошибаются. Только есть еще такие вроде вас, которые упрямо отстаивают собственные ошибки, игнорируя единственное мерило истины - практику.
ЦитироватьЦитироватьВсегда есть люди, читающие по диагонали
Все люди субъективны, и все люди ошибаются. Только есть еще такие вроде вас, которые упрямо отстаивают собственные ошибки, игнорируя единственное мерило истины - практику.
Будем считать, что соскочили. Про практику я вам написал раза три :) У меня ее предостаточно, в очень разных областях. Отбросьте ваш эрланг и тоже добавьте практики, особенно в железе, сможете смотреть на мир шире, вернее и прозрачнее :)
ЦитироватьЦитироватьДублирование и троирование - это способ восстановления после аппаратных ошибок.
Эт Вы зря. "Горячее" дублирование и троирование - это способ не замечать аппаратных ошибок
Я бы разделил.
Дублирование - способ восстановления после аппаратных ошибок.
Требует, как правило анализа и принятия решения.
Троирование - это способ не замечать аппаратных ошибок.
ЦитироватьПро практику я вам написал раза три :) У меня ее предостаточно, в очень разных областях. Отбросьте ваш эрланг и тоже добавьте практики, особенно в железе, сможете смотреть на мир шире, вернее и прозрачнее :)
У меня уже достаточно практики с железом - оно мне уже стало скушно, и я перешел к сложным системам, в том числе к Эрлангу :D
Точнее, вы тяготеете к натуральному хозяйству с полным воспроизводством всего локально, а я уже достаточно давно и прочно перешел к капиталстической модели с разделением труда - мне выгоднее не делать самому ВСЁ, а найти человека (или организацию), который сделает мне какие-то вещи достаточно близко к моему пониманию, но дешевле чем это сделал-бы я. И себе я оставляю в основном интеграцию и доводку до продукта, а также программирование.
И вы можете спорить сколько угодно, но на определенных уровнях сложности систем иного выхода кроме специализации и разделения труда нет, причем как раз из соображений надежности.
Надежность в смысле предсказуемости реализации ТЗ в предсказуемые сроки и по предсказуемой себестоимости.
Например, была конкретная задача, которая в себя включала программу, сеть и некоторое количество оборудования. И была физическая возможность изготовить некоторое количество оборудования самостоятельно. Так вот оказалось (и было доказано практикой), что изготовление своими силами обеспечивает лучшее качество оборудования, но отнимает ресурсы от программирования и это не компенсируется лучшим качеством самостоятельно изготовленного оборудования. То есть усложнение программы для работы с менее качественным но уже готовым дешевым оборудованием позволяет решить задачу надежнее чем отвлечение сил на изготовление собственного оборудования.
ЦитироватьТроирование - это способ не замечать аппаратных ошибок.
Аппаратные ошибки на низкой орбите, ниже радиационных поясов, через час после пуска- это непозволительная роскошь. Понятно, что при проходе рад поясов, на межпланетной траектории, троирование иметь необходимо- вдруг вспышка на Солнце или еще какая галактическая частица прилетит. Ну и в конце миссии троирование обычно позволет продлить миссию за расчетные сроки.
Но в тех условиях, где болтается сейчас ФГ, обычная бытовая электроника выхаживает недели и месяцы без сбоев, даже в негерметичных контейнерах. Сколько любительских спутников летало на бытовухе.
Цитировать
Вы спорите сами с собой, генерируя мысли-противопоставления, которые я не высказывал и не собирался высказывать. Я вам предлагаю немного подождать, мое появление здесь обусловлено исключительно интересом к такой драматической эпопее ФГ. Когда все окончательно упрется в туман или все выяснится, мне будет мало интереса здесь появляться. И вы будете спорить с кем-то другим про эрланги, хоть до потери глазами орбиты :) Я же привык говорить о конкретных вещах, предметно, или пошутить между делом :)
ЦитироватьЦитироватьТроирование - это способ не замечать аппаратных ошибок.
Аппаратные ошибки на низкой орбите, ниже радиационных поясов, через час после пуска- это непозволительная роскошь. .
Это в другую большую тему, про версии отказа. Тут обсуждают высокие стили программирования :) Сам я также не верю в отказ бортовой машины по ее внутренним причинам.
ЦитироватьВы спорите сами с собой, генерируя мысли-противопоставления, которые я не высказывал и не собирался высказывать.... Я же привык говорить о конкретных вещах, предметно, или пошутить между делом :)
А я самый скромный в мире человек :lol:
ЦитироватьА я самый скромный в мире человек :lol:
zyxman, вы общаетесь с фонтаном. Здесь нужен сантехник :D
ЦитироватьПро ассемблер. Все как в этом мире. Чтобы чему-то научиться, нужно начинать с азов, с основ. Человек, начинавший программировать на асме, всегда будет программировать намного тщательнее, умнее и оптимальнее на любом языке, чем младой кодировщик, разговаривающий на языке очень высокого уровня :) Я лучше взял бы человека лет 40, начинавшего на МК-61, чем 25летнего, не видевшего ничего глубже окошек VC :)
Во вяском случае программист real-time и embedded систем уж точно должен понимать, как оно там физически работает. ПО КА подходит под оба пункта в полной мере. Не буквально каждую машинную команду своей программы, конечно, и большая часть ПО может быть написана на подходящем языке высокого уровня, но пониманеи что он делает и во что это выльется на физическом уровне необходимо. А программист окошек под виндос конечно, может целиком и полностью витать в некоем абстрактном идеальном мире, созданном ерлангом или другой средой программирования.
Ох уж мне эти подстольные программисты... ну да ладно - сам таким был :wink:
ЦитироватьНе буквально каждую машинную команду своей программы, конечно, и большая часть ПО может быть написана на подходящем языке высокого уровня, но пониманеи что он делает и во что это выльется на физическом уровне необходимо. А программист окошек под виндос конечно, может целиком и полностью витать в некоем абстрактном идеальном мире, созданном ерлангом или другой средой программирования.
Осталось объяснить персонам, которые это не понимают. И не поймут, из всех дурацких околотехнических снобов, которых я видел - самые дурацкие были в среде "чистых" программистов. Им гораздо легче пространно витийствовать, чем что-то сделать в железе - это ведь куда сложнее. Когда я учился, было хорошо видно такое разделение. Кто не умел толком ничего делать - шел в окошки и в нарождающиеся конторки, продвигающие всякие СУБД и ворды. Очень умно начинал рассуждать, только вот в среде промышленности они были пшиком. А теперь таких большинство. Пройдет еще одно поколение, взрощенное на снобизме высокого программирования - и мы уже не сможем снабдить ПО даже ФГ. Для этих людей мясо растет в пельменях. И так во всех сферах промышленности, потому что ее уже наполовину нет.
ЦитироватьВо вяском случае программист real-time и embedded систем уж точно должен понимать, как оно там физически работает.
Понимать должен. Но делать не должен.
Как раз именно в нынешнее время программист должен как и любой инженер уметь найти и применить готовое решение.
Потому что готовый отлаженный код экономит время и повышает надежность.
ЦитироватьБудем считать, что соскочили. Про практику я вам написал раза три :) У меня ее предостаточно, в очень разных областях. Отбросьте ваш эрланг и тоже добавьте практики, особенно в железе, сможете смотреть на мир шире, вернее и прозрачнее :)
Я тут не сказал, но вообще-то я работаю с товарищами, пишущими софт для критически важных систем. Где проблемы могут стоить миллионных убытков и потерянных жизней.
Так что же, они пишут его вовсе не на ассемблере. И даже не на С или С++ - так как цена ошибки слишком велика.
Они его пишут на специальном языке VDM, в котором корректность программ доказывается формально. Для исполнения используют высоконадёжные промышленные чипы.
VDM тоже чистый функциональный подход.
Цитироватьсофт для критически важных систем... его пишут на специальном языке VDM, в котором корректность программ доказывается формально. Для исполнения используют высоконадёжные промышленные чипы
VDM... ммммм... Это часом не язык для описания аппаратуры?
Или имеется в виду Венский подход к описанию семантики языков программирования?
Определения из Интернета:
http://www.encyclo.co.uk/define/VDM
Цитироватьесли человек в достаточно молодом возрасте достаточно имел дело с машинами вроде PDP, Vax, m68k, там уже совсем другая ситуация наблюдается - там ведь есть богатый простор для оптимизации и для изощрений и это развивает мозг и позволяет лучше и быстрее воспринимать новое и эффективнее новое использовать
ЦитироватьЯ лучше взял бы человека лет 40, начинавшего на МК-61, чем 25летнего, не видевшего ничего глубже окошек VC :)
Это же про меня! Про меня! :lol:
Значит, меня бы взяли 8) Unispace не даст умереть с голоду на старости лет...
Цитироватьу НАСА... у нас...
Простите за личный вопрос, Вы работаете в НАСА?
ЦитироватьПО Mars Science Laboratory написано на С, содержит 2.5 миллиона строк кода и исполняет порядка 130 конкурентных процессов
Это который запускают сейчас? А откуда дровишки? не поделитесь?
По поводу Си же можно лишь пожалеть.
Цитироватьиз всех дурацких околотехнических снобов, которых я видел - самые дурацкие были в среде "чистых" программистов
Да, есть подобное :)
Цитироватьиз всех дурацких околотехнических снобов, которых я видел - самые дурацкие были в среде "чистых" программистов ... Пройдет еще одно поколение, взрощенное на снобизме высокого программирования - и мы уже не сможем снабдить ПО даже ФГ. Для этих людей мясо растет в пельменях. И так во всех сферах промышленности, потому что ее уже наполовину нет.
Да эти утопические рассуждения не ведут никуда. Если так пойдет, то единственным логичным эволюционным исходом станет внедрение все более современных технических средств, которые позволят иметь и окошки, и реальное время одновременно. И проблема будет решена. Не идеально, но реально :lol:
ЦитироватьVDM... ммммм... Это часом не язык для описания аппаратуры?
тут неплохое описание:
http://en.wikipedia.org/wiki/Vienna_Development_Method
ЦитироватьИли имеется в виду Венский подход к описанию семантики языков программирования?
Не семантики языков, а СИСТЕМ вообще.
И да, Венский подход.
ЦитироватьДа эти утопические рассуждения не ведут никуда.
Именно эти что вы комментировали действительно никуда не ведут.
Потому что они есть не что иное как вариант "раньше трава была зеленее".
ЦитироватьЕсли так пойдет, то единственным логичным эволюционным исходом станет внедрение все более современных технических средств, которые позволят иметь и окошки, и реальное время одновременно. И проблема будет решена. Не идеально, но реально :lol:
Проблема в том, что окошки тут обсуждаете вы.
Не знаю, вероятно у вас с окошками какие-то психологические проблемы, и поэтому вы постоянно к окошкам возвращаетесь, даже когда контекст совсем никак с окошками не связан.
ЦитироватьПроблема в том, что окошки тут обсуждаете вы.
Эмм. Вообще-то это был первый раз, когда я упомянул окошки. Да и то, лишь передергивал спеца, который их тут постоянно упоминает.
ЦитироватьПо поводу Си же можно лишь пожалеть.
Тут можно ответить известным афоризмом:
"There are only two kinds of programming languages: those people always bitch about and those nobody uses."
ЦитироватьThe Mars Science Laboratory (MSL), to be launched in 2011. MSL is a compact car size rover, developed at the Jet Propulsion Laboratory. It is programmed in more than 3 million lines of code (including auto-generated code), more than the combined code onboard all previous Mars missions together. This trend in software growth is expected to continue also for future Mars missions, making it a challenge to apply traditional formal methods. The system is highly multi-threaded with approximately 160 threads. It is programmed in C by a team of 30+ programmers. The system is tested by a team of 10+ testers. Testing is complicated by the fact that the programming team has little time for activities not directly related to development of new software, and hence cannot be disturbed too much by a testing effort. This prevents for example an approach based on new test-specific code instrumentation, be it automated or not. In addition, the system is difficult to execute due to its tight connection with hardware. This makes test-input generation and multiple automated re-runs a challenging task.
Источник: "Runtime Verification: 9th International Workshop, RV 2009 (http://books.google.ru/books?id=A_IBWF69WjMC&lpg=PA16&ots=40-XsHycm_&dq=mars%20science%20laboratory%20programming%20language&pg=PP1#v=onepage&q&f=false)"
Вот вам и про С, и про тестеров, и про ассинхронность, и про формальную верификацию. Могу поздравить себя, т.к. я все-таки был ближе всего к реальности 8)
ЦитироватьВот вам и про С, и про тестеров, и про ассинхронность, и про формальную верификацию. Могу поздравить себя, т.к. я все-таки был ближе всего к реальности 8)
Сколько человек из числа разработчиков СПО в НПОЛ ездило на международные конференции по верификации ПО и другим формальным методам? :roll:
Один из самых важных моментов:
ЦитироватьIt is programmed in C by a team of 30+ programmers. The system is tested by a team of 10+ testers.
С таким коллективом можно действительно серьёзно развернуться.
ЦитироватьСколько человек из числа разработчиков СПО в НПОЛ ездило на международные конференции по верификации ПО и другим формальным методам? :roll:
Не задавайте глупых вопросов, поскольку ответ очевиден: они выше этого.
ЦитироватьСколько человек из числа разработчиков СПО в НПОЛ ездило на международные конференции по верификации ПО и другим формальным методам? :roll:
Да ну при чем здесь это? Я тоже никуда не ездил и вообще не имею отношения к разработке ПО КА. Однако опираясь на свой ограниченный (буду скромным) опыт в организации разработки и тестирования ПО и бегло проанализировав специфику данной конкретной области, пришел к выводам, с которыми, как оказалось, согласились бы инженеры NASA, работавшие над одним из последних проектов в этой области.
И смысл не в том, что в НПОЛ делали так или не так - у них свои проблемы и ограничения. Смысл в том, что это логичное направление развития в разработке таких систем. Пора уже отложить ставшие родными циклограммы в сторону :wink:
ЦитироватьС таким коллективом можно действительно серьёзно развернуться.
Тут можно поспорить, а упоминание "серебряной пули" было бы наконец к месту :)
Цитироватьbs пишет:
ЦитироватьИ смысл не в том, что в НПОЛ делали так или не так - у них свои проблемы и ограничения. Смысл в том, что это логичное направление развития в разработке таких систем. Пора уже отложить ставшие родными циклограммы в сторону :wink:
ЦитироватьС таким коллективом можно действительно серьёзно развернуться.
Тут можно поспорить, а упоминание "серебряной пули" было бы наконец к месту :)
Хорошо, отложили "родные" циклограммы, и что?
Wishbone , извитите, я удалил больше чем хотел. Это вопрос к bs.
ЦитироватьХорошо, отложили "родные" циклограммы, и что?
Как что? "Мы пойдем другим путем". Ну и получили искомый результат. К слову сказать, циклограмма участка выведения на отлетную траекторию в КИСе ни разу не прошла без замечаний. А мы еще удивляемся, почему это ФГ не улетел к Марсу, и все ссылаемся: то двигатель не включился (как будто он сам включается), то короткое замыкание (наверно, от сырости), то проблемы в системе электроснабжения. "Чем кумушек считать трудиться..."
Да, конечно, технические решения могут быть самыми разными, но технология создания и отработки КА нарабатывалась десятилетиями, и еще никто не смог ее опровергнуть. Вот и создателям ФГ это не удалось, как они ни старались доказать, что старый опыт надо выбросить, а у них есть новые подходы.
Первый такой подход мы наблюдаем благодаря NORAD. Надеюсь, что второго подхода им не дадут, иначе новых российских АМС наше поколение просто не дождется.
ЦитироватьЭмм. Вообще-то это был первый раз, когда я упомянул окошки.
Извините. Что-то тут дискуссия идет традиционными нездоровыми путями..
- То окошки упоминают, то популярностями меряются, то вспоминают как все было хорошо раньше и как стало всё плохо сейчас :lol:
Цитироватьтехнология создания и отработки КА нарабатывалась десятилетиями, и еще никто не смог ее опровергнуть.
Не ошибаетесь? Это последние "успешные" миссии по изучению фобоса/марса не дают опровергнуть? Тогда тоже, уверен, молва была, мол лезут тут с модными циклограммами. На кулачковых-то и аналоговых вычислителях работало и никто не смог опровергнуть! :wink:
ЦитироватьЦитироватьМогу поздравить себя, т.к. я все-таки был ближе всего к реальности 8)
К какой? Действительность - она везде разная.
Я бы не сказал, например, что использовать для программирования критических приложений Си - наилучший вариант.
Кстати, по поводу действительности
ЦитироватьПора уже отложить ставшие родными циклограммы в сторону :wink:
Что за бред?
Циклограммы убрать в космической отрасли?
Вы сами понимаете, что пишете?
Цитироватьпишут его вовсе не на ассемблере. И даже не на С или С++ - так как цена ошибки слишком велика. Они его пишут на специальном языке VDM, в котором корректность программ доказывается формально
Настоятельно просим подробности в студию!
Вся мишура, которая тут выдается высокими программистами, лакмусируется очень просто. Спрашиваем у них - вы ГОТОВЫ написать ПО для ФГ так, как вы считает правильным, считая, что вознаграждение вас достойно, а не трендеть ? И все. Очень много воды, но реальность состоит в том, что написать сложное embedded ПО с RTOS - это не рассказывать басни про эрланги, это намного сложнее. Если мне скажут судьи кто, и зададут такой же вопрос, то я был бы готов не стушеваться и поучаствовать в проекте, технически. Но организационно - нет.
ЦитироватьТут можно ответить известным афоризмом:
"There are only two kinds of programming languages: those people always bitch about and those nobody uses."
А я позволю себе повторить ранее высказанное:
в отрасли применялись и применяются с успехом и другие языки программирования высокого и сверхвысокого уровней, в частности:
- Ада
- Java
- Модула-2
- HAL/S
- ПРОЛ2
- ГРАФИТ-ФЛОКС
Могу высказать предположение, что и Джовиаль используется/использовался.
ЦитироватьЧто за бред?
Циклограммы убрать в космической отрасли?
Вы сами понимаете, что пишете?
Этой фразой я обобщал мои предыдущие рассуждения. Тут более "близкие к телу" спецы не раз говорили о бесполезности и вреде многозадачности и ассинхронности в космической отрасли. О вреде языков высокого уровня и неспециализированных языков тоже поговорили. Так вот, реальность такова, что весь этот супер вредный ансамбль целенаправленно используется в NASA и сыграл свою роль не в одной успешной миссии. Неужели мы такие умные, а они полные идиоты и не видят этой серьезной проблемы?
ЦитироватьЯ бы не сказал, например, что использовать для программирования критических приложений Си - наилучший вариант.
Нельзя так категорично. Скажем так, если на Си можно разработать решение с требуемой надежностью, то в чем проблема? В случае c MSL я готов спорить, что Си был выбран по серьезным соображениям, а не от тоски по ассемблеру. На вскидку - "родной" компилятор под целевую ОС (следовательно, "прямая" поддержка многозадачности и асинхронности), наработанная база решений из предыдущих миссий, наработанная база средств разработки и тестирования, тот же SPIN (вычитал, что использовался для тестирования как минимум ПО модуля обработки/передачи изображений). В общем суровая, но развивающаяся база.
По отдельным факторам Си будет бесспорно проигрывать. Но в стройной методологии разработки он может быть и не самым плохим выбором.
ЦитироватьVDM тоже чистый функциональный подход
Посмотрел - неа. Есть понятие функций - действительно, без побочных эффектов, и есть понятие операций - как раз императивная часть.
ЦитироватьВся мишура, которая тут выдается высокими программистами, лакмусируется очень просто. Спрашиваем у них - вы ГОТОВЫ написать ПО для ФГ так, как вы считает правильным, считая, что вознаграждение вас достойно, а не трендеть ?
Честно, я бы рискнул поработать так (писать так как считаю правильным) ОДИН ГОД за еду и за общагу и за галочку в резюме, даже понимая насколько велика вероятность неудачи.
Но ввиду приколов с "неразглашением" и прочих режимных, я предпочитаю другие варианты поспокойнее (да, я нашел выходы на разработку ПО для космоса, и как раз Эрланг и предполагаю там использовать, уж извините подробностей не будет, ибо конкуренция).
ЦитироватьСпрашиваем у них - вы ГОТОВЫ написать ПО для ФГ так, как вы считает правильным, считая, что вознаграждение вас достойно, а не трендеть ? ... Если мне скажут судьи кто, и зададут такой же вопрос, то я был бы готов не стушеваться и поучаствовать в проекте, технически. Но организационно - нет.
Насчет разделения технического и организационного участия, не буду врать, не понял. В остальном уверен, что серьезные участники этой ветки ответят положительно. Но какой смысл и польза в этом лакмусировании? В очередной раз потыкать в кого-то пальцем, а себя побить кулаком в грудь?
Гораздо правильнее было бы сформулировать отдельную задачу и решить ее разными методами, сравнить и сделать выводы. И, кстати, для этого не требуется одевать монашеский прикид :)
ЦитироватьЦитироватьVDM тоже чистый функциональный подход
Посмотрел - неа. Есть понятие функций - действительно, без побочных эффектов, и есть понятие операций - как раз императивная часть.
Вообще-то в Эрланге функция тоже может отправлять и принимать сообщения, и даже может через встроенную API работать с встроенной в ВМ СУБД, и таким образом получать побочные эффекты из внешнего мира, но это не делает его императивным.
ЦитироватьГораздо правильнее было бы сформулировать отдельную задачу и решить ее разными методами, сравнить и сделать выводы. И, кстати, для этого не требуется одевать монашеский прикид :)
Это что-то из области Цветочного города, тратить время и ресурсы на изучение процесса выбора. Про организационно я уже раньше писал, это реально большая проблема, которая в конечном счете может отвратить многих, даже не принимая в расчет денежную сторону. Что толку, если команда хорошо все знает и умеет, но у нас часто вынуждена быть направляемой каким-нибудь неповоротливым умом выше по инстанции ? Вот я не уверен, что заложенное отсутствие связи на опорной орбите - чисто техническое решение. Наверняка организационные добавились.
ЦитироватьЦитироватьЦиклограммы убрать в космической отрасли?
Вы сами понимаете, что пишете?
Этой фразой я... о бесполезности и вреде многозадачности и ассинхронности в космической отрасли... весь этот супер вредный ансамбль целенаправленно используется в NASA и сыграл свою роль не в одной успешной миссии. Неужели мы такие умные, а они полные идиоты и не видят этой серьезной проблемы?
Не путайте мух и котлеты. Многозадачность умные люди в отрасли и у нас не отвергают, см. в частности цитату приведенную мною, из книги Д.И. Козлова, А.Н. Аншакова, А.В. Соллогуба и Я.А. Мостового.
А вот циклограммы - вещь основополагающая, и в НАСА от них никуда не ушли, естественно.
Умные мужики в НАСА, ясное дело. Жаль, не все найти и прочесть удается, что делают.
Цитироватьесли на Си можно разработать решение с требуемой надежностью, то в чем проблема?
наверное, проблема в возможности достичь этого же решения с меньшими затратами используя другой язык
Цитироватьтот же SPIN (вычитал, что использовался для тестирования как минимум ПО модуля обработки/передачи изображений)
Блин, а вот 22 страницы увидел - и все... Не подкинете материальчик полностью?
ЦитироватьПо отдельным факторам Си будет бесспорно проигрывать. Но в стройной методологии разработки он может быть и не самым плохим выбором
Полностью согласен. Например, если программа на Си полностью автоматически генерируется заведомо корректным генератором.
Цитироватьнаверное, проблема в возможности достичь этого же решения с меньшими затратами используя другой язык
Ну так вот же, умные парни из NASA (сто процентов проанализировав не один возможный вариант), пришли к выводу, что на Си им это будет сделать более эффективно. И как я уже предположил, дело должно быть не столько в самом языке, сколько в обвязке, в которой он используется.
ЦитироватьБлин, а вот 22 страницы увидел - и все... Не подкинете материальчик полностью?
С удовольствем - вот то, про что я говорил (http://www.google.ru/url?sa=t&rct=j&q=Random+Testing+and+Model+Checking%3A+Building+a+Common+Framework+for+Nondeterministic+Exploration&source=web&cd=1&ved=0CBkQFjAA&url=http%3A%2F%2Frjoshi.org%2Fbio%2Fpapers%2FWODA2008.pdf&ei=TLrSTpT-K4Wf-wak9bDDDg&usg=AFQjCNEULeIi3ZB6pGHR3HQ0iZiLPaKy0w). Предлагается вариант недетерменированного поиска ошибок в пространстве состояний для SPIN-модели на примере модуля MSL.
ЦитироватьПолностью согласен. Например, если программа на Си полностью автоматически генерируется заведомо корректным генератором.
Хитрости не отнять :)
ЦитироватьЧто толку, если команда хорошо все знает и умеет, но у нас часто вынуждена быть направляемой каким-нибудь неповоротливым умом выше по инстанции ? Вот я не уверен, что заложенное отсутствие связи на опорной орбите - чисто техническое решение. Наверняка организационные добавились.
Теперь понял. Тут готовых решений у меня нет - только зависть поддержке частной космической отрасли в США :roll:
ЦитироватьГораздо правильнее было бы сформулировать отдельную задачу и решить ее разными методами, сравнить и сделать выводы. И, кстати, для этого не требуется одевать монашеский прикид :)
Ок. Я предлагаю задачу: эмулятор ракетного двигателя на сжатом газе. Думаю, задача вполне реальная жизненная и пример может быть дополнен до чего-то другого, но в рамках форума нет смысла сильно усложнять.
Можем добавить систему управления эмулируемым двигателем и соответственно эмуляторы датчиков и эмуляторы исполнительных устройств.
Вот тут я уже написал первый простейший код и жду комментариев и вопросов чтобы дорабатывать дальше:
http://www.novosti-kosmonavtiki.ru/phpBB2/viewtopic.php?p=843547#843547
ЦитироватьВот тут я уже написал первый простейший код и жду комментариев и вопросов чтобы дорабатывать дальше:
http://www.novosti-kosmonavtiki.ru/phpBB2/viewtopic.php?p=843547#843547
Я перестал вас воспринимать хоть сколь-нибудь серьезно :) Похоже, надо было делать это раньше :)
ЦитироватьНу так вот же, умные парни из NASA (сто процентов проанализировав не один возможный вариант), пришли к выводу, что на Си им это будет сделать более эффективно. И как я уже предположил, дело должно быть не столько в самом языке, сколько в обвязке, в которой он используется.
Да, дело несомненно в обвязке, точнее в генераторах кода.
В ближайшие дни попытаюсь подробно выяснить чего они использовали, но есть подозрение что функциональщину, подозреваю что даже конкретно Lisp :D , тк на функциональных языках компиляторы компиляторов рядовое явление и Lisp очень любят американские госорганы, ну и плюс какой-то диалект Lisp в AutoCad, следовательно американские конструкторы вероятно с ним знакомы.
ЦитироватьТеперь понял. Тут готовых решений у меня нет - только зависть поддержке частной космической отрасли в США :roll:
США десятилетиями фильтровали умных людей со всего мира, на базе энергичного этноса, отсюда и результат. У них для этого еще работает проект гринкарта, сбор сведений на добровольной основе. А у нас работает проект "возьми гастера - разбавь специалиста". Так что не исключено, что через 20 лет запуск ФГ нам покажется недостижимой фантастикой, надо ловить момент сейчас и наслаждаться.
ЦитироватьСША десятилетиями фильтровали умных людей со всего мира, на базе энергичного этноса, отсюда и результат.
На самом деле даже больше чем десятилетиями.
И дело там не в энергичном этносе а в демократии - сила демократии в том что она позволяет брать лучших умных людей из всех слоев общества и ставить отборных людей на места, где они будут наиболее эффективны, не разбирая торговлю, инженерную деятельность и управление.
- Умных людей не хватает даже в Индии с её миллиардом населения, потому что между умным человеком вообще и умным человеком с наиболее эффективным образованием и на наиболее эффективной должности огромная пропасть, переполненная энергичными дураками.
Когда-то мне приводили хороший пример по теме отбора:
Цитировать- Вопрос: что нужно чтобы страна выигрывала олимпиады?
- Ответ: нужно подготовить десятки тысяч высококлассных тренеров, которые будут с детских лет работать с молодежью в спортшколах и как можно больше людей пропускать через сито отбора.
А конкретно в СССР была проблема, что толковые люди без связей могли пойти только в инженеры, да еще в военные, а высшее руководство было жестко клановое. Поэтому когда давали правильную команду сверху то совершали чудеса.
Плюс США еще выиграли от глобализации, тк по сути международное разделение труда позволило им вывести за пределы страны низкотехнологичные и грязные отрасли, оставив у себя ключевые и высокотехнологичные отрасли и управление, и соответственно им не нужно распылять умных людей на низкоприбыльные и неключевые отрасли.
ЦитироватьПлюс США еще выиграли от глобализации, тк по сути международное разделение труда позволило им вывести за пределы страны низкотехнологичные и грязные отрасли, оставив у себя ключевые и высокотехнологичные отрасли и управление, и соответственно им не нужно распылять умных людей на низкоприбыльные и неключевые отрасли.
Этот "выигрыш" сейчас аукается во всей красе, когда государственный дебет с кредитом не сходится. Сначала вывели низкотехнологичное производство - эффект был колоссален, всем понравилось. Следом было выведено высокотехнологичное. Если сервер SUN 2000-го года был собран в США, то 2002 уже на Тайване. Компенсировалось все это великолепие искусственным вздуванием цен на недвижимость, что позволяло малоквалифицированному населению сводить концы с концами - раз в полгода переоцениваем дом, после чего бодро чешем в банк и тащим оттуда кучу денег. К чему все это привело - видно сейчас - 10% населения страны сидят без работы и без всяких дополнительных источников дохода. Отсюда и демонстрации повсеместные.
ЦитироватьЭтой фразой я обобщал мои предыдущие рассуждения. Тут более "близкие к телу" спецы не раз говорили о бесполезности и вреде многозадачности и ассинхронности в космической отрасли.
На Си как раз достаточно часто используется и многопоточность и многозадачность, как кооперативная так и вытесняющая.
ЦитироватьНельзя так категорично. Скажем так, если на Си можно разработать решение с требуемой надежностью, то в чем проблема?
Кстати да, существует масса инструментов для Си. Это статические анализаторы кода, рантайм анализаторы и прочее. При грамотной методологии разработки и тестирования можно получить очень надёжных код.
ЦитироватьЦитироватьТут можно ответить известным афоризмом:
"There are only two kinds of programming languages: those people always bitch about and those nobody uses."
А я позволю себе повторить ранее высказанное:
в отрасли применялись и применяются с успехом и другие языки программирования высокого и сверхвысокого уровней, в частности:
- Ада
- Java
Я не вижу большой разницы между Си и этими двумя. Те же яйца.
Цитировать- Модула-2
- HAL/S
- ПРОЛ2
- ГРАФИТ-ФЛОКС
Могу высказать предположение, что и Джовиаль используется/использовался.
Это почти умершие языки "those nobody uses".
ЦитироватьЧестно, я бы рискнул поработать так (писать так как считаю правильным) ОДИН ГОД за еду и за общагу и за галочку в резюме, даже понимая насколько велика вероятность неудачи.
Ну зачем за еду. Считаем. Пусть 30 программистов. з/п 100 тыщ. р.
За 2 года - 72 млн. р. Умножить на 2 (налоги). Итого ~150 млн. р. Сущие крохи по сравнению со стоимостью всего проекта. Теперь вопрос куда уходят деньги в нашей космонавтике.
Цитироватьесть подозрение что функциональщину, подозреваю что даже конкретно Lisp :D , тк на функциональных языках компиляторы компиляторов рядовое явление и Lisp очень любят американские госорганы, ну и плюс какой-то диалект Lisp в AutoCad, следовательно американские конструкторы вероятно с ним знакомы
Хммм..... См. высказывание Unispace выше
ЦитироватьЦитироватьСША десятилетиями фильтровали умных людей со всего мира, на базе энергичного этноса, отсюда и результат
дело там не в энергичном этносе а в демократии - сила демократии в том что она позволяет брать лучших умных людей из всех слоев общества
Глупости.
Главная сила США в:
1) Долларе как мировой валюте.
2) Двенадцати авианосцах и прочем вооружении.
Первая причина позволяет США банально перекупать лучших специалистов со всего света. Впрочем, своих не хватает, все норовят ничего не делать а деньги получать[/size] в юристы пойти.
Знаете шутку: "Американский университет - место, где русские профессора учат китайских студентов"?
Демократия присутствует во многих странах мира - однако же, успехов в науке и технологии подобных нет.
По поводу "социальных лифтов". Как раз в СССР они действительно работали. Сын доярки вполне мог стать и академиком, и членом Политбюро.
При капитализме ("демократии") все как раз иначе. Понятие "застойная бедность" слышали?
ЦитироватьЦитировать- Ада
- Java
Я не вижу большой разницы между Си и этими двумя. Те же яйца
Ну, все же. Java провозглашалась как "безопасный" язык.
Ада - вообще серьезно отличается.
ЦитироватьЦитировать- Модула-2
- HAL/S
- ПРОЛ2
- ГРАФИТ-ФЛОКС
Могу высказать предположение, что и Джовиаль используется/использовался
Это почти умершие языки "those nobody uses".
Ну, ГРАФИТ-ФЛОКС используется в настоящее время вроде как НПЦ АП им. Пилюгина.
Модула-2 используется в настоящее время в ОАО ИСС.
HAL/S использовался на протяжении 30 лет.
Джовиаль - почти уверен, что используется.
ЦитироватьПо поводу "социальных лифтов". Как раз в СССР они действительно работали. Сын доярки вполне мог стать и академиком, и членом Политбюро.
При капитализме ("демократии") все как раз иначе. Понятие "застойная бедность" слышали?
Академиком или членом стать мог. Но всё равно остался бы нищим по сравнению с капитализмом.
И шансов реализовать своё хобби как Маск - не имел бы. Потому как из государства деньги выбить на то что хочется не получится...
ЦитироватьМодула-2 используется в настоящее время в ОАО ИСС
Да, тут пробегала ссылка на то, как они изобретали велосипед - кросс-платформу на модуле-2. У меня сразу возник вопрос, зачем? Пишут, что добились типизации, модульности, раздельной компиляции, кросс-платформенности. Внимание вопрос: про GNU С++ там никто не слышал вообще? Ведь это все уже есть и
очень давно.
ЦитироватьЦитироватьПо поводу "социальных лифтов". Как раз в СССР они действительно работали. Сын доярки вполне мог стать и академиком, и членом Политбюро.
При капитализме ("демократии") все как раз иначе. Понятие "застойная бедность" слышали?
Академиком или членом стать мог. Но всё равно остался бы нищим по сравнению с капитализмом
Нищих как раз при развитом социализме не было. А при капитализме - сколько хочешь. Зачем вообще становиться миллионером нормальному человеку? Есть достойное качество жизни, уверенность в будущем своем и своих детей - зачем стремиться к миллиардам?
ЦитироватьИ шансов реализовать своё хобби как Маск - не имел бы
Вообще, зачем "как Маск"? В Советском Союзе существовали свои пути, как раз множество НИИ функционировали. Даже поговорка была об "удовлетворении своего любопытства за государственный счет", помните?
ЦитироватьЦитироватьМодула-2 используется в настоящее время в ОАО ИСС
Да, тут пробегала ссылка на то, как они изобретали велосипед - кросс-платформу на модуле-2. У меня сразу возник вопрос, зачем? Пишут, что добились типизации, модульности, раздельной компиляции, кросс-платформенности. Внимание вопрос: про GNU С++ там никто не слышал вообще? Ведь это все уже есть и очень давно
Что именно непонятно?
Модула-2 - язык значительно более "строгий" нежели С/С++. Многие ошибки в Модуле-2 просто невозможны.
Модульности в смысле Модулы-2 в С/С++ нет.
ЦитироватьМодула-2 - язык значительно более "строгий" нежели С/С++. Многие ошибки в Модуле-2 просто невозможны.
Я очень часто сталкиваюсь с попытками найти и использовать языковые средства, чтобы защитить себя от собственных глупостей. Не проще ли их просто не делать? Еще раз повторю одну важную мысль, которую я тут озвучивал. Дополнительные средства, по сути, есть "защита от дурака" и они, все равно, не спасают от всех проблем. Для устранения последних приходится использовать другие средства (простейший пример - peer review). Но эти средства в комплексе перекрывают и оплошности, которые можно случайно сделать без "защиты от дурака". Поэтому сама такая защита особой ценности не имеет.
ЦитироватьМодульности в смысле Модулы-2 в С/С++ нет.
Да есть, куда же она делась. В С++ объявления существуют отдельно от определений - аналог definition/implementation module в Модуле-2. Механизм импорта/экспорта с альясингом идентификаторов Модулы-2 реализуется в С++ посредством пространств имен. Я даже думаю, что последние вошли в С++ благодаря Модуле-2, но лень разгребать старые книжные завалы, чтобы подтвердить. Но помимо этого в С++ есть такая штука как абстрактные интерфейсы - они вообще поднимают модульность на качественно новый уровень.
ЦитироватьЯ очень часто сталкиваюсь с попытками найти и использовать языковые средства, чтобы защитить себя от собственных глупостей. Не проще ли их просто не делать?
Не проще. Все глупости делаются в цейтноте, когда все средства хороши, лишь бы успеть к сроку. Но даже если вы персонально аккуратно обходите скользкие места, то как вы убережетесь от глупостей очередного нового гения, пришедшего в команду? Собственно тут зарыта одна из главных проблем С++. Он очень обширен, поддерживает множество подходов и далеко не все из них безопасны. Это жуткий гибрид. Собственно это было одной из главный причин популярности Java как промышленного языка. С намного чище С++ концептуально. В этом смысле оно проще и безопаснее. Хотя приложения реального времени все еще ждут своих Кернигана и Ритчи. :D
Цитироватьсама такая защита особой ценности не имеет
А "не особую" имеет?
ЦитироватьЦитироватьМодульности в смысле Модулы-2 в С/С++ нет.
Да есть... думаю, что последние вошли в С++ благодаря Модуле-2
Ладно, уговорили 8) Впрочем, остальные недостатки С++ никуда не делись, о них неплохо написал Not.
ЦитироватьНу, все же. Java провозглашалась как "безопасный" язык.
Ада - вообще серьезно отличается.
Дело не безопасности а в выразительной силе языка. Код на Ява и Си не особо сильно различаются по выразительности. Поэтому вероятность логических ошибок примерно одинакова
Ада помоему сейчас не особо актуальна, ибо слишком формализована и не снижает вероятность логических ошибок.
Си также не имеет альтернативы если надо активно управлять и взаимодействовать с железом. А для очень высокоуровневых вещей можно создать спец. DSL с кодогенератором в Си. Классический пример это генератор парсеров YACC.
Цитироватьто как вы убережетесь от глупостей очередного нового гения, пришедшего в команду? Собственно тут зарыта одна из главных проблем С++. Он очень обширен, поддерживает множество подходов и далеко не все из них безопасны. Это жуткий гибрид.
Тем не менее для низкоуровневых вещей альтернативы С/С++ сейчас нет и не предвидется. Все конкуренты требуют нетривиального рантайма и виртуальной машины, что автоматически исключает их из рассмотения.
ЦитироватьА "не особую" имеет?
Имеет, но настолько "не особую", что надо внимательно смотреть на сопутствующие ей жертвы.
ЦитироватьАда помоему сейчас не особо актуальна, ибо слишком формализована и не снижает вероятность логических ошибок.
Я думаю Ада была очень популярна в свое время по причине того, что существовали компиляторы с доказанной корректностью. Но ограничения и постоянно возврастающие требования к сложности систем, судя по всему, победили. Да и не исключаю, что "корректные" компиляторы с Си тоже уже имеются. Как минимум помню, что были попытки по их созданию. Вполне возможно, что это еще одна из причин, почему для MSL использовался Си.
ЦитироватьНе проще. Все глупости делаются в цейтноте, когда все средства хороши, лишь бы успеть к сроку.
Ну цейтнот - это вообще отдельная песня. Но интересно, есть ли у кого-то жизненный сравнительный опыт по спасению/утоплению проекта в цейтноте за счет языка реализации?
ЦитироватьНо даже если вы персонально аккуратно обходите скользкие места, то как вы убережетесь от глупостей очередного нового гения, пришедшего в команду?
Я спасаюсь, добиваясь сто процентного покрытия кода при тестировании. Это гарантирует отсутствие фатальных глупостей от таких гениев. Не фатальные глупости в большинстве своем отфильтровывают тим-лиды в процессе контроля ревизий. А то, что все-таки просачивается, вреда не приносит и вычищается со временем.
ЦитироватьСобственно тут зарыта одна из главных проблем С++. Он очень обширен, поддерживает множество подходов и далеко не все из них безопасны.
Ну что ж, может у меня какое-то неполное представление о безопасности.
ЦитироватьСобственно это было одной из главный причин популярности Java как промышленного языка. С намного чище С++ концептуально. В этом смысле оно проще и безопаснее. Хотя приложения реального времени все еще ждут своих Кернигана и Ритчи. :D
Мне почему-то кажется, что Java купила обещаниями кросс-платформенности. Может купили еще кажущейся легкостью (ООП в крови, обширная стандартная библиотека, сборка мусора). В том виде в котором она была до появления генериков, это вообще была смешная система - все стандартные алгоритмы работали только с одним типом (базовым классом) и требовали небезопасного явного приведения результатов на выходе. Вот уж где был реальный простор для глупостей, тем более, что они провоцировались самой платформой.
ЦитироватьНу цейтнот - это вообще отдельная песня. Но интересно, есть ли у кого-то жизненный сравнительный опыт по спасению/утоплению проекта в цейтноте за счет языка реализации?
Есть. Свежий отварной говяжий и свиной язык, реализованный с хреном, горчичкой и прочими радостями, спасал в нашей стране не один проект на госиспытаниях, или этапе сдачи :)
:lol: :lol: :lol:
ЦитироватьНищих как раз при развитом социализме не было. А при капитализме - сколько хочешь.
В СССР было огромное количество бомжей и нищих тоже хватало. Просто некоторые вроде вас их принципиально старались не замечать, а например милиция очень активно их использовала, и даже буквально тряслась за них, тк бомжи очень удобны чтобы в конце месяца ими закрывать план по поимке пьяных на улице.
Вообще бомжи есть в любой стране, даже в Японии.
И дело тут СОВСЕМ не в уровне доходов, а в том что есть такие люди, которые в душе бродяги и им это нравится и не всегда системе образования удается привить таким людям привычки заставляющие их жить как остальные люди. В бомжи попадают даже люди вполне состоявшиеся, имеющие нормальную семью. Мне мой родственник рассказывал историю которую он видел сам - еще в 1980-х в СССР один вполне адекватный мужик, имевший семью, квартиру, работу и детей вдруг захотел жить в канализации и его оттуда так никакими методами вытащить и не смогли.
Собственно в Японии к бомжам относятся не как к падшим и нездоровым, а считают их чем-то вроде юродивых - особенных людей с очень отличным от обычного взглядом на жизнь.
ЦитироватьЗачем вообще становиться миллионером нормальному человеку? Есть достойное качество жизни, уверенность в будущем своем и своих детей - зачем стремиться к миллиардам?
А зачем жить? Зачем работать? - Можно ведь бомжевать :?
Вы пытаетесь всех людей равнять по своему пониманию, а люди все разные.
Во вторых, если вы не понимаете смысла миллионов, это не ввиду того что миллионы плохие или бессмысленные, а ввиду ВАШЕЙ ограниченности.
Например, имей вы миллион, вам ведь не обязательно на него молиться - вы можете взять этот миллион и вложить его в ваши любимые графические средства разработки ПО.
Мне просто стыдно, что я вынужден вам тут рассказывать азы Карла Маркса.
ЦитироватьЦитироватьИ шансов реализовать своё хобби как Маск - не имел бы
Вообще, зачем "как Маск"? В Советском Союзе существовали свои пути, как раз множество НИИ функционировали. Даже поговорка была об "удовлетворении своего любопытства за государственный счет", помните?
Эти советские пути мерзкий и противный для нормального человека вариант исполнения мечты.
И да, часть людей идут на такое. Но нормальный и естественный путь как раз каким-то образом накопить излишки (то-ли самому заработать, то-ли в наследство получить, то-ли кредит взять) и затем эти излишки вложить в исполнение своей мечты.
И вот мерзостность социализма как раз в том что он запрещает естественный путь а предлагает неестественный - встраиваться в государство и использовать ресурсы государства.
Кроме того государственный путь плох еще тем что все ресурсы запускаются через один узел и если этот узел плохо работает, то вот это самое "удовлетворение любопытства за гос счет" становится неэффективным.
В капитализме КАЖДЫЙ может инвестировать свои излишки в чужую идею, а все неэффективными быть не могут, поэтому обязательно что-то получится.
ЦитироватьЦитироватьНе проще. Все глупости делаются в цейтноте, когда все средства хороши, лишь бы успеть к сроку.
Ну цейтнот - это вообще отдельная песня. Но интересно, есть ли у кого-то жизненный сравнительный опыт по спасению/утоплению проекта в цейтноте за счет языка реализации?
Функциональные лучше работают в цейтноте. Как раз ввиду отсутствия хранения состояния.
ЦитироватьЦитироватьСобственно это было одной из главный причин популярности Java как промышленного языка. С намного чище С++ концептуально. В этом смысле оно проще и безопаснее. Хотя приложения реального времени все еще ждут своих Кернигана и Ритчи. :D
Мне почему-то кажется, что Java купила обещаниями кросс-платформенности.
Я тоже раньше думал что сила Java в кроссплатформенности, а сейчас убедился что Java выиграла за счет получения заметных плюсов (сборщик мусора и ООП) при минимальном отличии синтаксиса от Си. Фактически у программистов владевших Си появился выбор - либо довольно сложный и громоздкий С++ либо Java, и для большинства Java оказалась проще в использовании.
Реально кроме сборщика мусора больше никаких преимуществ для надежных систем Java не дает, ну правда есть еще Enterprise Java Beans, но то совсем отдельная история - именно как тут говорили надежность за счет специфики библиотек и рантайма.
ЦитироватьВ СССР было огромное количество бомжей и нищих тоже хватало.
zyxman, Вы несете полную чушь
ЦитироватьМне мой родственник рассказывал историю которую он видел сам - еще в 1980-х в СССР один вполне адекватный мужик, имевший семью, квартиру, работу и детей вдруг захотел жить в канализации и его оттуда так никакими методами вытащить и не смогли.
Мне знакомый рассказывал, что в США таких случаев множество
ЦитироватьЦитироватьМодула-2 - язык значительно более "строгий" нежели С/С++. Многие ошибки в Модуле-2 просто невозможны.
Я очень часто сталкиваюсь с попытками найти и использовать языковые средства, чтобы защитить себя от собственных глупостей. Не проще ли их просто не делать? Еще раз повторю одну важную мысль, которую я тут озвучивал. Дополнительные средства, по сути, есть "защита от дурака" и они, все равно, не спасают от всех проблем. Для устранения последних приходится использовать другие средства (простейший пример - peer review). Но эти средства в комплексе перекрывают и оплошности, которые можно случайно сделать без "защиты от дурака". Поэтому сама такая защита особой ценности не имеет.
Ценность защиты зависит от способа реализации.
Когда защита реализуется через запреты и усложнения как это сделано в Модуле и в Аде, это одно, а когда защита реализуется через альтернативный, более удобно читаемый и более элегантный способ решения сложных задач (подход Эрланга) это СОВСЕМ другое.
Тут действительно стоит посмотреть примеры кода и сразу многие вопросы отпадут.
ЦитироватьЭти советские пути мерзкий и противный для нормального человека вариант исполнения мечты.
Мерзкий дебил это вы. Посмотрите на youtube популярный сейчас клип "Наш дурдом голосует за Путина". Ничего близкого во времена СССР не было. Это я про видеоряд, даже не про подтекст
ЦитироватьЦитироватьНе проще. Все глупости делаются в цейтноте, когда все средства хороши, лишь бы успеть к сроку.
Ну цейтнот - это вообще отдельная песня. Но интересно, есть ли у кого-то жизненный сравнительный опыт по спасению/утоплению проекта в цейтноте за счет языка реализации?
С++ очень приятен как для спасения, так и для утопления "горящего" проекта. Один хитрый хак и вуаля! Проблема однако в том, что никто не гарантирует что будет после этого самого "вуаля" Обычно в таким местах приличные люди пишут пространный комментарий: дескать это хак, он временный, и т.д., и живет этот хак долго и счастливо, пока какой нибудь неучтенный в спешке момент не обрушивает все с треском и пламенем. Языки более строгие предоставляют меньше возможностей, и тут больший акцент лежит на архитектуре. Если она предполагает предлагаемое решение, то путем аврала, штурма, решение находится. Если нет - то или проект усекается, или откладывается, что лучше запуска непроверенного и сколькзкого хака.
ЦитироватьРеально кроме сборщика мусора больше никаких преимуществ для надежных систем Java не дает, ну правда есть еще Enterprise Java Beans, но то совсем отдельная история - именно как тут говорили надежность за счет специфики библиотек и рантайма.
Java мало что дает для надежных систем, вследствие недетерминизма виртуальной машины и того же сборщика мусора. Java позволяет строить системы высокой доступности, но к надежности это имеет опосредованное отношение.
ЦитироватьЦитироватьу НАСА... у нас...
Простите за личный вопрос, Вы работаете в НАСА?
ЦитироватьПО Mars Science Laboratory написано на С, содержит 2.5 миллиона строк кода и исполняет порядка 130 конкурентных процессов
Это который запускают сейчас? А откуда дровишки? не поделитесь?
По поводу Си же можно лишь пожалеть.
Там команда порядка 30 разработчиков и 10 тестеров, плюс на них работает лаборатория надежности ПО (NASA) Почитать можно например в докладе сделанном по системе LogScope, в Гренобле, на конфе по методам runtime верификации, в 2009 году:
http://books.google.com/books?id=A_IBWF69WjMC&pg=PA16&lpg=PA16#v=onepage&q&f=false
ЦитироватьЦитироватьто как вы убережетесь от глупостей очередного нового гения, пришедшего в команду? Собственно тут зарыта одна из главных проблем С++. Он очень обширен, поддерживает множество подходов и далеко не все из них безопасны. Это жуткий гибрид.
Тем не менее для низкоуровневых вещей альтернативы С/С++ сейчас нет и не предвидется. Все конкуренты требуют нетривиального рантайма и виртуальной машины, что автоматически исключает их из рассмотения.
В этом проблема. С одной стороны язык должен быть со строгой типизацей (более строгой чем в модуле) и средствами формальной верификации правильности программ чтобы гарантированно отлавливать те баги, которые компилятор может отловить автоматически. С другой стороны он должен быть достаточно низкого уровня, чтобы можно было представлять сгенеренный код (не опускаясь тем не менее до ручного кодирования отдельных команд) и не включать непрозрачных (с точки зрения генерируемого кода и подробностей функционирования), опасных и ненужных для высоконадежных embedded/real-time систем примочек, типа динамического распределения памяти, не говоря уж о встроенной сборке мусора.
Языка, который в полной мере отвечал бы требованиям этой области нет. Из существующего и широкораспространенного Модула-2 пожалуй не самый плохой вариант. Или "С" - похуже модулы с точки зрения надежности, но зато ближе к железу. А в идеале, конечно, нужен специальный язык.
Да уже обсудили пару страниц назад. Но интересно было бы узнать, что именно из разработок лабаратории надежности ПО применялось в работе над MSL.
ЦитироватьДа уже обсудили пару страниц назад. Но интересно было бы узнать, что именно из разработок лабаратории надежности ПО применялось в работе над MSL.
http://books.google.com/books?id=A_IBWF69WjMC&pg=PA16&lpg=PA16#v=onepage&q&f=false
Ну здравствуйте, там как раз написано, что в виду суровой загрузки программистов невозможно было применить средства требующие инъекций доп кода. Поэтому кому-то и дали добро на побаловаться LogScope'ом. А к нему у меня очень скептическое отношение. Сами авторы пишут, что спецификации в основном пришлось высасывать из пальца, да кое-где местами удалось автоматизировать этот процесс. Хотя нашли пару ошибок - похвально.
Я имел в виду более серьезные продукты лаборатории надежности.
ЦитироватьНу здравствуйте, там как раз написано, что в виду суровой загрузки программистов невозможно было применить средства требующие инъекций доп кода. Поэтому кому-то и дали добро на побаловаться LogScope'ом. А к нему у меня очень скептическое отношение. Сами авторы пишут, что спецификации в основном пришлось высасывать из пальца, да кое-где местами удалось автоматизировать этот процесс. Хотя нашли пару ошибок - похвально.
Я имел в виду более серьезные продукты лаборатории надежности.
Ну про палец вы сами сочинили, для красного словца. И вообще, я сомневаюсь что вы хоть что-то прочли и поняли, из указанного текста.
Там было сказано, что разработчики заняты своей основной работой и у них нет времени писать спецификации. Однако это не означает, что инъекции кода невозможны - этим в полуавтоматическом режиме занимаются инженеры лаборатории надежности, применяя соотвествующие средства. Это во-первых. Во-вторых, учитывая сильную привязку к железу, выписать реальные темпоральные ограничения достаточно сложно и они решили применить метод анализа диагностических файлов, благо они формируются системно, без пропусков. И отсюда весь дальнейший танец, а именно динамический анализ, в комбинации со статическим из аннотаций.
На скептическое же отношение вы безусловно имеет право, благо это ничего не меняет в реальности :D
ЦитироватьДело не безопасности...
ну-ну. спор можно с вами на этом заканчивать
ЦитироватьЯва и Си не особо сильно различаются по выразительности. Поэтому вероятность логических ошибок примерно одинакова
почитайте литературу
ЦитироватьАда помоему сейчас не особо актуальна
Ада успешно используется в настоящее время. Насколько я понимаю, кроме прочего - при написании ПО МКС.
Цитироватьдля очень высокоуровневых вещей можно создать спец. DSL с кодогенератором в Си
А можно - проблемно-ориентированный язык с прямой генерацией машинного кода 8) БЦВМ. Без промежуточной стадии.
ЦитироватьЯ спасаюсь, добиваясь сто процентного покрытия кода при тестировании. Это гарантирует...
1. Это невозможно. Покрытия кстати по какому из критериев? Покрытия операторов? Условий? Путей?
Для космического же аппарата, взаимодействующего в реальном времени с аппаратурой, протестировать все ситуации невозможно абсолютно.
2. Не гарантирует покрытие кода ничего...
ЦитироватьНу про палец вы сами сочинили, для красного словца. И вообще, я сомневаюсь что вы хоть что-то прочли и поняли, из указанного текста.
Спасибо за высокую оценку моих познавательных способностей :)
Цитироватьspecification learning
- writing specs is time consuming
- often hard to come up with properties
- one approach is to use already generated log files to "get ideas"
- in the extreme case, specifications can be automatically generated from log files
Источник - Monitoring the Execution of Space Craft Flight Software, JPL (http://www.google.ru/url?sa=t&rct=j&q=Monitoring+the+Execution+of+Space+Craft+Flight+Software&source=web&cd=1&ved=0CDMQFjAA&url=http%3A%2F%2Fcompass.informatik.rwth-aachen.de%2Fws-slides%2Fhavelund.pdf&ei=Z43UTo_WB9CGhQeropFM&usg=AFQjCNE8GYiG5PL9pZSz9BoBIz7cqT61PQ)
Моя вина лишь в том, что я более глубоко подошел к изучению данного вопроса, перелопатив и другие публикации. В итоге думал, что это тоже было в обсуждаемом документе. Ну тут уж простите меня - в 3:30 по Москве у меня дома тоже 3:30 :shock:
ЦитироватьТам было сказано, что разработчики заняты своей основной работой и у них нет времени писать спецификации. Однако это не означает, что инъекции кода невозможны - этим в полуавтоматическом режиме занимаются инженеры лаборатории надежности, применяя соотвествующие средства. Это во-первых.
Давайте не будем фантазировать. Из документа, от которого плясали:
ЦитироватьTesting is complicated by the fact that the programming team has little time for activities not related to development of new software, and hence cannot be disturbed too much by a testing effor. This prevents for example an approach based on new test-specific code instrumentation, be it automated or not.
Выделил, чтобы вам было легче разобраться. Про отсутствие времени на спецификации - это ваши фантазии. Не стоит так обобщать "testing effort", тем более, что следующей фразой дается конкретное пояснение.
ЦитироватьНа скептическое же отношение вы безусловно имеет право, благо это ничего не меняет в реальности :D
Ну и на этом спасибо. Думаю очевидно, что мой скептицизм не безосновательный - обратите внимание на case study в документе, на который я сослался в начале.
ЦитироватьВ СССР было огромное количество бомжей
Ложь №1. Были возможно - как единичные исключения.
Цитироватьи нищих тоже хватало
Ложь №2. Нищета была редким, исключительным явлением при развитом социализме.
Цитироватьбомжи есть в любой стране, даже в Японии.
И дело тут СОВСЕМ не в уровне доходов
ну-ну. и нищим нравится бедствовать
ЦитироватьЦитироватьЗачем вообще становиться миллионером нормальному человеку? Есть достойное качество жизни, уверенность в будущем своем и своих детей - зачем стремиться к миллиардам?
А зачем жить? Зачем работать? - Можно ведь бомжевать :?
Я на вопрос о смысле жизни спокойно отвечу - затем, чтобы людям пользу приносить, например.
Или - искать ИСТИНУ. Заниматься наукой.
Или создавать нечто новое.
Или - полететь на Марс.
А жить ради миллионов рублей или долларов - извините, мелко. Впрочем, все люди разные, действительно. Вы пытаетесь всех людей равнять по своему пониманию. Мне просто противно общаться, честно говоря, с людьми вашего уровня понимания этих вопросов.
Цитироватьсоветские пути мерзкий и противный для нормального человека вариант исполнения мечты
как раз безудержное стремление к деньгам, огромным деньгам - болезнь. Богопротивный, мерзкий и противный для нормального человека вариант мечты. Впрочем, некогда кое-где молились золотому тельцу.
Цитировать1. Это невозможно. Покрытия кстати по какому из критериев? Покрытия операторов? Условий? Путей?
Возможно. По всем указанным критериям.
ЦитироватьДля космического же аппарата, взаимодействующего в реальном времени с аппаратурой, протестировать все ситуации невозможно абсолютно.
Если имеются в виду все возможные комбинации значений переменных состояния системы, то конечно не возможно. Но этого и не требуется.
Цитировать2. Не гарантирует покрытие кода ничего...
Гарантирует, что
весь код работает именно так, как было задумано при его написании. Без сюрпризов и глупостей.
ЦитироватьJava мало что дает для надежных систем
По крайней мере по сравнению с Си меньше возможностей залезть по произвольному адресу в память и что-нибудь испортить.
ЦитироватьЦитировать1. Это невозможно. Покрытия кстати по какому из критериев? Покрытия операторов? Условий? Путей?
Возможно. По всем указанным критериям
По всем ПУТЯМ вы покрываете программы? Настоящие? Из многих сотен тыщ строк? Простите, не верю.
ЦитироватьЦитировать2. Не гарантирует покрытие кода ничего...
Гарантирует, что весь код работает именно так, как было задумано при его написании. Без сюрпризов и глупостей
Не гарантирует.
ЦитироватьЦитироватьЦитировать1. Это невозможно. Покрытия кстати по какому из критериев? Покрытия операторов? Условий? Путей?
Возможно. По всем указанным критериям
По всем ПУТЯМ вы покрываете программы? Настоящие? Из многих сотен тыщ строк? Простите, не верю.
ЦитироватьЦитировать2. Не гарантирует покрытие кода ничего...
Гарантирует, что весь код работает именно так, как было задумано при его написании. Без сюрпризов и глупостей
Не гарантирует.
Это вероятно наш Юниспейс с его "аккуратным" программированием. :D
bs, помните историю про ходжу Насреддина, падишаха, шахматную доску и зернышки риса? :D
ЦитироватьПо всем ПУТЯМ вы покрываете программы? Настоящие? Из многих сотен тыщ строк? Простите, не верю.
Да, вот такой я кудесник. Впрочем не я один.
ЦитироватьЦитироватьГарантирует, что весь код работает именно так, как было задумано при его написании. Без сюрпризов и глупостей
Не гарантирует.
Вы сейчас рассуждаете в срезе некоего асбтрактного "покрытия"? Я же его использовал в сочетании с тестированием. Представьте себе такой план тестирования, который заставляет отработать каждый линейный (детерминированный) участок кода минимум один раз и зафиксировать ожидаемый результат.
Цитироватьна них работает лаборатория надежности ПО (NASA) Почитать можно например в докладе сделанном по системе LogScope, в Гренобле, на конфе по методам runtime верификации, в 2009 году:
http://books.google.com/books?id=A_IBWF69WjMC&pg=PA16&lpg=PA16#v=onepage&q&f=false
Спасибо, Not!
ЦитироватьЭто вероятно наш Юниспейс с его "аккуратным" программированием. :D
Ага, "обидеть художника может каждый" :)
Цитироватьbs, помните историю про ходжу Насреддина, падишаха, шахматную доску и зернышки риса? :D
Увы не могу - тяжелое детство, знаете ли. Вместо сказок штудировал мануалы по БЭСМ.
P.S. Пардон, кажется из уроков математики про геометрическую прогрессию припоминаю. Тонко :lol:
ЦитироватьЦитироватьЭто вероятно наш Юниспейс с его "аккуратным" программированием. :D
Ага, "обидеть художника может каждый" :)
Цитироватьbs, помните историю про ходжу Насреддина, падишаха, шахматную доску и зернышки риса? :D
Увы не могу - тяжелое детство, знаете ли. Вместо сказок штудировал мануалы по БЭСМ.
не знаю что вы там штудировали, но занятия по дискретной математике вы явно прогуливали. Иначе были бы в курсе комбинаторной сложности переборных задач. :wink: Вас подводят апломб и здравый смысл. Но с точки зрения здравого смысла Солнце вращается вокруг Земли :D
ЦитироватьЦитироватьПо всем ПУТЯМ вы покрываете программы? Настоящие? Из многих сотен тыщ строк? Простите, не верю.
Да, вот такой я кудесник. Впрочем не я один...
Представьте себе такой план тестирования, который заставляет отработать каждый линейный (детерминированный) участок кода минимум один раз и зафиксировать ожидаемый результат.
Если каждый линейный участок - это первый критерий, покрытие операторов. Ничего особенного он не гарантирует.
Покрытие маршрутов (путей) подразумевает, что вы тестируете набором, в котором предусматривается проход по всем возможным комбинациям условий в программе. .
К сожалению :( (попробую найти литературу) и это не гарантирует отсутствия ошибок.
Цитироватьне знаю что вы там штудировали, но занятия по дискретной математике вы явно прогуливали. Иначе были бы в курсе комбинаторной сложности переборных задач. :wink: Вас подводят апломб и здравый смысл. Но с точки зрения здравого смысла Солнце вращается вокруг Земли :D
Выходит проблема тех, кто не прогуливал дискретку в том, что теперь за ее деревьями они не видят леса? :twisted:
ЦитироватьЕсли каждый линейный участок - это первый критерий, покрытие операторов. Ничего особенного он не гарантирует.
Покрытие маршрутов (путей) подразумевает, что вы тестируете набором, в котором предусматривается проход по всем возможным комбинациям условий в программе. .
Ох, ну сложно же пробивать устоявшиеся взгляды. Помогите мне хоть слегка - расслабьтесь :)
Чтобы покрыть все линейные участки, разумеется необходимо обеспечить проход по комбинациям условий в программе.
ЦитироватьК сожалению :( (попробую найти литературу) и это не гарантирует отсутствия ошибок.
Не тратьте времени - отсутствие ошибок не гарантирует ни что. Я уже объяснял, о какой гарантии разговор.
ЦитироватьПокрытие маршрутов (путей) подразумевает, что вы тестируете набором, в котором предусматривается проход по всем возможным комбинациям условий в программе. .
К сожалению :( (попробую найти литературу) и это не гарантирует отсутствия ошибок.
Не нужно ничего искать, достаточно слегка напрячь мозги. Эта задача из класса неразрешимых, поскольку 1) не известны входные данные (они могут широко варьироваться на вещественных интервалах) и 2) даже если бы множество всех комбинаций аргументов было счетно и сравнительно невелико, количество комбинаций и перестановок на всех условных операторах программы определяется как экспонента от их количества. А ведь еще есть переменные, циклы с недетерминированным количеством итераций и т.д. и т.п.
ЦитироватьВыходит проблема тех, кто не прогуливал дискретку в том, что теперь за ее деревьями они не видят леса? :twisted:
Ваша проблема в том, что вы отлично владеете художественным словом и поисковыми системами, но абсолютно не умеете думать, во всяком случае на том уровне, который требуется для понимания программирования надежных систем.
ЦитироватьЦитироватьВ СССР было огромное количество бомжей
Ложь №1. Были возможно - как единичные исключения.
Бомжей в СССР было достаточно, чтобы ими милиция закрывала план по мелким правонарушениям.
Я это знаю не из газет/журналов, а от людей, которые работали в милиции.
ЦитироватьЦитироватьи нищих тоже хватало
Ложь №2. Нищета была редким, исключительным явлением при развитом социализме.
А когда был этот ваш развитой социализм? - Я достаточно хорошо помню жизнь с года примерно 1982, и очень хорошо помню вереницы нищенствующих на кладбищах и возле церквей.
И где-то тогда-же я познакомился с цыганами.
ЦитироватьЦитироватьбомжи есть в любой стране, даже в Японии.
И дело тут СОВСЕМ не в уровне доходов
ну-ну. и нищим нравится бедствовать
Это вы считаете что они бедствуют.
Вообще вы напоминаете янки из классики, которые не понимают никакого другого способа жизни кроме ихнего.
А на самом деле есть много других способов жизни, а не только классическая цивилизация, например Чукчи - они еще и сейчас пытаются жить как жили их предки, а при СССР их пытались заставить жить как цивилизация, буквально забирали детей из семей и увозили за тысячи километров в интернаты. Так эти дети сбегали из сытости и цивилизации интернатов, чтобы пройдя пешком эти тысячи километров жить традиционным укладом.
Еще есть дауншифтеры, есть Амиши и многие другие альтернативы, и бомжевание судя по классике вполне традиционная форма существования - вспомните Тома Сойера.
ЦитироватьЦитироватьЦитироватьЗачем вообще становиться миллионером нормальному человеку? Есть достойное качество жизни, уверенность в будущем своем и своих детей - зачем стремиться к миллиардам?
А зачем жить? Зачем работать? - Можно ведь бомжевать :?
Я на вопрос о смысле жизни спокойно отвечу - затем, чтобы людям пользу приносить, например.
Или - искать ИСТИНУ. Заниматься наукой.
Или создавать нечто новое.
Или - полететь на Марс.
А жить ради миллионов рублей или долларов - извините, мелко. Впрочем, все люди разные, действительно. Вы пытаетесь всех людей равнять по своему пониманию. Мне просто противно общаться, честно говоря, с людьми вашего уровня понимания этих вопросов.
Вы именно что мелкий ограниченный человек.
Ибо я уже вам тут говорил, что не обязательно зарабатывать миллионы чтобы на них молиться.
В НОРМАЛЬНОЙ стране вы можете на эти деньги например построить мост, или школу, или фабрику, или еще что-то полезное, и так во многих случаях и происходит.
И собственно богатство западной цивилизации и бедность нашей как раз поэтому, что у нас СЛИШКОМ МНОГО людей руководствуется в жизни вашей примитивной одномерной позицией, выбирая либо поклонение золотому тельцу, либо псевдомессианство, а все другие измерения недоступны вашему примитивному мировоззрению.
ЦитироватьВаша проблема в том, что вы отлично владеете художественным словом и поисковыми системами, но абсолютно не умеете думать, во всяком случае на том уровне, который требуется для понимания программирования надежных систем.
Я вас тоже очень уважаю! :wink:
ЦитироватьНе нужно ничего искать, достаточно слегка напрячь мозги. Эта задача из класса неразрешимых, поскольку 1) не известны входные данные (они могут широко варьироваться на вещественных интервалах) и 2) даже если бы множество всех комбинаций аргументов было счетно и сравнительно невелико, количество комбинаций и перестановок на всех условных операторах программы определяется как экспонента от их количества. А ведь еще есть переменные, циклы с недетерминированным количеством итераций и т.д. и т.п.
Слова не практика, но мужа! :)
Давайте я немного потыкаю вас в практику:
double foo( double a, double b, double c, double d )
{
if( a > 0 )
{
return a + b * c - d;
}
return 2*a - b * c + d
}
Сколько наборов входных параметров из "несчетного множества всех комбинаций аргументов" потребуется, чтобы покрыть все линейные участки этой функции и убедиться, что она работает так, как ожидается? Мое ограниченное понимание в программировании надежных систем требует всего двух.
ЦитироватьЧтобы покрыть все линейные участки, разумеется необходимо обеспечить проход по комбинациям условий в программе
Нет.
ЦитироватьНе тратьте времени - отсутствие ошибок не гарантирует ни что. Я уже объяснял, о какой гарантии разговор.
Если в программе есть ошибки, естественно, что ее поведение может стать непредсказуемым.
ЦитироватьЦитироватьПокрытие маршрутов (путей) подразумевает, что вы тестируете набором, в котором предусматривается проход по всем возможным комбинациям условий в программе. К сожалению :( (попробую найти литературу) и это не гарантирует отсутствия ошибок.
Не нужно ничего искать, достаточно слегка напрячь мозги
Ну, хотел для авторитетности 8) специально для bs подыскать с конкретным примером. А пример хотел найти - читал когда-то - для случая с покрытием всех ПУТЕЙ (в простой программе), но все равно без гарантии отсутствия ошибок.
ЦитироватьЦитироватьЧтобы покрыть все линейные участки, разумеется необходимо обеспечить проход по комбинациям условий в программе
Нет.
Почему?
ЦитироватьЕсли в программе есть ошибки, естественно, что ее поведение может стать непредсказуемым.
Ошибки бывают разные. От ошибок в спецификации и ошибок в логике работы системы гарантии получить не реально. Гарантировать, что программа работает согласно спецификации - вполне.
ЦитироватьДавайте я немного потыкаю вас в практику:
Потыкайте своего кота ;)
Цитировать
double foo( double a, double b, double c, double d )
{
if( a > 0 )
{
return a + b * c - d;
}
return 2*a - b * c + d
}
Сколько наборов входных параметров из "несчетного множества всех комбинаций аргументов" потребуется, чтобы покрыть все линейные участки этой функции и убедиться, что она работает так, как ожидается? Мое ограниченное понимание в программировании надежных систем требует всего двух.
Начнем с того, что алгоритм в этой функции нелинейный (условный оператор). Продолжим тем, о чем подумал падишах, глядя на вторую клетку шахматной доски и закончим анализом реальной прошивки реальной БЦВМ (конец доски), где возникает экспоненциальная сложность. Ну и дополним тем, что ваш алгоритм некорректен в смысле отстутствия проверки на переполнение при умножении и сложении. То есть появляетя третья и четвертая, пятая и так далее ветви, на каждой некорректной арифметической операции. Разные процессоры ведут себя по разному. Одни генерируют аварийное прерывание. Другие присваивают значение NAN и умывают руки. Ну а вы, как программист чешете репу и пытаетесь понять, откуда взялись неучтенные ситуации. :wink:
ЦитироватьБомжей в СССР было достаточно, чтобы ими милиция закрывала план по мелким правонарушениям.
Я это знаю не из газет/журналов, а от людей, которые работали в милиции
Замечательно. Я видел ситуацию своими глазами.
Пусть будет "достаточно, чтобы милиция закрывала план" - но в любом случае по сравнению с сегодняшним положением это именно "единичные исключения".
ЦитироватьА когда был этот ваш развитой социализм? - Я достаточно хорошо помню жизнь с года примерно 1982, и очень хорошо помню вереницы нищенствующих на кладбищах и возле церквей
Перид "развитого социализма" - 1970е и 1980е.
Не надо передергивать и юлить, "нищенствующие возле церквей" - это зачастую не настоящие нищие. А вот бедности до нищеты среди народа практически не было.
Зато сейчас при капитализме - сколько угодно.
ЦитироватьВообще вы напоминаете янки из классики, которые не понимают никакого другого способа жизни кроме ихнего
Цитироватьнапример Чукчи
Господи, с кем я спорю... Сказано ведь...
Цитироватьбогатство западной цивилизации и бедность нашей
Какое на хрен "богатство"? Что понимаете под "западной цивилизацией"? Рынок? Откройте глаза и посмотрите на карту мира - нерыночных стран почти и нет на ней. ВЕЗДЕ рынок. И почти везде бедность. Жирует "золотой миллиард" - в основном за счет исторического ограбления колоний.
По поводу моего якобы "примитивного" и "одномерного" мышления могу сказать вот что. Я имел возможность своими глазами понаблюдать, пожить и при развитом социализме, и в цитадели "свободного мира" - где Not сейчас - и в сегодняшней России. И достаточно много чего повидал. И могу сравнивать.
В частности - видел и чувствовал на себе маразмы "развитой цивилизованной западной страны". Которую - как мне кажется - вы идеализируете.
В общем, все это не имеет прямого отношения к БВК АМС.
Хочется подискутировать на эти темы - следуйте на глобальную авантюру.
ЦитироватьНу, хотел для авторитетности 8)
Мужики, если бы я не считал участников этой ветки достойными собеседниками, я бы тут не писал. В жизни восприятие информации сильно зависит от исходной посылки, т.е. от того, считаете ли вы собеседника умственно отсталым или умным человеком. Так вот, всем здесь будет намного полезней думать, что собеседник как минимум не глупый. Такая простая вещь, а может творить чудеса, даже :!: когда такой исходный посыл ошибочен.
ЦитироватьНачнем с того, что алгоритм в этой функции нелинейный (условный оператор).
А кто говорил, что линейный?
ЦитироватьНу и дополним тем, что ваш алгоритм некорректен в смысле отстутствия проверки на переполнение при умножении и сложении. То есть появляетя третья и четвертая, пятая и так далее ветви, на каждой некорректной арифметической операции. Разные процессоры ведут себя по разному. Одни генерируют аварийное прерывание. Другие присваивают значение NAN и умывают руки. Ну а вы, как программист чешете репу и пытаетесь понять, откуда взялись неучтенные ситуации. :wink:
Маневр "соскок" обнаружен и засчитан :) Ошибки лучше обрабатывать там, где можно принять наиболее взвешенное решение. Данная функция понятия не имеет, как и где она будет использована, поэтому обрабатывать ошибки в ней очень не дальновидно. Механизм исключений придумали не умственно отсталые люди.
ЦитироватьЦитироватьНу и дополним тем, что ваш алгоритм некорректен в смысле отстутствия проверки на переполнение при умножении и сложении. То есть появляетя третья и четвертая, пятая и так далее ветви, на каждой некорректной арифметической операции. Разные процессоры ведут себя по разному. Одни генерируют аварийное прерывание. Другие присваивают значение NAN и умывают руки. Ну а вы, как программист чешете репу и пытаетесь понять, откуда взялись неучтенные ситуации. :wink:
Маневр "соскок" обнаружен и засчитан :) Ошибки лучше обрабатывать там, где можно принять наиболее взвешенное решение. Данная функция понятия не имеет, как и где она будет использована, поэтому обрабатывать ошибки в ней очень не дальновидно. Механизм исключений придумали не умственно отсталые люди.
В смысле соскок? Не вижу никакого соскока. Вы предложили проанализировать граф управления вашей функции. Я вам его нарисовал, исходя из предложенной информации, ни больше, не меньше. Обработки исключительной ситуации в вашем тексте я не вижу, из чего и расписываю ПОЛНЫЙ граф а не то что вы там себе вообразили из соображений здравого смысла. Проблема переполнения не настолько проста, насколько может показаться. Достаточно одного пробоя протоном чтобы в вашей переменной оказалось совсе не то, что вы ожидали увидеть. И никакие предварительные проверки тут не помогут.
ЦитироватьНищих как раз при развитом социализме не было. А при капитализме - сколько хочешь.
при развитом социализме - нищими были все. Иначе не ломанулись бы за колбасой.
ЦитироватьЗачем вообще становиться миллионером нормальному человеку? Есть достойное качество жизни, уверенность в будущем своем и своих детей - зачем стремиться к миллиардам?
Миллион (баксов) - это на самом деле не так уж и много. Столько рядовой работник за несколько лет зарабатывает. Талантливый - на порядок быстрее.
ЦитироватьЦитироватьИ шансов реализовать своё хобби как Маск - не имел бы
Вообще, зачем "как Маск"? В Советском Союзе существовали свои пути, как раз множество НИИ функционировали. Даже поговорка была об "удовлетворении своего любопытства за государственный счет", помните?
Затем, что хоть и за госсчёт - но исключительно в рамках предписанного направления. А прорывное предписано быть не может - слишком велик риск неуспеха при "свободном поиске", ни один чиновник не санкционирует.
ЦитироватьСи также не имеет альтернативы если надо активно управлять и взаимодействовать с железом. А для очень высокоуровневых вещей можно создать спец. DSL с кодогенератором в Си. Классический пример это генератор парсеров YACC.
Взаимодействие с железом - это не более чем запись/чтение значений по неким адресам. Такое даже в бейсике было, ЕМНИП
ЦитироватьВзаимодействие с железом - это не более чем запись/чтение значений по неким адресам.
Ага. А программирование - это всего лишь упорядочивание символов друг за другом :D
ЦитироватьЦитироватьДело не безопасности...
ну-ну. спор можно с вами на этом заканчивать
Это капитуляция?
ЦитироватьЦитироватьЯва и Си не особо сильно различаются по выразительности. Поэтому вероятность логических ошибок примерно одинакова
почитайте литературу
Аргументов не осталось?
Может тогда на C# переходить пора?
ЦитироватьЦитироватьАда помоему сейчас не особо актуальна
Ада успешно используется в настоящее время. Насколько я понимаю, кроме прочего - при написании ПО МКС.
Смотря для какого софта.
Неактуальность Ады в полностью новых проектах.
ЦитироватьЦитироватьдля очень высокоуровневых вещей можно создать спец. DSL с кодогенератором в Си
А можно - проблемно-ориентированный язык с прямой генерацией машинного кода 8) БЦВМ. Без промежуточной стадии.
Таких пока нет. Нужен язык общего назначения с большими низкоуровнвыми возможностями.
ЦитироватьВ смысле соскок? Не вижу никакого соскока. Вы предложили проанализировать граф управления вашей функции. Я вам его нарисовал, исходя из предложенной информации, ни больше, не меньше.
Нет, я предложил ответить на вопрос о числе требуемых наборов входных аргументов и показал, что их не бесконечное множество. Это лишь маленький пример, чтобы объяснить, почему не будет комбинаторной сложности в реальном проекте.
ЦитироватьОбработки исключительной ситуации в вашем тексте я не вижу, из чего и расписываю ПОЛНЫЙ граф а не то что вы там себе вообразили из соображений здравого смысла.
Обработки исключительной ситуации там быть не должно по уже обозначенным соображениям.
ЦитироватьПроблема переполнения не настолько проста, насколько может показаться. Достаточно одного пробоя протоном чтобы в вашей переменной оказалось совсе не то, что вы ожидали увидеть. И никакие предварительные проверки тут не помогут.
А что поможет? Формальная верификация? Или может анализатор логов, полученных прогонами на КИСе в тепличных условиях? :twisted:
Так вот, направляя вашу мысль в нужное русло - нам нужно обеспечить отработку исключительной ситуации, вызванной пробоем протоном. Для этого в системе будет дополнительный код, а соответственно в плане тестирования будет шаг, который обеспечит выполнение (покрытие) этого кода. И так во всем.
Покажите мне, как можно добиться лучших результатов!
ЦитироватьЦитироватьВ смысле соскок? Не вижу никакого соскока. Вы предложили проанализировать граф управления вашей функции. Я вам его нарисовал, исходя из предложенной информации, ни больше, не меньше.
Нет, я предложил ответить на вопрос о числе требуемых наборов входных аргументов и показал, что их не бесконечное множество. Это лишь маленький пример, чтобы объяснить, почему не будет комбинаторной сложности в реальном проекте.
1)
ЦитироватьСколько наборов входных параметров из "несчетного множества всех комбинаций аргументов" потребуется, чтобы покрыть все линейные участки этой функции и убедиться, что она работает так, как ожидается? Мое ограниченное понимание в программировании надежных систем требует всего двух.
А я утверждаю что как минимум три (плюс некорректное значение), чтобы убедиться что ваша функция не работает, как ожидается ;) То есть вы уже облажались и пропустили дугу в графе. Классическая ошибка, которая однажды привела к самоуничтожению Ариан-5. Тоже наверное разработчики были с чрезмерным самомнением ;)
2) Я ведь не зря вам написал про вторую клетку доски. К сожалению до вас не дошло. Каждое ветвление добавляет степень экспоненты. И в какой то момент вам просто не хватит мощности всех ваших компьютеров чтобы сгенерировать параметры для всех веток достаточно обширного алгоритма.
ЦитироватьПокажите мне, как можно добиться лучших результатов!
За парту! Начать с дискретной математики.
ЦитироватьЦитироватьНу, хотел для авторитетности 8)
Мужики,
Кое-что нашел. В. Кулямин с примерами:
http://panda.ispras.ru/~kuliamin/lectures-mbt/Lecture03.pdf
ЦитироватьЦитироватьЦитироватьНу, хотел для авторитетности 8)
Мужики,
Кое-что нашел. В. Кулямин с примерами:
http://panda.ispras.ru/~kuliamin/lectures-mbt/Lecture03.pdf
Хорошая статейка. Еще один важный момент, упомянутый и у Кулямина - проблема вычисления значений тестовых примеров, которая сводится к задаче выполнимости, которая NP (экспоненциально) трудна уже для булевых формул с количеством переменных больше трех. С вещественнымми еще грустнее - возникают невыпуклые функции и там полная извините задница в общем случае.
ЦитироватьПокажите мне, как можно добиться лучших результатов!
А после дискретки можно вернуться к программированию, но уже с позиций формальной верификации. Возвращаясь к вашей замечательной функции, можно либо явно перехватывать исключение, либо проверить параметры на входе (может быть очень трудно попасть в условия выражения, поскольку любое изменение там должно сопровождаться проверкой входного интервала, что не всегда тривиально для нелинейной функции). И, наконец, можно описать этот же интервал в аннотации к функции. Тогда верификатор, в процессе символического исполнения и доказательства корректности вычислит граничные значения на входе и проверит их на совместимость с выражениями внутри функции. К сожалению точность не гарантируется, поскольку интервалы возможных значений (область определения) могут быть слишком широкими. В этом случае генерируется предупреждение и предложение разработчику сузить интервал введением явной проверки.
ЦитироватьА я утверждаю что как минимум три (плюс некорректное значение), чтобы убедиться что ваша функция не работает, как ожидается ;) То есть вы уже облажались и пропустили дугу в графе.
Ну вот, я же говорил, что я волшебник. Из бесконечности сделали три. Рад за вас.
ЦитироватьКлассическая ошибка, которая однажды привела к самоуничтожению Ариан-5. Тоже наверное разработчики были с чрезмерным самомнением ;)
Вы тоже считаете это ошибкой программиста, который разработал корректный код для Ариан-4, а не тех, кто задействовал его для Ариан-5 без соответствующей доработки и тестирования? Не рад за вас :)
Давайте допустим, что программист, писавший код для Ариан-4, сделал бы обработку случая с переполнением (хотя это было бы совершенно бессмысленно). Вы считаете, что приемлемый вариант обработки такого случая для Ариан-4 подошел бы для Ариан-5? Т.е. отсечка по каналу управления из-за предельных значений 16-разрядного параметра не привела бы к катастрофе? Не рад за вас! :)
Давайте еще раз про исключения. Вы не знаете, как и где применяется функция, а уже рассуждаете о необходимости обработки ошибки прямо на месте. А вам не приходит в голову ни одного варианта, когда реакция на ошибку должна быть разной?
Цитировать2) Я ведь не зря вам написал про вторую клетку доски. К сожалению до вас не дошло. Каждое ветвление добавляет степень экспоненты. И в какой то момент вам просто не хватит мощности всех ваших компьютеров чтобы сгенерировать параметры для всех веток достаточно обширного алгоритма.
Конечно не дошло. Темный я. Только правда в том, что я получаю надежность системы, а вы отрекаетесь от нее, ссылаясь на чрезмерную сложность.
ЦитироватьЗа парту! Начать с дискретной математики.
Уже бегу!
ЦитироватьЦитироватьА я утверждаю что как минимум три (плюс некорректное значение), чтобы убедиться что ваша функция не работает, как ожидается ;) То есть вы уже облажались и пропустили дугу в графе.
Ну вот, я же говорил, что я волшебник. Из бесконечности сделали три. Рад за вас.
Смотрите пункт 2. Там не бесконечность, но экспоненциальность, что одно...эээ... лампово :)
профессионально программированием не занимаюсь уже лет 15 - но вопрос возник.
а вот _функциональное_ написание "сверху вниз" с использованием модульного подхода и жестко формализованными(в том числе по допустимым значениям) связями/ресурсозатратами на асме - при использовании аппаратного контроля данных и при необходимости - аппаратной многозадачности - это просто немодно или плохо?
ЦитироватьДавайте еще раз про исключения. Вы не знаете, как и где применяется функция, а уже рассуждаете о необходимости обработки ошибки прямо на месте. А вам не приходит в голову ни одного варианта, когда реакция на ошибку должна быть разной?
Я лишь следовал вашей спецификации. Ваша ошибка заключается в неполноте этой спецификации. Казалось бы мелочь - но мы помним про Ариан, где эта мелочь аукнулась так что будь здоров! Программирование высоконадежных систем - это в первую очередь полное описание спецификации функции. Design by contract - слышали наверное? Это в ту сторону. Интервалы переменных - всего лишь малая часть оных. А еще конкурентность, темпоральность, и так далее.
Цитироватьпрофессионально программированием не занимаюсь уже лет 15 - но вопрос возник.
а вот _функциональное_ написание "сверху вниз" с использованием модульного подхода и жестко формализованными(в том числе по допустимым значениям) связями/ресурсозатратами на асме - при использовании аппаратного контроля данных и при необходимости - аппаратной многозадачности - это просто немодно или плохо?
Если асм - это Ассемблер, то это безнадежно устарело. Ассемблер очень сложно проверять, что делает практически невозможным анализ относительно сложных программ. Если в Модуле выход за границы массива породит всего лишь исключительную ситуацию, которая может быть перехвачена и обработана, то в Ассемблере вы испортите все до чего дотянетесь.
ЦитироватьКое-что нашел. В. Кулямин с примерами:
http://panda.ispras.ru/~kuliamin/lectures-mbt/Lecture03.pdf
Очень хорошо! Я понял, о чем вы. Но давайте вспомним, что я говорил:
ЦитироватьПредставьте себе такой план тестирования, который заставляет отработать каждый линейный (детерминированный) участок кода минимум один раз и зафиксировать ожидаемый результат.
Я очень тщательно подбирал слова, все до последнего. Фиксация ожидаемого результата в данном случае эквивалента "покрытию ветвей" в статье. Со всеми вытекающими бонусами.
ЦитироватьЦитироватьКое-что нашел. В. Кулямин с примерами:
http://panda.ispras.ru/~kuliamin/lectures-mbt/Lecture03.pdf
Очень хорошо! Я понял, о чем вы. Но давайте вспомним, что я говорил:
ЦитироватьПредставьте себе такой план тестирования, который заставляет отработать каждый линейный (детерминированный) участок кода минимум один раз и зафиксировать ожидаемый результат.
Я очень тщательно подбирал слова, все до последнего. Фиксация ожидаемого результата в данном случае эквивалента "покрытию ветвей" в статье. Со всеми вытекающими бонусами.
Почитайте ту статью внимательно. Точное покрытие вычислительно сложно в общем случае. Неточное покрытие бессмысленно. Т.е. всегда существует некий компромисс между желаниями и возможностями.
то-есть в основном немодно, т.к. про в том числе "проверку диапазонов" я как-бы упомянул?
Мне трудно оценить общую сложность реализации - но имхо не факт что написание+отладка "высокоуровневой" программы _конкретно для КА_ окажется быстрее/дешевле/проще/надежнее чем то-же на асме.
В частности я в основном на нем и писал - и мне долго было дико читать про утечки памяти, сборку мусора, эксепшены и прочую херомантию, страхующую неряшливых/неграмотных программистов.
Но это сугубое имхо конечно.
Цитироватьто-есть в основном немодно, т.к. про в том числе "проверку диапазонов" я как-бы упомянул?
Мне трудно оценить общую сложность реализации - но имхо не факт что написание+отладка "высокоуровневой" программы _конкретно для КА_ окажется быстрее/дешевле/проще/надежнее чем то-же на асме.
В частности я в основном на нем и писал - и мне долго было дико читать про утечки памяти, сборку мусора, эксепшены и прочую херомантию, страхующую неряшливых/неграмотных программистов.
Но это сугубое имхо конечно.
Да пожалуйста, кривой GOTO у которого переменная в качестве смещения. И таких вариантов в Ассемблере пруд пруди. А формально проверить невозможно вследствие огромного количества состояний ассемблерной программы. Мода тут непричем. Причем тут непрактичность больших ассемблерных программ.
ЦитироватьЦитироватьПредставьте себе такой план тестирования, который заставляет отработать каждый линейный (детерминированный) участок кода минимум один раз и зафиксировать ожидаемый результат
Я очень тщательно подбирал слова, все до последнего. Фиксация ожидаемого результата в данном случае эквивалента "покрытию ветвей" в статье
Я вообще понимаю слова в их общепринятом смысле. Как мне кажется, "отработать каждый участок минимум один раз" эквивалентно всего лишь "заставить выполниться каждый оператор минимум один раз", а вовсе не "заставить выпониться каждый линейный участок при каждом возможном сочетании значений логических условий, ведущем к данному линейному участку".
И еще. В случае упрвляющих алгоритмов для КА ситуация весьма осложняется за счет наличия "внешних" по отношению к ПО условий - показаний датчиков, контролирующих БА, и пр. Причем эти условия меняются со временем.
ЦитироватьЯ лишь следовал вашей спецификации. Ваша ошибка заключается в неполноте этой спецификации.
Я как раз рассуждал в рамках гарантии соответствия кода спецификации. Ошибки в спецификации - совсем другой вопрос. Не ругайте меня за них: когда я программист, я - преобразователь спецификаций в качественный код. Когда я проектировщик - тогда можно и за спецификации попинать.
ЦитироватьКазалось бы мелочь - но мы помним про Ариан, где эта мелочь аукнулась так что будь здоров!
Не, не, не... Дэвид Блейн. Ариан-5 - жертва глупости проектировщиков. Программист сделал свое дело (по спецификациям Ариан-4), программист может уходить :P
ЦитироватьПрограммирование высоконадежных систем - это в первую очередь полное описание спецификации функции. Design by contract - слышали наверное? Это в ту сторону. Интервалы переменных - всего лишь малая часть оных. А еще конкурентность, темпоральность, и так далее.
Ну было бы все просто - не было бы интереса к таким задачам.
Цитироватьто-есть в основном немодно, т.к. про в том числе "проверку диапазонов" я как-бы упомянул?
Нет, не немодно, а сложно, затратно, не надежно (т.е. конечно можно сделать очень надежно, но будет очень не эффективно, по сравнению с более "модными" средствами).
ЦитироватьЦитироватьЦитироватьПредставьте себе такой план тестирования, который заставляет отработать каждый линейный (детерминированный) участок кода минимум один раз и зафиксировать ожидаемый результат
Я очень тщательно подбирал слова, все до последнего. Фиксация ожидаемого результата в данном случае эквивалента "покрытию ветвей" в статье
Я вообще понимаю слова в их общепринятом смысле. Как мне кажется, "отработать каждый участок минимум один раз" эквивалентно всего лишь "заставить выполниться каждый оператор минимум один раз", а вовсе не "заставить выпониться каждый линейный участок при каждом возможном сочетании значений логических условий, ведущем к данному линейному участку".
Даже это в общем случае трудно. Представьте что вам нужно проверить самый последний линейный участок (или последний оператор, если угодно) перед завершением программы. Это означает, что вам нужно подобрать такие условия, при которых этот оператор выполнится, то есть фактически решить задачу останова, которая в общем случае неразрешима за полиномиальное время, по Тьюрингу. Наверняка будут частные примеры, когда это просто, но в общем случае - нет.
Цитироватьпри развитом социализме - нищими были все. Иначе не ломанулись бы за колбасой
Все, последний раз здесь отклоняюсь от темы в эту сторону.
Приведенное утверждение является ложью.
И ломанулись не за колбасой, а за свободой. Какие же мы были идиоты...
ЦитироватьМиллион (баксов) - это на самом деле не так уж и много. Столько рядовой работник за несколько лет зарабатывает
А тратит сколько за это время? На жилье?
ЦитироватьЯ вообще понимаю слова в их общепринятом смысле. Как мне кажется, "отработать каждый участок минимум один раз" эквивалентно всего лишь "заставить выполниться каждый оператор минимум один раз"
Вы все правильно поняли! Но уже который раз пропускаете неотъемлемое -
фикасацию ожидаемого результата. По примеру в статье - тестируем функцию, фиксируем резльтат. Слово "нечетное" в результате отсутствует. Его нет - ошибка обнаружена, результат не соответствует ожидаемому.
ЦитироватьИ еще. В случае упрвляющих алгоритмов для КА ситуация весьма осложняется за счет наличия "внешних" по отношению к ПО условий - показаний датчиков, контролирующих БА, и пр. Причем эти условия меняются со временем.
Безусловно! Но это не значит, что мы должны смириться с этим. Ищем, находим и применяем способы адекватной их отработки.
ЦитироватьНо это не значит, что мы должны смириться с этим. Ищем, находим и применяем способы адекватной их отработки.
Ну конечно мы не смирились!
Иначе бы мы здесь не сидели 8)
ЦитироватьЦитироватьЦитироватьДело не безопасности...
ну-ну. спор можно с вами на этом заканчивать
Это капитуляция?
ничего подобного. это констатация.
ЦитироватьНет, не немодно, а сложно, затратно, не надежно (т.е. конечно можно сделать очень надежно, но будет очень не эффективно, по сравнению с более "модными" средствами).
позволю себе с вами не согласиться - из моей практики - моя реализация на асме на равном железе была на 2 порядка (!) быстрее, ей _всегда_ хватало ресурсов и она решала при этом более полную задачу (больше объем данных, сложнее структура), чем "фирменный" продукт на плюсах. И задача была нетривиальна. Правда, мне не заплатили в результате...
2 Not - ни в коем случае не хочу спорить ради спора - но описанная Вами ситуация - либо алгоритмическая (сам алгоритм/его реализация) ошибка, либо ошибка диапазонов в модуле - генераторе адресов, не говоря уже о том, что это нездоровый стиль.
Безусловно я сейчас в этой области любитель, кроме того в командных проектах больше нескольких человек не учавствовал, да и их не любил - но вот быстрый, эффективный, надежный код я писал. И извращенный типа алгоритмов на самомодификации - тоже. И как-то всегда получалось, что отладка на асме - алгоритмическая или блохи в диапазонах - а вот в остальных случаях (с - с++) - все намного запутаннее...
ЦитироватьЦитироватьНет, не немодно, а сложно, затратно, не надежно (т.е. конечно можно сделать очень надежно, но будет очень не эффективно, по сравнению с более "модными" средствами).
позволю себе с вами не согласиться - из моей практики - моя реализация на асме на равном железе была на 2 порядка (!) быстрее, ей _всегда_ хватало ресурсов и она решала при этом более полную задачу (больше объем данных, сложнее структура), чем "фирменный" продукт на плюсах. И задача была нетривиальна. Правда, мне не заплатили в результате...
2 Not - ни в коем случае не хочу спорить ради спора - но описанная Вами ситуация - либо алгоритмическая (сам алгоритм/его реализация) ошибка, либо ошибка диапазонов в модуле - генераторе адресов, не говоря уже о том, что это нездоровый стиль.
Безусловно я сейчас в этой области любитель, кроме того в командных проектах больше нескольких человек не учавствовал, да и их не любил - но вот быстрый, эффективный, надежный код я писал. И извращенный типа алгоритмов на самомодификации - тоже. И как-то всегда получалось, что отладка на асме - алгоритмическая или блохи в диапазонах - а вот в остальных случаях (с - с++) - все намного запутаннее...
Да на здоровье. Пишите. Может и заплатят... когда нибудь. Но большие проекты на ассемблере давно уже не пишут, по вышеозвученным причинам.
ЦитироватьВозвращаясь к вашей замечательной функции, можно либо явно перехватывать исключение, либо проверить параметры на входе (может быть очень трудно попасть в условия выражения, поскольку любое изменение там должно сопровождаться проверкой входного интервала, что не всегда тривиально для нелинейной функции).
То есть мы возвращаем к основам. Что программист обязан досконально знать архитектуру процессора и используемый формат чисел с плавающей точкой? В таком случае значительно проще будет программировать на ассемблере сопроцессора явно проверяя все флаги и отлавливая исключения.
Кстати даже целочисленное переполнение проще контролировать на ассемблере, т.к. у процессора есть спец. флаг, который из высокоуровневых языков недоступен.
Нет, компилятор же, грубо говоря, дружит с ассемблером. Можно заставить его хоть каждую арифметическую операцию сопровождать проверкой флага переполнения, при этом абсолютно прозрачно для программиста. Так что это не повод писать на ассемблере. Вопрос целесообразности такой паранои рассматривать не будем :)
Цитироватьпозволю себе с вами не согласиться - из моей практики - моя реализация на асме на равном железе была на 2 порядка (!) быстрее, ей _всегда_ хватало ресурсов и она решала при этом более полную задачу (больше объем данных, сложнее структура), чем "фирменный" продукт на плюсах. И задача была нетривиальна. Правда, мне не заплатили в результате...
Хотите скажу почему взяли фирменный продукт на плюсах? Да потому что ваш код на ассемблере смогли бы сопровождать только вы сами или такой же как вы представитель вымирающего вида разработчиков, да и то не факт. А продукт на плюсах будет сопровождать любой подкованный в плюсах разработчик, коих несравнимо больше. Это зачастую намного важнее, чем более эффективная работа софта. Когда я говорил про эффективность, я подразумевал эффективность разработки как процесса, а не как эффективность его результата.
Цитироватьпозволю себе с вами не согласиться - из моей практики - моя реализация на асме на равном железе была на 2 порядка (!) быстрее, ей _всегда_ хватало ресурсов . И как-то всегда получалось, что отладка на асме - алгоритмическая или блохи в диапазонах - а вот в остальных случаях (с - с++) - все намного запутаннее...
Вы спорите с людьми, которые не занимаются железными проектами с встроенным ПО. Они живут в своем виртуальном "высоком" мире, не чувствуют нутром связь железа и кода, параноидально отстаивают свои миражи и психуют с оскорблениями, если их позицию пытаются оспорить. Они никогда не поймут то, о чем я или вы говорим, об аккуратности и строгости подхода. Асм им видится неким непонятным атавистичеким врагом, хотя этот асм может иметь и макросы, и стандартную библиотеку процедур. Эти "высокие" товарищи могут и не знать, что множество функций, модулей в языках высокого уровня, в языках моделирования пишется на асме, с целью оптимизации по размеру и скорости. Этим товарищам неведомо, что вместо их высокопроверенных ОС, написанных на эрлангах, в экстренном случае на борт ФГ нужно отправить несколько сот байт кода, выполняющих строго заданную функцию, а больше отправить просто нельзя, из-за ограничений по времени и условиям связи. И что такой код может быть написан только на машинном языке, с отличным пониманием связки железо-код. И еще они не понимают и не хотят понимать, что умеющий качественно, тщательно писать на асме ВСЕГДА будет писать хороший код и на языке высокого уровня, что асм может быть хорошей школой, а сам проект - на языке высокого уровня. Всю эту тему можно слить в утиль, от высоких программистов тут идут лишь пустые сотрясательства воздуха и ни один из них так и не ответил на простой вопрос - "готовы вместо трендежа работать над проектом и проявить свои умения?".
ЦитироватьНет, компилятор же, грубо говоря, дружит с ассемблером. Можно заставить его хоть каждую арифметическую операцию сопровождать проверкой флага переполнения, при этом абсолютно прозрачно для программиста. Так что это не повод писать на ассемблере. Вопрос целесообразности такой паранои рассматривать не будем :)
Речь не о проверки компилятором, а о "обработчиках". Если на асме простой условный переход по флагу, то на ЯВУ потребуется изменение синтаксиса.
Да и проверки компилятора будут тупы и неэффективны, т.к. будут тупо включены на каждую операцию. На асме всё можно сделать только там где надо и что надо. Например, флаг потери точности при операциях с плавающей точкой - в большенстве случаев пофиг на эту ситуацию, однако в ряде случаев её может быть необходимо обработать. Как указать это компилятору на ЯВУ? Нереально.
Ps. В этом плане "ручная верификация" программ на асме действительно создавать высоканадёжный код. Только медленно.
Цитироватьэффективность разработки как процесса, а не как эффективность его результата.
э-э? а как же результат? _высоконадежный_ и все такое? Для коммерческого софта - вы правы(что грустно), но мы говорим все-таки о единичном продукте с чудовищной стоимостью ошибок?
Unispace, вы агрессивно генерализируете имхо) Мне кажется что присутствующие здесь высокие товарищи знают про асм не из книжек... К тому-же я не спорю, а спрашиваю и местами сомневаюсь - я все-таки уже непрофессионал в ПО.
И кстати мне кажется что функциональные графические языки о которых немного здесь говорили очень эффективно и надежно решают задачу... Если конечно атомарные блоки вылизаны...
ЦитироватьАсм им видится неким непонятным атавистичеким врагом, хотя этот асм может иметь и макросы, и стандартную библиотеку процедур. Эти "высокие" товарищи могут и не знать, что множество функций, модулей в языках высокого уровня, в языках моделирования пишется на асме, с целью оптимизации по размеру и скорости.
А вы ни разу не допускаете возможности того, что это предположение ошибочно в виду вашей предвзятости в этом вопросе?
Цитироватьумеющий качественно, тщательно писать на асме ВСЕГДА будет писать хороший код и на языке высокого уровня, что асм может быть хорошей школой, а сам проект - на языке высокого уровня.
Ух заблуждаетесь. Во-первых, понятие хороший код очень растяжимое. Кому-то хороший - это сколь угодно кривой, но быстрый, а кому-то наоборот. Критериев хорошести много и они еще зависят от специфики задачи.
Во-вторых, есть такой эффект - когда разработчик достигает "просветления", он пишет хороший код на чем угодно. Но прикол в том, что этого гораздо легче достичь, работая с языками высокого уровня, чем наоборот. Потому что такой человек будет писать на ассемблере, как на языке высокого уровня. Писать на ЯВУ как на ассемблере намного сложнее :)
Это не пустой треп - уж я на асме исписал будь здоров и прошел путь от i8080 до протмода i386-х, не считая убогих микроконтроллеров и процов DSP.
ЦитироватьПроверки компилятора будут тупы и неэффективны, т.к. будут тупо включены на каждую операцию. На асме всё можно сделать только там где надо и что надо. Например, флаг потери точности при операциях с плавающей точкой - в большенстве случаев пофиг на эту ситуацию, однако в ряде случаев её может быть необходимо обработать. Как указать это компилятору на ЯВУ? Нереально.
Да реально. Возьмем работу с FPU на С++ в платформе i80x86. Рантайм позволяет изменять флаги FPU, отвечающие за индикацию ошибок. Сам FPU умеет генерировать прерывание в случае ошибочных ситуаций. Это прерывание транслируется в исключение. Исключение можно обрабатывать там, где это уместно. Можно игнорировать или просто отключить генерацию прерывания FPU.
Цитироватьесть такой эффект - когда разработчик ... пишет хороший код на чем угодно. Но прикол в том, что этого гораздо легче достичь, работая с языками высокого уровня
Вот тут не согласен. попробуйте разбалованного библиотеками работы с памятью (с виртуальной в том числе) программиста пересадить на асм. Или пусть даже с плюсов на си. Сверху вниз спускаться намного труднее - надо самому делать вещи, о которых вы даже не задумывались. Большая трудоемкость - это недостаток понижения уровня языка, безусловно, но это - повышение надежности продукта, т.к. вы _точно_ знаете что и как работает.
ЦитироватьИсключение можно обрабатывать там, где это уместно
А должны ли быть исключения(ситуативно), если пишется высоконадежный код? Имхо - костыль, наравне с гарбадж коллектом. Надо прибирать за собой - и надо понимать, что происходит в программе.
ЦитироватьВот тут не согласен. попробуйте разбалованного библиотеками работы с памятью (с виртуальной в том числе) программиста пересадить на асм. Или пусть даже с плюсов на си. Сверху вниз спускаться намного труднее - надо самому делать вещи, о которых вы даже не задумывались.
А я не говорил, что это легко. Я говорил про качество результата :)
ЦитироватьА должны ли быть исключения(ситуативно), если пишется высоконадежный код? Имхо - костыль, наравне с гарбадж коллектом. Надо прибирать за собой - и надо понимать, что происходит в программе.
Исключения как инструмент обработки ошибок настолько же надежен, как дополнительные проверки и даже более надежен, т.к. не зависит от того, забыл кто-то проверить код/флаг ошибки или нет, и не плодит лишний код на эти проверки.
ЦитироватьДа реально. Возьмем работу с FPU на С++ в платформе i80x86. Рантайм позволяет изменять флаги FPU, отвечающие за индикацию ошибок. Сам FPU умеет генерировать прерывание в случае ошибочных ситуаций. Это прерывание транслируется в исключение. Исключение можно обрабатывать там, где это уместно. Можно игнорировать или просто отключить генерацию прерывания FPU.
Это частный случай. Выброс аппаратного исключения.
Я говорю про явную проверку в коде различных низкоуровневых условий. Например переполнения. В ЯВУ переполнение может быть как допустимым (арифметика по модулю) и недопустимым (вычисления). На асме всё можно точно закодить и проверить.
ЦитироватьВо-вторых, есть такой эффект - когда разработчик достигает "просветления", он пишет хороший код на чем угодно. Но прикол в том, что этого гораздо легче достичь, работая с языками высокого уровня, чем наоборот. Потому что такой человек будет писать на ассемблере, как на языке высокого уровня. Писать на ЯВУ как на ассемблере намного сложнее :)
Это не пустой треп - уж я на асме исписал будь здоров и прошел путь от i8080 до протмода i386-х, не считая убогих микроконтроллеров и процов DSP.
Не видел хороших программистов, пересевших с асма на высокий уровень и пишущих на этом высоком уровне плохо и неаккуратно. Достаточно вспомнить программистов компьютерных игр, начинавших с кодов при жестком ограничении в ресурсах и продолжающих отлично делать свое дело на высоком уровне. То же самое в приборной области, то же самое в прикладном компьютерном ПО. Зато я вижу море программеров окошек, делающих свою работу спустя рукава, небрежно и плохо. Вы в курсе, что даже один из создателей очень известного языка высокого уровня был ярым противником нагромождения лишних конструкций ? Здесь отмечаются люди, оторванные от проектирования прибора целиком, они видят только свою область, тестирование, эрланги. А ведь языки более высокого уровня не только облегчают программирование, но и вносят свои особенности, требующие еще большего тестирования. Сборщики мусора, динамическая память и прочие надаппаратные вещи в жесткой среде реального времени - это не плюс. И задача аккуратности и тщательности при программировании никак не может быть заменена последующими тестированиями. Асм воспитывает такую аккуратность и полезен как этап профессионального опыта. Это примерно то же самое, что армия. Вас никто не заставляет во взрослой жизни жить по-армейски, но человек, прошедший армию, будет во многих вещах выглядеть предпочтительнее, чем бывший студент-хиппи. А если дело касается таких вещей, как встроенное ПО для космических аппаратов, то там коды вообще не могут быть забыты в принципе, они всегда присутствуют.
ЦитироватьЯ говорю про явную проверку в коде различных низкоуровневых условий. Например переполнения. В ЯВУ переполнение может быть как допустимым (арифметика по модулю) и недопустимым (вычисления). На асме всё можно точно закодить и проверить.
Ну по аналогии при необходимости всегда можно сделать библиотеку типов со вставками на асме с такой жесткой проверкой всех операций и генерацией исключений по результатам проверок. Так что даже такая глобальная паранойя вполне реализуется и на ЯВУ.
ЦитироватьКстати да, существует масса инструментов для Си. Это статические анализаторы кода, рантайм анализаторы и прочее. При грамотной методологии разработки и тестирования можно получить очень надёжных код.
:shock: Это примерно как утверждать, что "очень надежный код можно получить на Ассемблере". Т.к. Си имеет максимально широкие возможности наловить глюков из-за своих широчайших возможностей по доступу к аппаратуре.
ЦитироватьНапример, флаг потери точности при операциях с плавающей точкой - в большенстве случаев пофиг на эту ситуацию, однако в ряде случаев её может быть необходимо обработать. Как указать это компилятору на ЯВУ? Нереально.
Вообще-то это делается еще на этапе создания/наполнения оптимизатора в компиляторе. Как пример могу привести реализацию циклического сдвига на Си для 1 байтного числа которую компиляция очень часто приведет к одной/двум(зависит от камня) процессорным командам с использованием бита переноса.
// циклический сдвиг влево движок форума не пропустил :roll:
x=((x >> 1) | (x << 7)); // циклический сдвиг вправо
Т.е. вместо того, что-бы сделать все то, что явно написано в строке будет просто использование бита переноса вполне конкретной ситуации где это надо/допустимо.
ЦитироватьPs. В этом плане "ручная верификация" программ на асме действительно создавать высоканадёжный код. Только медленно.
По моему опыту - с некоторого размера нет! Начинаешь терять суть кода в отдельных кусках. Приходится урезать самому себе набор доступных "хаккерских" приемов т.к. "спецэффекты" вылазят полным ходом в самых разных местах. Могу ограничить объем Асм-кода для одного высококлассного разработчика примерно 40-60кБ (правда туда можно засунуть всю логику работы ФГ ;) ) - дальше время получения надежного кода улетает за десятки лет разработки. Кроме того во весь рост встает проблема совместной работы нескольких программистов над одним кодом - с Асмом начинаются ТАКИЕ разборки, что быстрее вместе не писать....
ЦитироватьНе видел хороших программистов, пересевших с асма на высокий уровень и пишущих на этом высоком уровне плохо и неаккуратно. Достаточно вспомнить программистов компьютерных игр, начинавших с кодов при жестком ограничении в ресурсах и продолжающих отлично делать свое дело на высоком уровне. То же самое в приборной области, то же самое в прикладном компьютерном ПО.
Это немного не то. Да, они будут выдавать более оптимальный с точки зрения ресурсов и быстродействия код на ЯВУ, но это не самый важный критерий для ПО КА.
ЦитироватьЗато я вижу море программеров окошек, делающих свою работу спустя рукава, небрежно и плохо.
Я вижу такое же количество строителей, делающих работу из рук вон плохо. Но вряд ли я стал бы сетовать на то, что они ничего не понимают в технологии изготовления кирпичей. Это сейчас тенденция такая - доступность технологий опускает входной барьер в профессию. Поэтому на выходе много мусора, который даже не осознает, что он реально ничего из себя не представляет. Какой-то процент адекватных разработчиков все-таки есть.
ЦитироватьВы в курсе, что даже один из создателей очень известного языка высокого уровня был ярым противником нагромождения лишних конструкций ?
Не совсем понял о каком нагромождении каких конструкций речь, поэтому идентификацию провести не смог :)
ЦитироватьЗдесь отмечаются люди, оторванные от проектирования прибора целиком, они видят только свою область, тестирование, эрланги.
А я отношусь к этому очень положительно. Талантливые люди из других областей тоже полезны.
ЦитироватьА ведь языки более высокого уровня не только облегчают программирование, но и вносят свои особенности, требующие еще большего тестирования. Сборщики мусора, динамическая память и прочие надаппаратные вещи в жесткой среде реального времени - это не плюс. И задача аккуратности и тщательности при программировании никак не может быть заменена последующими тестированиями.
Или вносят свои особенности, которые в итоге требует меньше тестирования.
ЦитироватьАсм воспитывает такую аккуратность и полезен как этап профессионального опыта.
Асм безусловно очень полезен как этап проф. опыта. Но аккуратность программирования можно воспитывать не только им.
ЦитироватьА если дело касается таких вещей, как встроенное ПО для космических аппаратов, то там коды вообще не могут быть забыты в принципе, они всегда присутствуют.
А не спешите с такими выводами. В этой теме уже были озвучены следующие интересные факты:
- ОАО ИСС ведет разработку на собственной кросс-платформе на базе языка Модула-2, которая для покрытия большего числа платформ включает в свой состав фронт-компилятор в язык Си. Т.е. там ассемблера вообще в принципе быть не может ни на каком этапе.
- ФГУП "НПЦ Автоматики и приборостроения им. Пилюгина" уже в далеком прошлом перевело все свои разработки на ГРАФИТ-ФЛОКС (графический язык реального времени). А это подразумевает не только отсутствие ассемблера, но и в принципе разработку ПО инженерами, которые к программированию отношения не имеют вообще! Не говоря уже про ассемблер.
ЦитироватьЦитироватьНе видел хороших программистов, пересевших с асма на высокий уровень и пишущих на этом высоком уровне плохо и неаккуратно. Достаточно вспомнить программистов компьютерных игр, начинавших с кодов при жестком ограничении в ресурсах и продолжающих отлично делать свое дело на высоком уровне. То же самое в приборной области, то же самое в прикладном компьютерном ПО.
Это немного не то. Да, они будут выдавать более оптимальный с точки зрения ресурсов и быстродействия код на ЯВУ, но это не самый важный критерий для ПО КА.
Уже и по оптимальности ручной код начинает проигрывать машинно-сгенерированному из С. Это связано с внедрением в БЦВМ гибридных архитектур, векторных процессоров, настраиваемых конвейеров. Попробуйте перемножить матрицы на векторном процессоре на ассемблере. Или попробуйте вручную загрузить конвейер для эффективной обработки той же матрицы. Причем речь не о встроенных конвейерах АЛУ, а именно о внешних, управляемых пользователем. Трансляторы же с ЯВУ делают это значительно лучше.
ЦитироватьУже и по оптимальности ручной код начинает проигрывать машинно-сгенерированному из С. Это связано с внедрением в БЦВМ гибридных архитектур, векторных процессоров, настраиваемых конвейеров.
Бесспорно. И даже не надо далеко ходить, взять хотя бы плавающий указатель стека - руками такое на асме делать не реально, а уже заметная экономия кода и дополнительный свободный регистр. Глобальная оптимизация, альясинг и прочие штуки дают существенный выигрыш даже в банальном коде.
ЦитироватьУже и по оптимальности ручной код начинает проигрывать машинно-сгенерированному из С. Это связано с внедрением в БЦВМ гибридных архитектур, векторных процессоров, настраиваемых конвейеров. Попробуйте перемножить матрицы на векторном процессоре на ассемблере. Или попробуйте вручную загрузить конвейер для эффективной обработки той же матрицы. Причем речь не о встроенных конвейерах АЛУ, а именно о внешних, управляемых пользователем. Трансляторы же с ЯВУ делают это значительно лучше.
Писать векторный код на Си - не легче чем на ассемблере. Там изпользуютса специальные функции, которые точно соответствуют векторным инструкциям соответного процессора. Если вы напишете умножение матрицы обычными средствами языка, то они не преобразуютса в векторный код т.к. векторным инструкциям нужен адрес делимый на размер вектора.
ЦитироватьУже и по оптимальности ручной код начинает проигрывать машинно-сгенерированному из С. Это связано с внедрением в БЦВМ гибридных архитектур, векторных процессоров, настраиваемых конвейеров. Попробуйте перемножить матрицы на векторном процессоре на ассемблере. Или попробуйте вручную загрузить конвейер для эффективной обработки той же матрицы. Причем речь не о встроенных конвейерах АЛУ, а именно о внешних, управляемых пользователем. Трансляторы же с ЯВУ делают это значительно лучше.
Не начинает. На малых кусках код машина делает оптимальнее, но интегрально Асм-программа получается все равно эффективнее. Причина в разных подходах. Когда пишешь на Асме начинаешь прежде всего с удобного размещения наиболее часто используемых величин (как минимум флаги состояний) в наиболее доступных регистрах. А потом стиль просто навязывает разбиение задачи на фрагменты ложащиеся на регистровую матрицу камня с максимальным использованием минимальных регистров (того, что заложено в аппаратуру камня). Причем максимально используются доступные элементы контроллера типа системы прерываний, таймеров и DMA. Не потому, что доступнее, а потому, что так проще.
Посмотри к примеру конструкцию выше как использовать бит переноса в Си. Но ведь это ГЕМОРРОЙ и поэтому циклический сдвиг так редко встречается в Си-программах. А вот скажи, 128 битное суммирование на 8 битной машине в Си - исполнении не пробовал? А многобитную криптографию на циклических сдвигах? Но ведь это все простейшие операции при возможности работы с битами состояния процессора (на Асме)!
ЦитироватьА не спешите с такими выводами. В этой теме уже были озвучены следующие интересные факты:
- ОАО ИСС ведет разработку на собственной кросс-платформе на базе языка Модула-2, которая для покрытия большего числа платформ включает в свой состав фронт-компилятор в язык Си. Т.е. там ассемблера вообще в принципе быть не может ни на каком этапе.
Любой процессор исполняет машинные коды, а не модулу-2. Да, были и есть такие очень специальные процессоры и системы, которые имеют именно машинные команды вычисления матрицы или преобразования Хартли. При разработке можно без проблем обойтись без асма, но все-таки процессор будет оперировать кодами, и при возникновении какой-либо экстренной ситуации или дебаге может возникнуть необходимость обратиться именно к кодам. Я работал с очень сложной системой, где ПО из миллионов строк было написано на языке выского уровня класса Ада. Но мы обязаны были изучить архитектуру процессоров, на которых исполнялся сгенерированный компилятором код, и в экстренных случаях уметь править ПО прямо в коде, потому что иного способа просто не было. Чтобы поправить все в листинге, сгенерировать код заново, понадобилось бы не меньше суток. Теперь представьте, что в ФГ нашли ошибку за 10 минут до сеанса, а средства создания образа, который нужно срочно загрузить в ФГ, смогут сгенерировать этот образ через полчаса. Или вариант, когда нужно загрузить очень короткий код, без всяких ОС, страниц памяти и прочего, просто код, который сразу, без всяких долгих инициализаций, запустит двигатели. Остается только один путь - править сам образ или создать этот короткий машинный код. Так что коды есть и будут присутствовать в таких системах, пока процессоры не научатся исполнять язык высокого уровня напрямую :)
ЦитироватьПисать векторный код на Си - не легче чем на ассемблере. Там изпользуютса специальные функции, которые точно соответствуют векторным инструкциям соответного процессора.
Векторный код на С++:
Matrix A = ( B * C ).T() * V;
Писать его очень легко (да проще уже не бывает), а специализированная библиотека матричных операций сделает все необходимое для максимально эффективной загрузки конвеера абсолютно прозрачно для программиста. Разобраться в таком коде на порядки проще, чем в куче спец инструкций. Сделать ошибку - на порядки сложнее.
ЦитироватьЦитироватьУже и по оптимальности ручной код начинает проигрывать машинно-сгенерированному из С. Это связано с внедрением в БЦВМ гибридных архитектур, векторных процессоров, настраиваемых конвейеров.
Бесспорно. И даже не надо далеко ходить, взять хотя бы плавающий указатель стека - руками такое на асме делать не реально, а уже заметная экономия кода и дополнительный свободный регистр. Глобальная оптимизация, альясинг и прочие штуки дают существенный выигрыш даже в банальном коде.
А анекдот в том, что на Асме этот плавающий указатель стека тебе даже в голову не придет использовать. Если конечно не пожелаешь пройтись по широко расставленным граблям...
ЦитироватьЦитироватьПисать векторный код на Си - не легче чем на ассемблере. Там изпользуютса специальные функции, которые точно соответствуют векторным инструкциям соответного процессора.
Векторный код на С++:
Matrix A = ( B * C ).T() * V;
Писать его очень легко (да проще уже не бывает), а специализированная библиотека матричных операций сделает все необходимое для максимально эффективной загрузки конвеера абсолютно прозрачно для программиста. Разобраться в таком коде на порядки проще, чем в куче спец инструкций. Сделать ошибку - на порядки сложнее.
Ну если изпользовать библиотеку , можно ето делать и на ассемблере. Будет просто передача адресов в реестры и вызов подпрограмы.
ЦитироватьЦитироватьПисать векторный код на Си - не легче чем на ассемблере. Там изпользуютса специальные функции, которые точно соответствуют векторным инструкциям соответного процессора.
Векторный код на С++:
Matrix A = ( B * C ).T() * V;
Писать его очень легко (да проще уже не бывает), а специализированная библиотека матричных операций сделает все необходимое для максимально эффективной загрузки конвеера абсолютно прозрачно для программиста. Разобраться в таком коде на порядки проще, чем в куче спец инструкций. Сделать ошибку - на порядки сложнее.
А ты поиграйся с разными типами матриц и полюбуйся НАСКОЛЬКО разный код будет получен. Причем скорость будет часто разная на порядки.
ЗЫ. А еще попробуй скомпилировать это добро "специальной библиотекой" для 8-разрядного AVR-а. :twisted:
ЦитироватьЯ работал с очень сложной системой, где ПО из миллионов строк было написано на языке выского уровня класса Ада. Но мы обязаны были изучить архитектуру процессоров, на которых исполнялся сгенерированный компилятором код, и в экстренных случаях уметь править ПО прямо в коде, потому что иного способа просто не было. Чтобы поправить все в листинге, сгенерировать код заново, понадобилось бы не меньше суток.
Ну это вас жестоко развели! :wink:
ЦитироватьТеперь представьте, что в ФГ нашли ошибку за 10 минут до сеанса, а средства создания образа, который нужно срочно загрузить в ФГ, смогут сгенерировать этот образ через полчаса. Или вариант, когда нужно загрузить очень короткий код, без всяких ОС, страниц памяти и прочего, просто код, который сразу, без всяких долгих инициализаций, запустит двигатели. Остается только один путь - править сам образ или создать этот короткий машинный код. Так что коды есть и будут присутствовать в таких системах, пока процессоры не научатся исполнять язык высокого уровня напрямую :)
Да в текущей ситуации я скорее поверю, что им надо будет сначала загрузить туда 4Мб более свежей виртуальной машины :lol:
Цитировать. Разобраться в таком коде на порядки проще, чем в куче спец инструкций. Сделать ошибку - на порядки сложнее.
Не в защиту асма, но такое ощущение, что вы не в курсе, что такое макроассемблер и библиотека функций :)
Цитировать.
Ну это вас жестоко развели! :wink:
Глупость просто какую-то сказали :) Вы просто не знаете специфики, иначе все встало бы на свои места. Генерация занимает часы, загрузка в тысячи процессоров может занимать часы, возвращение системы в полностью рабочее состояние после перезагрузки может занимать часы. А невыполнение своих функций в течение 30 мин - уже экстренное событие. Правка в коде и система патчинга сделает все то же самое быстрее и мягче с точки зрения всей системы.
ЦитироватьЦитироватьА должны ли быть исключения(ситуативно), если пишется высоконадежный код? Имхо - костыль, наравне с гарбадж коллектом. Надо прибирать за собой - и надо понимать, что происходит в программе.
Исключения как инструмент обработки ошибок настолько же надежен, как дополнительные проверки и даже более надежен, т.к. не зависит от того, забыл кто-то проверить код/флаг ошибки или нет, и не плодит лишний код на эти проверки.
Исключения сами по себе для высоконадежного программирования наносят только вред. В результате ексепшена управление просто вылетает на некий высокий уровень. Где именно произошла ошибка и что теперь делать - непонятно. Переменные потенциально остались в промежуточном непонятном состоянии и можно ли их дальше использовать - неизвестно. Вобщем, поймав эксепшен остается только застрелиться. Такой подход сгодится для программирования окошек, но не для высоконадежного программирования.
Можно конечно взять в скобки try-catch каждое место, где потенциально может быть эксепшен, а так же перехватывать его на всех вышележащих уровнях вложенности вызовов подпрограмм, но это практически то же самое, что передача и анализ кода ошибки.
Впрочем, и в том и в другом случае потенциально опасное место можно просмотреть по невнимательнести. Да и код загромождается - таких мест очень много. Поэтому при совсем правильном подходе анализ потенциальных исключений должен выполняться компилятором, автоматически и гарантированно всегда. Компилятор должен либо убедится в невозможности исключений путем анализа допустимого диапазона входных значений, либо, если это невозможно, заставить программиста сделать явную проверку входных значений или явную обработку исключения в месте его возникновения.
ЦитироватьА вот скажи, 128 битное суммирование на 8 битной машине в Си - исполнении не пробовал? А многобитную криптографию на циклических сдвигах? Но ведь это все простейшие операции при возможности работы с битами состояния процессора (на Асме)!
А зачем нам рассматривать 8-битные машины, когда давно летают 32-битные? Тенденция такова, что ресурсов становится больше, а программирование на аппаратном уровне - сложнее.
Если же ну очень нужно выжать все из архитектуры конкретного контроллера - ну пожалуйста, используйте вставку _asm_ . Но зачем всё корячить на ассемблерной коленке? :D
ЦитироватьА анекдот в том, что на Асме этот плавающий указатель стека тебе даже в голову не придет использовать. Если конечно не пожелаешь пройтись по широко расставленным граблям...
Вот именно, а компилятор сделает и сэкономит 1-2% в объеме исполняемого кода.
ЦитироватьДа и проверки компилятора будут тупы и неэффективны, т.к. будут тупо включены на каждую операцию. На асме всё можно сделать только там где надо и что надо. Например, флаг потери точности при операциях с плавающей точкой - в большенстве случаев пофиг на эту ситуацию, однако в ряде случаев её может быть необходимо обработать. Как указать это компилятору на ЯВУ? Нереально.
Очень просто. При описании каждой переменной с плавающей запятой указвается ее необходимая точность с точки зрения прикладной задачи. Точность результата при арифметических операциях легко определяется статически компилятором исходя из точности операндов. Если результат выражения имеет точность большую или равную точности той переменной, которой он присваивается, все в порядке. Если меньшую - ошибка, программа не обеспечивает заданную в ТУ точность.
ЦитироватьНе в защиту асма, но такое ощущение, что вы не в курсе, что такое макроассемблер и библиотека функций :)
Знаю даже слишком хорошо. Неужели вы будете спорить, что данная запись на С++ выглядит намного проще и понятней, чем последовательность макросов на асме? А ведь это очень простое выражение, бывают намного сложнее.
ЦитироватьГлупость просто какую-то сказали Вы просто не знаете специфики, иначе все встало бы на свои места.
Да я понял. Это была шутка.
Цитировать- ОАО ИСС ведет разработку на собственной кросс-платформе на базе языка Модула-2, которая для покрытия большего числа платформ включает в свой состав фронт-компилятор в язык Си. Т.е. там ассемблера вообще в принципе быть не может ни на каком этапе.
Ну уж прям. :) Некоторые подпрограммы там наверняка на ассемблере. А возможно и ассемблерные вставки в самом коде на модуле-2
ЦитироватьТочность результата при арифметических операциях легко определяется статически компилятором исходя из точности операндов.
Никаких проверок на уровне компилятора здесь не сделать, тем более в каждой операции. Только оценка на уровне алгоритма и выбранных форматов данных. Задачи уменьшения ошибок при интенсивных математических расчетах весьма сложны. И как раз высокие программисты, многие из которых слабо себе представляют машинную арифметику, часто не понимают важности этих задач. Для них все, что в дабле, всегда считается очень точно :) Вообще тут очень большой перекос в сторону формального тестирования непонятно чего. А в жизни правильная концепция, выбранные форматы, карты памяти, архитектура, внешний обмен данными, диаграммы работы и прочие вещи куда сильнее влияют на количество ошибок, чем некие абстрактные тесты или проверки. Ошибки тоже бывают на разных уровнях. Одно дело ошибиться с коэффициентами окна при обработке изображения со звездного датчика, то не приведет к фатальному провалу миссии. И другое дело грубо ошибиться в диаграмме работы, гонках в обмене. Умный, строгий программист подобен гроссмейстеру, он делает ходы на основании большого опыта и базы данных. И выигрывает у компьютера, который просто перебирает варианты на основе формальных сечений.
ЦитироватьВ общем, все это не имеет прямого отношения к БВК АМС.
Экономика и управление ресурсами страны имеют САМОЕ прямое отношение к АМС. Потому что АМС это проекты, находящиеся на САМОМ переднем крае возможностей научной и технологической инфраструктуры страны, а также АМС ПРЕДЕЛЬНО зависят от качества управления и чуть меньше от финансовых возможностей страны.
Теперь что такое я называю нормальными странами.
Буквально я называю нормальными страны где достаточно сильный капитализм.
ЦитироватьКапитализм — экономическая система производства и распределения, основанная на частной собственности, всеобщем юридическом равенстве и свободе предпринимательства.
Более конкретно я предпочитаю такое: в капитализме действует свободное движение капитала - КАЖДЫЙ может СВОБОДНО заработать капитал, а также СВОБОДНО его продать/обменять/сдать в аренду итд.
И вот стран где достаточно большой процент СВОБОДНОГО капитала и являются нормальными, и таких стран в мире совсем мало - это буквально ТОЛЬКО G7 список примерно 1990 года.
Достаточно большой процент начинается где-то от 20%.
Строго говоря, абсолютной свободы капитала нет нигде в мире, тк очевидно космос пока вне рассмотрения, а в нейтральных водах законы действуют недостаточно надежно, а на территории государств всегда есть ограничения.
Например, практически везде есть очень большие ограничения по работе с радиоактивными материалами и прочими опасными технологиями.
НО конкретно механизмы самых ключевых вещей - земля+недвижимость (ДА ОНИ ОБЯЗАТЕЛЬНО ВМЕСТЕ!!!), а также производство материальных и нематериальных товаров, и управление ресурсами страны в нормальных странах действуют предельно эффективно.
Конкретно у нас сейчас не капитализм, а НЕОФЕОДАЛИЗМ.
ЦитироватьФеодализм (от лат. feudum — лен, феодальное землевладение) — тип общества, характеризующийся наличием двух социальных классов — феодалов (землевладельцев) и простолюдинов (крестьян), занимающих по отношению к феодалам подчиненное положение; феодалы при этом связаны друг с другом специфическим типом правовых обязательств, известных как феодальная иерархия.
Отличие неофеодализма от простого феодализма в наличии ФОРМАЛЬНО ЗАДЕКЛАРИРОВАННЫХ, НО НЕ РАБОТАЮЩИХ частной собственности, свободы и равенства. Таким образом оказывается что государственные чиновники становятся феодалами, потому что они могут решать вопросы, которые законным путем не решаются и поэтому они находятся над законом.
ЦитироватьНеужели вы будете спорить, что данная запись на С++ выглядит намного проще и понятней, чем последовательность макросов на асме? А ведь это очень простое выражение, бывают намного сложнее
Все-таки вы исходите из удобства процесса, а не предсказуемости результата. Можете сказать, сколько памяти и где будет использовано при исполнении этой сишной строки? Сколько тактов это займет? Реентрабельна ли эта хрень? И так далее, без конца. А ведь это - очень простое выражение, бывают намного сложнее ;)
За удобство и скорость написания мы расплачиваемся контролем...
извините, был дубль
ЦитироватьЦитироватьНеужели вы будете спорить, что данная запись на С++ выглядит намного проще и понятней, чем последовательность макросов на асме? А ведь это очень простое выражение, бывают намного сложнее
Все-таки вы исходите из удобства процесса, а не предсказуемости результата. Можете сказать, сколько памяти и где будет использовано при исполнении этой сишной строки? Сколько тактов это займет? Реентрабельна ли эта хрень?
Profiler вам в помощь :wink:
ЦитироватьИсключения сами по себе для высоконадежного программирования наносят только вред. В результате ексепшена управление просто вылетает на некий высокий уровень. Где именно произошла ошибка и что теперь делать - непонятно. Переменные потенциально остались в промежуточном непонятном состоянии и можно ли их дальше использовать - неизвестно. Вобщем, поймав эксепшен остается только застрелиться. Такой подход сгодится для программирования окошек, но не для высоконадежного программирования.
Нет, это просто прекрасно! :)
Вы мне напомнили мой давний диалог с одним очень бородатым и очень умудренным опытом программистом на FoxPro, который руководил отделом ИТ в Русславбанке и в частности был отцом их системы банк-клиент по состоянию на 2006-й год. Я тогда регистрировался как ИП и подбирал банк для расчетных счетов. Будучи человеком не далеким от ИТ я естественно расчитывал никак не меньше, чем на нормальную систему управления счетами по инету. Так вот, когда я засыпал операционистку вопросами по банк-клиенту, она просто отвела меня в ИТ отдел и отдала его мне на растерзание. Там мне с ярким пламенем в глазах рассказали про их уникальную систему. Клиент на FoxPro, работавший в dos-box'е, все распоряжения сгружал в папку в виде email, подтверждения операций также приходили обратно по email. Далее в работу вступал замечательный почтовый клиент The Bat!, который требовалось запустить, потом импортировать в него сгенерированную банк-клиентом почту, отправить ее, дождаться ответной почты, экспортировать ее в папку банк-клиента и выполнить синхронизацию в последнем, чтобы увидеть, что же там в итоге получилось. Оценив невероятный успех коллектива, я задал всего два вопроса: "Что за х@#я?" и "Где нормальный веб-клиент?" Если бы у меня была с собой хотя бы отвертка, я бы высек ответ в гранитном полу прямо у них в ИТ-отделе. Потому что поучительным тоном бородатый начальник сообщил мне: "Молодой человек, если бы вы хоть немного бы разбирались в теме, то вы бы знали, что страницы в интернете не позволяют записывать данные". 2006-й год :shock:
В общем блестящий пример, как один страшный порок рождает другой, еще более страшный, асболютно незаметно для жертвы :lol:
Вадим, смотрите - ваша боязнь переполнения стека в совокупности с другими соображениями сделала вас приверженцем статического распределения памяти под переменные. Но этот первый страшный порок и привел вас ко второму - вы теперь не знаете, в каком состоянии ваши переменные после исключения. Что в итоге наталкивает вас на следующий порок в виде суицидальных мыслей :twisted: ну и последующие проблемы, которые вы хорошо описали.
ЦитироватьПоэтому при совсем правильном подходе анализ потенциальных исключений должен выполняться компилятором, автоматически и гарантированно всегда. Компилятор должен либо убедится в невозможности исключений путем анализа допустимого диапазона входных значений, либо, если это невозможно, заставить программиста сделать явную проверку входных значений или явную обработку исключения в месте его возникновения.
На шаг ближе к идеальному компилятору. Подкину вам еще одну идею: при совсем правильном подходе компилятор должен по названию исходного файла сам разобраться, что хочет разработчик, и выдать идеально совершенный код без права на ошибку :)
ЦитироватьProfiler вам в помощь :wink:
Если все потом смотреть профайлером и дебаггером - какой смысл в языке высокого уровня? Особенно учитывая, что вы можете _посмотреть_ что получилось, а _управлять_ результатом - только очень косвенно... А вот например я веду статистику и вижу, что у меня блок памяти стал давать много ошибок - и я хочу его исключить из работы - вот такую возможность надо предусмотреть для КА - это ведь нормально? Свой менеджер памяти надо писать, стандартный не покатит. Вот допустим в параллельно работающих машинах я меряю джиттер по исполнению - и когда он превышает определенную величину, отключаю процессорную секцию - это кем-то уже написано для ЯВУ?
Вполне реально на асме написать с резервированием пары регистров - и когда космические лучи или еще какая хрень выбъет регистр - по результатам тестирования код самомодифицируется и будет использовать резервный регистр. И так далее.
Правда, по нынешним временам наверное дешевле воткнуть 100500 ява-процессоров от разных производителей мобилок по баксу и мажоритарно определять, кто прав...
ЦитироватьЦитироватьProfiler вам в помощь :wink:
Если все потом смотреть профайлером и дебаггером - какой смысл в языке высокого уровня?
Все смотреть не нужно. Смотреть нужно узкие места. Если вы не вписываетесь в отведенный вам квант времени для данной операции - вот там и смотрите. Прописные ж истины...
ЦитироватьА вот например я веду статистику и вижу, что у меня блок памяти стал давать много ошибок - и я хочу его исключить из работы - вот такую возможность надо предусмотреть для КА - это ведь нормально? Свой менеджер памяти надо писать, стандартный не покатит. Вот допустим в параллельно работающих машинах я меряю джиттер по исполнению - и когда он превышает определенную величину, отключаю процессорную секцию - это кем-то уже написано для ЯВУ?
Это все безусловно очень круто, но это логичнее было решать на уровне ОС, а не в СПО.
ЦитироватьВполне реально на асме написать с резервированием пары регистров - и когда космические лучи или еще какая хрень выбъет регистр - по результатам тестирования код самомодифицируется и будет использовать резервный регистр. И так далее.
Я уже видел такое в фильме "Терминатор 2" :!: :twisted:
ЦитироватьПравда, по нынешним временам наверное дешевле воткнуть 100500 ява-процессоров от разных производителей мобилок по баксу и мажоритарно определять, кто прав...
Патентуйте идею! Я просто уверен, что каждый раз отваливать по $200-300k за RADx000 не айс.
ЦитироватьНу и дополним тем, что ваш алгоритм некорректен в смысле отстутствия проверки на переполнение при умножении и сложении. То есть появляетя третья и четвертая, пятая и так далее ветви, на каждой некорректной арифметической операции. Разные процессоры ведут себя по разному. Одни генерируют аварийное прерывание. Другие присваивают значение NAN и умывают руки. Ну а вы, как программист чешете репу и пытаетесь понять, откуда взялись неучтенные ситуации. :wink:
ЦитироватьМаневр "соскок" обнаружен и засчитан :) Ошибки лучше обрабатывать там, где можно принять наиболее взвешенное решение. Данная функция понятия не имеет, как и где она будет использована, поэтому обрабатывать ошибки в ней очень не дальновидно. Механизм исключений придумали не умственно отсталые люди.
Коллеги!
Я считаю что вы оба правы, но вижу что один недопонимает, а другой не может объяснить. Попробую объяснить я.
Суть в том, что действительно обработать ВСЕ ситуации сколько-нибудь сложной системы действительно невозможно, НО возможно декомпозицией разбить сложную систему на совокупность простых систем, каждую из которых проверить точно можно.
И уж извините, но из песни слов не выкинешь - рантайм вроде Ады и Эрланга, с проверками диапазонов переменных и входных параметров во время исполнения позволяет сделать действительно всё надежно, тк блоки кода будут вызываться ТОЛЬКО с заранее протестированными данными.
ЦитироватьСуть в том, что действительно обработать ВСЕ ситуации сколько-нибудь сложной системы действительно невозможно, НО возможно декомпозицией разбить сложную систему на совокупность простых систем, каждую из которых проверить точно можно.
К сожалению, сумма протестированных компонентов не эквивалентна протестированной системе из этих компонентов. :D И здесь начинается самое интересное. Очевидно, что если пытаться верифицировать систему целиком - то комбинаторный взрыв весьма вероятен. Приходится идти на послабления - организовывать асинхронный обмен между компонентами, допуская что физически компонент не ждет данные или команды, а берет их из буфера тогда, когда ему это удобно, а компонент отдающий данные команды игнорирует переполнения буфера. Отдельно верифицируется собственно буфер на предмет его непереполнения. Введение таких развязок и позволяет снизить суммарное количество состояний системы до приемлимого.
Очень интересная дискуссия.
А можно вопрос к разработчикам космического софта?
Есть ли формальные технические требования (format technical requirements), для софта, которые реально НАДО выполнять?
В авиации очень с этим строго, и по сути выбор операционной системы
среды программирования, в основном зависит от формальных (я бы сказал бюрократических) требований, даже во вред эффективности, удобства разработки и функциональности.
Вот например, С++ coding guideline. Читаешь- сердце радуется :-)
http://www2.research.att.com/~bs/JSF-AV-rules.pdf
dup
ЦитироватьВведение таких развязок и позволяет снизить суммарное количество состояний системы до приемлимого.
Снова здравствуй модель асинхронных агентов? Я знал, что в этом что-то есть. ;)
ЦитироватьЦитироватьВозвращаясь к вашей замечательной функции, можно либо явно перехватывать исключение, либо проверить параметры на входе (может быть очень трудно попасть в условия выражения, поскольку любое изменение там должно сопровождаться проверкой входного интервала, что не всегда тривиально для нелинейной функции).
То есть мы возвращаем к основам. Что программист обязан досконально знать архитектуру процессора и используемый формат чисел с плавающей точкой? В таком случае значительно проще будет программировать на ассемблере сопроцессора явно проверяя все флаги и отлавливая исключения.
Кстати даже целочисленное переполнение проще контролировать на ассемблере, т.к. у процессора есть спец. флаг, который из высокоуровневых языков недоступен.
Нет, мы не возвращаемся а идем дальше.
А дальше виртуальная машина, в которой может быть много вариантов работы с переполнениями, от явной проверки данных на соответствие оттестированному диапазону, через обработку флагов переполнений до чисел неограниченной размерности.
Уж извините, из песни слов не выкинуть - в Эрланговской ВМ целые числа имеют размерность ограниченную только объемом ОЗУ.
ЦитироватьВот например, С++ coding guideline. Читаешь- сердце радуется :-)
http://www2.research.att.com/~bs/JSF-AV-rules.pdf
Ух ты. Это просто подарок, вещь! Теперь я знаю куда тыкать мордой брыкающихся молодых жеребцов, то и дело норовящих поставить открывающую "{" не на новой строке :twisted: Lockheed Martin и баста. :!:
Ну и в целом приятно видеть, что за годы разработки были набиты правильные шишки :lol:
ЦитироватьЦитироватьКстати да, существует масса инструментов для Си. Это статические анализаторы кода, рантайм анализаторы и прочее. При грамотной методологии разработки и тестирования можно получить очень надёжных код.
:shock: Это примерно как утверждать, что "очень надежный код можно получить на Ассемблере". Т.к. Си имеет максимально широкие возможности наловить глюков из-за своих широчайших возможностей по доступу к аппаратуре.
Кстати да. Я несколько лет назад писал статью как раз про эти самые анализаторы кода, и тогда пришел к выводу что их огромное количество в случае Си и C++ вызвано слишком большой вольностью в языке, вкупе с низкой выразительностью языка.
Причем для С/C++ есть крайне неприятный момент, что для него например невозможно сделать программу автоматической проверки соответствия стандартам кодирования без привлечения ИИ или ручного труда.
Я не говорю что это проблема только С/С++, но для них это проблема вселенского масштаба ввиду колоссальных объемов готового кода.
ЦитироватьЦитироватьЯ работал с очень сложной системой, где ПО из миллионов строк было написано на языке выского уровня класса Ада. Но мы обязаны были изучить архитектуру процессоров, на которых исполнялся сгенерированный компилятором код, и в экстренных случаях уметь править ПО прямо в коде, потому что иного способа просто не было. Чтобы поправить все в листинге, сгенерировать код заново, понадобилось бы не меньше суток.
Ну это вас жестоко развели! :wink:
Я бы сформулировал по-другому: либо система была НЕграмотно спроектирована или плохо реализована, что любое изменение приводило к перекомпиляции огромного объема кода, либо низкокачественные средства разработки не умеют использовать элементарное кеширование уже скомпилированных блоков кода.
Вобщем в любом случае следствие либо низкого качества управления, либо слаборазвитой инфраструктуры разработки ПО.
ЦитироватьЦитировать.
Ну это вас жестоко развели! :wink:
Глупость просто какую-то сказали :) Вы просто не знаете специфики, иначе все встало бы на свои места. Генерация занимает часы, загрузка в тысячи процессоров может занимать часы, возвращение системы в полностью рабочее состояние после перезагрузки может занимать часы. А невыполнение своих функций в течение 30 мин - уже экстренное событие. Правка в коде и система патчинга сделает все то же самое быстрее и мягче с точки зрения всей системы.
Это не специфика задачи, а специфика недостатков используемых вами инструментов.
- В виртуальных машинах горячая замена отдельных модулей без перезагрузки системы вполне рядовое явление. Такое ТОЧНО есть в Эрланг ВМ (которая BEAM), а также в ВМ исполняющей Enterprise Java Beans (подробности уточню по запросу).
ЦитироватьЦитироватьВведение таких развязок и позволяет снизить суммарное количество состояний системы до приемлимого.
Снова здравствуй модель асинхронных агентов? Я знал, что в этом что-то есть. ;)
Ну дык Эрланг неглупые люди делали :lol:
ЦитироватьЯ бы сформулировал по-другому: либо система была НЕграмотно спроектирована или плохо реализована, что любое изменение приводило к перекомпиляции огромного объема кода, либо низкокачественные средства разработки не умеют использовать элементарное кеширование уже скомпилированных блоков кода.
.
Да, 6 стран и фирмы, капиталистические, по вашему определению, включая Bell Labs, не умеют проектировать, куда им до zyxman. Повторяю, я перестал вас воспринимать серьезно, уж не в обиду. Вы несете бред с гордым видом человека, который не может себе представить ничего из того, что не укладывается в его мирок. И не знаком со многими вещами, как организационными, так и технологическими, а свое незнание трансформирует в стандартный вариант "они дураки, а мы умные". Увы, часто все наоборот. Не пишите мне более по техническим темам.
ЦитироватьЦитироватьТочность результата при арифметических операциях легко определяется статически компилятором исходя из точности операндов.
Никаких проверок на уровне компилятора здесь не сделать, тем более в каждой операции.
Религия запрещает? :) Бездоказательное и ошибочное утверждение.
ЦитироватьТолько оценка на уровне алгоритма и выбранных форматов данных. Задачи уменьшения ошибок при интенсивных математических расчетах весьма сложны.
Именно. Поэтому не стоит делать их в ручную. Человеку свойственно ошибаться.
ЦитироватьИ как раз высокие программисты, многие из которых слабо себе представляют машинную арифметику, часто не понимают важности этих задач. Для них все, что в дабле, всегда считается очень точно :)
Не знаю, как там ваши высокие программисты, а вы даже если и представляете, как устоен дабл и как выпоняются операции над ним, похоже даже не пытаетесь оценивать ошибки. Потому что "все, что в дабле, всегда считается очень точно". ;) Что, впрочем, и не удивительно, потому что это титанический и утомительный ручной труд, если его не автоматизировать. Вот и приходится на авось. Выбрать разрядность числа побольше, потестировать, авось сработает как надо.
ЦитироватьВообще тут очень большой перекос в сторону формального тестирования непонятно чего.
Вообще у вас большая однобокость в представлениях. Ни коим образом не отрицаю разумность ваших утверждений, что разработчик real-time & embedded систем должен представлять, как это все работает на машинном уровне, но этого совершенно недостаточно. Вы программируете по сути не профессиональным, а кустарным методом, на авось и на глазок.
ЗЫ Тот факт, что вы где-то работали и что-то разрабатвали ни коим образом не отменяет сей факт. Такое встречается сплошь и рядом.
ЦитироватьНу по аналогии при необходимости всегда можно сделать библиотеку типов со вставками на асме с такой жесткой проверкой всех операций и генерацией исключений по результатам проверок. Так что даже такая глобальная паранойя вполне реализуется и на ЯВУ.
Можно, но никто этого не делает и не будет делать. Без языковой поддержки типа возможности пергрузки арифметических операторов будет совсем грустно.
ЦитироватьЦитироватьИсключения сами по себе для высоконадежного программирования наносят только вред. В результате ексепшена управление просто вылетает на некий высокий уровень. Где именно произошла ошибка и что теперь делать - непонятно. Переменные потенциально остались в промежуточном непонятном состоянии и можно ли их дальше использовать - неизвестно. Вобщем, поймав эксепшен остается только застрелиться. Такой подход сгодится для программирования окошек, но не для высоконадежного программирования.
Нет, это просто прекрасно! :)
Вы мне напомнили мой давний диалог с одним очень бородатым и очень умудренным опытом программистом на FoxPro, который руководил отделом ИТ в Русславбанке и в частности был отцом их системы банк-клиент по состоянию на 2006-й год. Я тогда регистрировался как ИП и подбирал банк для расчетных счетов. Будучи человеком не далеким от ИТ я естественно расчитывал никак не меньше, чем на нормальную систему управления счетами по инету. Так вот, когда я засыпал операционистку вопросами по банк-клиенту, она просто отвела меня в ИТ отдел и отдала его мне на растерзание. Там мне с ярким пламенем в глазах рассказали про их уникальную систему. Клиент на FoxPro, работавший в dos-box'е, все распоряжения сгружал в папку в виде email, подтверждения операций также приходили обратно по email. Далее в работу вступал замечательный почтовый клиент The Bat!, который требовалось запустить, потом импортировать в него сгенерированную банк-клиентом почту, отправить ее, дождаться ответной почты, экспортировать ее в папку банк-клиента и выполнить синхронизацию в последнем, чтобы увидеть, что же там в итоге получилось. Оценив невероятный успех коллектива, я задал всего два вопроса: "Что за х@#я?" и "Где нормальный веб-клиент?" Если бы у меня была с собой хотя бы отвертка, я бы высек ответ в гранитном полу прямо у них в ИТ-отделе. Потому что поучительным тоном бородатый начальник сообщил мне: "Молодой человек, если бы вы хоть немного бы разбирались в теме, то вы бы знали, что страницы в интернете не позволяют записывать данные". 2006-й год :shock:
В общем блестящий пример, как один страшный порок рождает другой, еще более страшный, асболютно незаметно для жертвы :lol:
Вадим, смотрите - ваша боязнь переполнения стека в совокупности с другими соображениями сделала вас приверженцем статического распределения памяти под переменные. Но этот первый страшный порок и привел вас ко второму - вы теперь не знаете, в каком состоянии ваши переменные после исключения. Что в итоге наталкивает вас на следующий порок в виде суицидальных мыслей :twisted: ну и последующие проблемы, которые вы хорошо описали.
ЦитироватьПоэтому при совсем правильном подходе анализ потенциальных исключений должен выполняться компилятором, автоматически и гарантированно всегда. Компилятор должен либо убедится в невозможности исключений путем анализа допустимого диапазона входных значений, либо, если это невозможно, заставить программиста сделать явную проверку входных значений или явную обработку исключения в месте его возникновения.
На шаг ближе к идеальному компилятору. Подкину вам еще одну идею: при совсем правильном подходе компилятор должен по названию исходного файла сам разобраться, что хочет разработчик, и выдать идеально совершенный код без права на ошибку :)
Содержательных аргументов, нет один художественный свист. Ну и психоанализ личности оппонетна - вообще классика форумной демагогии. :) Так что без комментариев, нечего комментировать.
Цитировать:shock: Это примерно как утверждать, что "очень надежный код можно получить на Ассемблере". Т.к. Си имеет максимально широкие возможности наловить глюков из-за своих широчайших возможностей по доступу к аппаратуре.
Кухонным ножём можно отрезать палец, а можно сделать салат. Аналогия ясна?
Детские ошибки в Си легко отлавливаются различными рантайм чекерами. В совокупности со статическими верификаторами и полноценным тестированием это даст высокую надёжность.
ЦитироватьЦитироватьЦитироватьКстати да, существует масса инструментов для Си. Это статические анализаторы кода, рантайм анализаторы и прочее. При грамотной методологии разработки и тестирования можно получить очень надёжных код.
:shock: Это примерно как утверждать, что "очень надежный код можно получить на Ассемблере". Т.к. Си имеет максимально широкие возможности наловить глюков из-за своих широчайших возможностей по доступу к аппаратуре.
Кстати да. Я несколько лет назад писал статью как раз про эти самые анализаторы кода, и тогда пришел к выводу что их огромное количество в случае Си и C++ вызвано слишком большой вольностью в языке, вкупе с низкой выразительностью языка.
Причем для С/C++ есть крайне неприятный момент, что для него например невозможно сделать программу автоматической проверки соответствия стандартам кодирования без привлечения ИИ или ручного труда.
Я не говорю что это проблема только С/С++, но для них это проблема вселенского масштаба ввиду колоссальных объемов готового кода.
Инструменты эти имеют весьма ограниченную полезность, по той простой причине, что не умеют читать мысли разработчика. Если, допустим, в языке отсутствует возможность сообщить компилятору, какую точность хочет получить разработчик, никакой инструмент это не установит. И - да - С не самый лучший язык для высоконадежного программирования.
ЦитироватьВообще-то это делается еще на этапе создания/наполнения оптимизатора в компиляторе. Как пример могу привести реализацию циклического сдвига на Си для 1 байтного числа которую компиляция очень часто приведет к одной/двум(зависит от камня) процессорным командам с использованием бита переноса.
// циклический сдвиг влево движок форума не пропустил :roll:
x=((x >> 1) | (x << 7)); // циклический сдвиг вправо
Причём тут оптимизатор? Речь о том что языковые средства ЯВУ не позволяют легко контролировать флаги как у процессора так и у сопроцессора. Простая задача сложить два числа и в случае переполнения что то сделать превращается в хакерский трюк вместо простого jo на ассемблере.
ЦитироватьПо моему опыту - с некоторого размера нет! Начинаешь терять суть кода в отдельных кусках. Приходится урезать самому себе набор доступных "хаккерских" приемов т.к. "спецэффекты" вылазят полным ходом в самых разных местах.
А никто и не говорил что будет легко. Стоимость кода для КА на порядок или даже на два и так будет дороже обычного коммерческого кода.
ЦитироватьМогу ограничить объем Асм-кода для одного высококлассного разработчика примерно 40-60кБ (правда туда можно засунуть всю логику работы ФГ ;) ) - дальше время получения надежного кода улетает за десятки лет разработки.
Всю программу действительно нет смысла делать на асме. Высокоуровневую логику, склеивающую функционал, можно сделать на ЯВУ. На асме вполне можно написать расчётные чистые функции и IO.
Особенно для малых контоллеров асм всё ещё применяется. Перед глазами вижу пример какк делают прошивку для блока питания.
ЦитироватьЦитировать:shock: Это примерно как утверждать, что "очень надежный код можно получить на Ассемблере". Т.к. Си имеет максимально широкие возможности наловить глюков из-за своих широчайших возможностей по доступу к аппаратуре.
Кухонным ножём можно отрезать палец, а можно сделать салат. Аналогия ясна?
Однако правильно спроектированный кухонный нож должен быть устроен таким образом, чтобы салат нарезать им было легко, а отрезать нечаянно палец по возможности проблематично. Аналогия ясна? :)
ЦитироватьДетские ошибки в Си легко отлавливаются различными рантайм чекерами.
В рантайме после обнаружения ошибки остается только застрелиться.
ЦитироватьВ совокупности со статическими верификаторами и полноценным тестированием это даст высокую надёжность.
Увы. Статические верификаторы не умеют читать мысли разработчика, а сам язык средств выразить эти мысли компилятору не предоставляет.
ЦитироватьУже и по оптимальности ручной код начинает проигрывать машинно-сгенерированному из С.
Это полуправда. Для современных процессоров Intel компиляторы действительно вылизаны и оптимизированы хорошо, для AMD всё уже значительно не так радужно. Для процессов других архитектур или даже для 186 уже всё очень и очень печально.
ЦитироватьЭто связано с внедрением в БЦВМ гибридных архитектур, векторных процессоров, настраиваемых конвейеров. Попробуйте перемножить матрицы на векторном процессоре на ассемблере. Или попробуйте вручную загрузить конвейер для эффективной обработки той же матрицы. Причем речь не о встроенных конвейерах АЛУ, а именно о внешних, управляемых пользователем. Трансляторы же с ЯВУ делают это значительно лучше.
Эффективный компилятор для архитектуры VLIW (эльбрус, итаниум) так и не написан, т.к. это очень трудоёмкая задача. Ручная загрузка конвеера тут пока позволяет добиваться лучших результатов, особенно в синтетических тестах.
ЦитироватьУж извините, из песни слов не выкинуть - в Эрланговской ВМ целые числа имеют размерность ограниченную только объемом ОЗУ.
А если надо контрольную сумму посчитать или зашифровать чего?
ЦитироватьЦитироватьЦитировать:shock: Это примерно как утверждать, что "очень надежный код можно получить на Ассемблере". Т.к. Си имеет максимально широкие возможности наловить глюков из-за своих широчайших возможностей по доступу к аппаратуре.
Кухонным ножём можно отрезать палец, а можно сделать салат. Аналогия ясна?
Однако правильно спроектированный кухонный нож должен быть устроен таким образом, чтобы салат нарезать им было легко, а отрезать нечаянно палец по возможности проблематично. Аналогия ясна? :)
Вот вы почти уже поняли. Такой нож невозможен без резкого снижения эффективности инструмента. Можно заставить повара работать тупым ножём, чтобы случаем не порезался или не убил кого.
Так что только искуство безопасного управления и применения инструмента даст и результат и безопасность.
ЦитироватьЦитироватьДетские ошибки в Си легко отлавливаются различными рантайм чекерами.
В рантайме после обнаружения ошибки остается только застрелиться.
Имеется ввиду фаза тестирование (debug сборка).
ЦитироватьГлупость просто какую-то сказали :) Вы просто не знаете специфики, иначе все встало бы на свои места. Генерация занимает часы, загрузка в тысячи процессоров может занимать часы, возвращение системы в полностью рабочее состояние после перезагрузки может занимать часы. А невыполнение своих функций в течение 30 мин - уже экстренное событие. Правка в коде и система патчинга сделает все то же самое быстрее и мягче с точки зрения всей системы.
Простите, но похоже Вы так-же не сильно в курсе возможностей СОВРЕМЕННЫХ компиляторов. В них есть возможность раздельной компиляции нескольких кусков проекта, а потом их линковка. Это позволяет не перекомпилировать весь проект при каждом изменении, а только его малую часть в которой эти изменения произошли. Это в разы ускоряет процесс правка-компиляция-проверка.
ЗЫ. Естественно для использования этой возможности надо во первых о ней знать, а во вторых ее использовать. :)
ЦитироватьПростите, но похоже Вы так-же не сильно в курсе возможностей СОВРЕМЕННЫХ компиляторов. В них есть возможность раздельной компиляции нескольких кусков проекта, а потом их линковка. Это позволяет не перекомпилировать весь проект при каждом изменении, а только его малую часть в которой эти изменения произошли. Это в разы ускоряет процесс правка-компиляция-проверка.
Это хорошо, но при этом бинарный патчинг практически невозможен если править непосредственно исходники..
ЦитироватьЦитироватьПростите, но похоже Вы так-же не сильно в курсе возможностей СОВРЕМЕННЫХ компиляторов. В них есть возможность раздельной компиляции нескольких кусков проекта, а потом их линковка. Это позволяет не перекомпилировать весь проект при каждом изменении, а только его малую часть в которой эти изменения произошли. Это в разы ускоряет процесс правка-компиляция-проверка.
Это хорошо, но при этом бинарный патчинг практически невозможен если править непосредственно исходники..
Вот для этого и нужны ВМ с поддержкой понятия модуля кода. Чтобы код системы загружался не целиком и не в жестко прописанные адреса, а был перемещаемым с динамическим связыванием (аналог позднего связывания, только работающий и после загрузки). Плюс в системе должно быть предусмотрено возможность такой перезагрузки на уровне языка и стандартов кодирования, путем исключения сторонних эффектов.
Вобщем получается чистый функциональный подход с асинхронными сообщениями.
Итого конечно на функциональщину и асинхронность будут потери, но зато избавляемся от необходимости кустарщины и получаем полноценное промышленное решение 24/7/365.
ЦитироватьЦитироватьУже и по оптимальности ручной код начинает проигрывать машинно-сгенерированному из С.
Это полуправда. Для современных процессоров Intel компиляторы действительно вылизаны и оптимизированы хорошо, для AMD всё уже значительно не так радужно. Для процессов других архитектур или даже для 186 уже всё очень и очень печально.
..
Эффективный компилятор для архитектуры VLIW (эльбрус, итаниум) так и не написан, т.к. это очень трудоёмкая задача. Ручная загрузка конвеера тут пока позволяет добиваться лучших результатов, особенно в синтетических тестах.
Анекдот про "неуловимого Джо" знаете? - Он неуловимый потому что никому не надо его ловить..
Ну так вот фирма Intel просто традиционно решает проблемы в своих процессорах улучшенным компилятором, а фирма AMD просто сделала такой процессор что там в таком серьезном вылизывании нет необходимости.
С 186 и VLIW ситуация аналогичная, но специфика чуть другая - просто этих процессоров настолько малое количество (в сравнении с Intel x86), что никто не хочет вкладываться в разработку оптимизатора.
ЦитироватьЦитироватьУж извините, из песни слов не выкинуть - в Эрланговской ВМ целые числа имеют размерность ограниченную только объемом ОЗУ.
А если надо контрольную сумму посчитать или зашифровать чего?
Есть у американцев такое мудрое понятие "Good Enough", то есть буквально "Достаточно Хороший".
- Эрланг не предназначен для вещей которые хорошо делаются на ассемблере. Вместо того чтобы доходить до фанатизма и делать одним инструментом всё (за счет обязательных проблем - то-ли трудоемкости использования инструмента, то-ли сложности, то-ли еще чего-то), нормальные люди имеют набор инструментов, каждый под свою область, с универсальным интерфейсом для их совместного использования.
То есть если вам нужно, есть несколько способов подключить к ВМ двоичные модули. Один из способов прилинковка двоичного модуля к ВМ.
Но вообще тк Эрланг был предназначен для телекома, а там есть множество бинарных протоколов, соответственно в язык ввели поддержку работы с бинарными полями - в первом приближении идеология этого расширения похожа на regex. Если хотите распишу подробнее.
И бинарными полями можно при желании "через левое ухо" посчитать что угодно, контрольную сумму даже наверное получится красиво.
Цитироватья вижу море программеров окошек, делающих свою работу спустя рукава, небрежно и плохо
Увы, можно лишь согласиться :( Зачастую еще и сопровождается неумеренным апломбом "я самый умный".
ЦитироватьВы в курсе, что даже один из создателей очень известного языка высокого уровня был ярым противником нагромождения лишних конструкций?
И он прав!
ЦитироватьСборщики мусора, динамическая память и прочие надаппаратные вещи в жесткой среде реального времени - это не плюс
Безусловно.
Цитироватьзадача аккуратности и тщательности при программировании никак не может быть заменена последующими тестированиями
Еще бы. Поэтому важен комплекс мер обеспечения надежности и качества БПО. Напишу подробнее ниже.
ЦитироватьЦитироватьна асме действительно создавать высоканадёжный код... медленно.
По моему опыту - с некоторого размера нет!
Кроме того во весь рост встает проблема совместной работы нескольких программистов над одним кодом
Вот! Голос не мальчика, но мужа! :) Ключевые вещи названы.
ЦитироватьЦитировать- ОАО ИСС ведет разработку на собственной кросс-платформе на базе языка Модула-2, которая для покрытия большего числа платформ включает в свой состав фронт-компилятор в язык Си. Т.е. там ассемблера вообще в принципе быть не может ни на каком этапе.
Ну уж прям. :) Некоторые подпрограммы там наверняка на ассемблере
Да, в публикациях вроде проскальзывало об использовании ассемблера.
Цитироватьвопрос к разработчикам космического софта?
Есть ли формальные технические требования (format technical requirements), для софта, которые реально НАДО выполнять?
В авиации очень с этим строго
Весьма уместный и актуальный вопрос!
На основании известных публикаций приходится сделать вывод, что - увы и ах! - нет. :(
Итак, попробую обобщить.
Для построения высоконадежного ПО БВК АМС (и вообще ПО КА, РБ и РН а также наземных комплесов управления) нужен целый комплекс мер. Мое мнение:
1. Приведение заработной платы и престижа профессии программиста БВК к соответствующих значимости и сложности решаемых задач уровням. Это - необходимое условие! При этом - воспитание ответственности и аккуратности у разработчиков, поддерживаемое комплексом соответствующих организационных мер.
2. Полноценная наземная отработка изделий, включая многоэтапную отладку ПО, включая моделирование внешней среды и использование натурного БВК, интерфейсов и аппаратуры.
3. Выработка минимальных стандартов, обязательных для реализации при создании ПО в отрасли (пример из авиации здесь приводился) , создание нормативной основы в области процессов создания ПО (в виде рекомендаций, требований, стандартов). Аттестация на основе единой шкалы критериев, качества процессов и технологий создания ПО на предприятих отрасли.
3. Активное внедрение в отрасли современных достижений науки и практики в области программной инженерии, включая формальные методы верификации - доказательства правильности, model checking, и пр., проблемно-ориентированных языков спецификаций и программирования.
4. Разработка на основе анализа отечественного и зарубежного опыта базовых принципов методологии и технологии создания высоконадежного отказоустойчивого ПО.
5. Активное использование инструментальных программных средств, позволяющих автоматизировать процессы ЖЦ ПО. За счет этого - снижать по возможности значимость человеческого фактора, обеспечить актуализацию (и автогенерацию!) программной документации самому ПО, сократить трудоемкость и сроки разработки, автоматизировать генерацию и прогон тестов с максимально возможными уровнями покрытия.
6. Создание отраслевой "базы знаний" по принципам, методологии, языкам, моделям, инструментальным средствам разработки высоконадежного ПО для передачи накопленного квалифицированными сотрудниками опыта молодым и обеспечения "связи поколений".
7. Попытка внедрения, где это возможно, принципов "программирования без программистов" когда по спецификации, которую создают специалисты по бортовым системам и логике управления, автоматически строится гарантированно правильная управляющая программа.
Вероятно, при их выполнении надежность ПО систем управления несколько повысится. Какие будут дополнения, предложения?
ЦитироватьА зачем нам рассматривать 8-битные машины, когда давно летают 32-битные?
Потому, что жрать 1 Вт для задачи у которой есть 10мкВт слегка не разумно. На данный момент 8 битники все-же наиболее отлажены, меньше всего жрут и имеют наибольшую надежность.
ЦитироватьЕсли же ну очень нужно выжать все из архитектуры конкретного контроллера - ну пожалуйста, используйте вставку _asm_ . Но зачем всё корячить на ассемблерной коленке? :D
Вставлять вставки не имеет смысла - не эффективно. Как правильно заметили, мелкие куски компилятор делает эффективнее. Тут или все писать на Асме или все на Си.
Ветка ушла в совершенно нерелевантную проблематике сторону, ИМХО.
Кто-нибудь имеет статистику или лиично сталкивался с проблемами в бортовом ПО? Я - да, причеим, с ПО, разработанным с использованием совсем разных инструментальных средств и на разных языках разными подрядчиками. И 90% проблем связаны с алгоритмическими ошибками на ранних стадиях разработки и ошибками в требованиях (технических заданиях).
ЦитироватьСкажите прямо, пока я еще на форуме, вы что-то создали своим руками ? От задумки, квадратов, моделирования алгоритмов на языке высокого уровня, до железа+программ, до тестов образцов, испытаний ? Я - да.
ЦитироватьКто-нибудь имеет статистику или лиично сталкивался с проблемами в бортовом ПО? Я - да
Это только у меня в глазах двоится?
:mrgreen:
ЦитироватьИтак, попробую обобщить.
[....]
Вероятно, при их выполнении надежность ПО систем управления несколько повысится. Какие будут дополнения, предложения?
Всё в принципе верно. Но нужно не столько ПО заниматься, а идти глубже - начиная с определения самой архитектуры борта.
А не по принципу "вот мы тут контроллер наразводили - спаяли, давай программируй!"
ЦитироватьКто-нибудь имеет статистику или лиично сталкивался с проблемами в бортовом ПО? Я - да, причеим, с ПО, разработанным с использованием совсем разных инструментальных средств и на разных языках разными подрядчиками. И 90% проблем связаны с алгоритмическими ошибками на ранних стадиях разработки и ошибками в требованиях (технических заданиях).
Это интересно, только не совсем понятно, что имеется в виду под алгоритмическими ошибками (косяки в спецификациях?). Частично мы как раз и обсуждали методы устранения и борьбы с ними.
ЦитироватьЭто интересно, только не совсем понятно, что имеется в виду под алгоритмическими ошибками.
Алгоритмические - это не когда a*b+c вместо a*(b+c) написали, а когда вообще функцию вызвать забыли.
ЦитироватьКто-нибудь имеет статистику или лиично сталкивался с проблемами в бортовом ПО? Я - да, причеим, с ПО, разработанным с использованием совсем разных инструментальных средств и на разных языках разными подрядчиками
Уважаемый SOE! Крайне интересно. Можно поподробнее, пожалуйста?
ЦитироватьИ 90% проблем связаны с алгоритмическими ошибками на ранних стадиях разработки и ошибками в требованиях (технических заданиях)
В этом случае необходимо среди комплекса моделей, методов, языков необходимо разработать и использовать:
1. Модели семантики управляющих программ и методы их проверки на целостность (непротиворечивость)
2. Модели, строгие языки спецификаций и алгоритмы проверки спецификаций на противоречивость.
3. Методологию анализа и постановки задачи и проектирования БПО, которая будет сводить к минимуму вероятность внесения разработчиками ошибок на этих стадиях жизненного цикла - например, за счет средств, улучшающих взаимопонимание в команде.
Кстати, перечисленные мною выше меры это подразумевают, а не противоречат.
Ну и, с оставшимися 10% бороться специфически "программистскими" заморочками.
Нужно использовать языки с более высоким уровнем выразительности (возможно DSL), провоцировать (а не заставлять) делать маленькие модули.
- Грубо говоря, на Си логика буквально тонет в инклудах и определениях.
ЦитироватьЦитироватьЭто хорошо, но при этом бинарный патчинг практически невозможен если править непосредственно исходники..
Вот для этого и нужны ВМ с поддержкой понятия модуля кода. Чтобы код системы загружался не целиком и не в жестко прописанные адреса, а был перемещаемым с динамическим связыванием (аналог позднего связывания, только работающий и после загрузки).
ВМ тут не поможет. Ибо при обнаружении бага всёравно придётся слать весь модуль целиком, и если но большой, то приплыли. Либо хакерить с байт-кодами виртуальной машины. В тоже время в машинном коде проблему можно разрулить правкой нескольких байт.
ЦитироватьАнекдот про "неуловимого Джо" знаете? - Он неуловимый потому что никому не надо его ловить..
Ну так вот фирма Intel просто традиционно решает проблемы в своих процессорах улучшенным компилятором, а фирма AMD просто сделала такой процессор что там в таком серьезном вылизывании нет необходимости.
С 186 и VLIW ситуация аналогичная, но специфика чуть другая - просто этих процессоров настолько малое количество (в сравнении с Intel x86), что никто не хочет вкладываться в разработку оптимизатора.
Так я об этом и сказал. Оптимизаторы для редких архитектур оставляют желать лучшего. А тупо брать Intel с дескопа и запихивать в железку никто не будет.
ЦитироватьНо вообще тк Эрланг был предназначен для телекома, а там есть множество бинарных протоколов, соответственно в язык ввели поддержку работы с бинарными полями - в первом приближении идеология этого расширения похожа на regex. Если хотите распишу подробнее.
Я знаю, что эрланг нативно поддерживает ASN.1
Но, увы, в реальных протоколах связи с КА он не применяется. И я не знаю почему. Поэтому разбирать пакеты всё равно придётся ручками.
ЦитироватьИ бинарными полями можно при желании "через левое ухо" посчитать что угодно, контрольную сумму даже наверное получится красиво.
Вообщем вы сами признаёте что законченное решение будет в виде фарша из асма, Си и эрланга.
ЦитироватьИтак, попробую обобщить.
Для построения высоконадежного ПО БВК АМС (и вообще ПО КА, РБ и РН а также наземных комплесов управления) нужен целый комплекс мер. Мое мнение:
1. Приведение заработной платы и престижа профессии программиста БВК к соответствующих значимости и сложности решаемых задач уровням. Это - необходимое условие! При этом - воспитание ответственности и аккуратности у разработчиков, поддерживаемое комплексом соответствующих организационных мер.
Тут пункт 0 забыт. Адекватная оценка количества человеко-часов и соотвественно создание коллектива с соответствующими возможностями.
ЦитироватьИ 90% проблем связаны с алгоритмическими ошибками на ранних стадиях разработки и ошибками в требованиях (технических заданиях).
Вот скажем когда входной параметр выходит за пределы допустимого для данной подпрограммы или данный алгоритм не обеспечивает нужную точность это алгоритмические ошибки и ошибки в ТЗ? :)
Цитироватькогда входной параметр выходит за пределы допустимого для данной подпрограммы или данный алгоритм не обеспечивает нужную точность это алгоритмические ошибки и ошибки в ТЗ?
Как правило, ошибки в требованиях (ТЗ, если хотите). Но сделать реализацию, несоответствующую требованиям с теми же проблемами тоже, конечно, можно. Что должно вылавливаться на этапе тестирования, охват которого тоже определяется сильно задолго для реализации. В итоге мы возвращаемся в тех самых 90% случаях к самым ранним этапам процесса. Где ни инструментальные средства, ни тем более язык программирования столь горячо обсуждаемые на этой ветке не фигурируют. А фигурируют стандарты на сам процесс.
ЦитироватьВ итоге мы возвращаемся в тех самых 90% случаях к самым ранним этапам процесса. Где ни инструментальные средства, ни тем более язык программирования столь горячо обсуждаемые на этой ветке не фигурируют. А фигурируют стандарты на сам процесс.
И что сейчас происходит на передовой борьбы с такими проблемами?
ЦитироватьЯ знаю, что эрланг нативно поддерживает ASN.1
Но, увы, в реальных протоколах связи с КА он не применяется. И я не знаю почему. Поэтому разбирать пакеты всё равно придётся ручками.
Насколько я понимаю, ASN.1 это стандарт описания протоколов, по сути то-же что BNF.
Не применяется вероятно потому что КА проектируют люди, которые не хотят далеко уходить от Си, и на Си все привыкли к BNF.
ЦитироватьЦитироватьИ бинарными полями можно при желании "через левое ухо" посчитать что угодно, контрольную сумму даже наверное получится красиво.
Вообщем вы сами признаёте что законченное решение будет в виде фарша из асма, Си и эрланга.
Не обязательно фарш и не обязательно Си. Может быть и ТОЛЬКО Эрланг, и Паскаль, и Модула, да хоть Фортран.
Вообще сейчас один энтузиаст делает императивный язык Reja для Эрланг-ВМ, но Си самый близкий к аппаратуре язык (ближе только ассемблер) и поэтому когда нужно сделать серьезную оптимизацию выбор очевиден. - Для максимальной производительности нужно то-ли либу на Си (ассемблере) линковать к Эрланг ВМ (этим вообще-то понижая надежность ВМ), либо через пайпы обмениваться данными между Эрланг-ВМ и сторонней программой, например на Си.
Меня лично в Erlang/OTP (не сам язык, а язык+ВМ+библиотека OTP и прочий инструментарий и методология) больше всего радует технология всей работы.
А именно, что я могу сделать сначала всё так как мне быстрее разрабатывать или удобнее разрабатывать, а потом на ходу подменять модули например на оптимизированные или на лучше протестированные.
Я понимаю, это возможно жутковато выглядит, как для обсуждения ПО АМС, но реально как раз вся идеология Erlang/OTP буквально для того и сделана, чтобы дорабатывать программу прямо во время полета :D
И таким образом (СТАНДАРТНО поддерживая обновление ПО во время полета) идеология Erlang/OTP позволяет заметно увеличить доступное для разработки время.
Плюс, Erlang/OTP технология действительно эффективно работает с большими распределенными системами, позволяя исключительно эффективно обновлять код на тысячах нод.
ЦитироватьКак правило, ошибки в требованиях (ТЗ, если хотите). Но сделать реализацию, несоответствующую требованиям с теми же проблемами тоже, конечно, можно. Что должно вылавливаться на этапе тестирования, охват которого тоже определяется сильно задолго для реализации. В итоге мы возвращаемся в тех самых 90% случаях к самым ранним этапам процесса. Где ни инструментальные средства, ни тем более язык программирования столь горячо обсуждаемые на этой ветке не фигурируют. А фигурируют стандарты на сам процесс.
Я правильно понимаю, что на базе некачественного ТЗ получается сильносвязанная система, которую сложно изменить/дополнить потом?
ЦитироватьЦитироватькогда входной параметр выходит за пределы допустимого для данной подпрограммы или данный алгоритм не обеспечивает нужную точность это алгоритмические ошибки и ошибки в ТЗ?
Как правило, ошибки в требованиях (ТЗ, если хотите). Но сделать реализацию, несоответствующую требованиям с теми же проблемами тоже, конечно, можно. Что должно вылавливаться на этапе тестирования, охват которого тоже определяется сильно задолго для реализации.
Тестирование, увы, гарантии не дает, поскольку полный охват всех возможных ситуаций невозможен.
ЦитироватьВ итоге мы возвращаемся в тех самых 90% случаях к самым ранним этапам процесса. Где ни инструментальные средства, ни тем более язык программирования столь горячо обсуждаемые на этой ветке не фигурируют. А фигурируют стандарты на сам процесс.
Да как сказать. Правильный язык разработки сам поддерживает определенный стандарт разработки. Скажем, если он требует указать точность, с которой должна вычисляться переменная, или допустимые пределы значений, то программист вынужден будет спросить их у составителя ТЗ, даже если они в ТЗ не указаны. А составитель ТЗ включить голову и подумать, какими они должеы быть, дополнить ТЗ. А если язык не требует, то составитель не указал, программист запрограммировал с какой-нибудь точностью и диапазоном (как получилось) а потом на поздних этапах или тестировании выясняется, что все это не годится и надо переделывать. И хорошо если не в полете.
ЦитироватьПравильный язык разработки сам поддерживает определенный стандарт разработки. Скажем, если он требует указать точность, с которой должна вычисляться переменная, или допустимые пределы значений, то программист вынужден будет спросить их у составителя ТЗ, даже если они в ТЗ не указаны....
Не факт. В цейтноте требования указывать точность нередко приводят к тому что программист просто физически не успевает спросить, и просто берет самый большой доступный диапазон, и дальше получается строго по вашему тексту, тк протестировать уже не представляется возможным :D
Но вобщем поддерживаю точку зрения, что язык ВМЕСТЕ с инструментами (рантайм, IDE, отладчики, эмуляторы, либы, всяческие CVS, анализаторы кода итд), действительно могут повлиять на выбор технологии, ограничивая либо не ограничивая возможности разработчиков.
ЦитироватьНо сделать реализацию, несоответствующую требованиям с теми же проблемами тоже, конечно, можно. Что должно вылавливаться на этапе тестирования, охват которого тоже определяется сильно задолго для реализации.
Полная ерунда. Вы пытаетесь привязать лошадь позади повозки :D. Определение тестовых планов начинается где-то в середине реализации, когда уже ясны схемные очертания реального а не запланированного продукта. Где-то за два-три месяца до выхода продукта на испытания к нему подключаются тестеры и начинают с ним играть, еще не сообщая разработчикам о каких либо проблемах, поскольку это бессмысленно - код меняется. И где-то за месяц до испытаний начинается настоящее тестирование. Сроки приблизительные, но где-то так.
ЦитироватьНе факт. В цейтноте требования указывать точность нередко приводят к тому что программист просто физически не успевает спросить, и просто берет самый большой доступный диапазон,
Пусть берет. Большая точность это не страшно, проблема когда меньшая. Если обеспечивается большая точность, то все норм.
Цитироватьи дальше получается строго по вашему тексту, тк протестировать уже не представляется возможным :D
Тестировать что? Точность проверяется компилятором, ее тестировать уже не нужно.
ЦитироватьЦитироватьпротестировать уже не представляется возможным :D
Тестировать что? Точность проверяется компилятором, ее тестировать уже не нужно.
Только при условии корректного программирования. Достаточно ошибочно привести к более узкому типу и вы огребли проблем. Компилятор будет молчать - ему заткнули рот явным приведением типа. Однако тестер обязан это найти. :D
ЦитироватьЦитироватьЦитироватьпротестировать уже не представляется возможным :D
Тестировать что? Точность проверяется компилятором, ее тестировать уже не нужно.
Только при условии корректного программирования. Достаточно ошибочно привести к более узкому типу и вы огребли проблем. Компилятор будет молчать - ему заткнули рот явным приведением типа. Однако тестер обязан это найти. :D
В правильном языке компилятору нельзя заткнуть рот приведением типа. Да и приведения типа как такового там не должно быть. Если узкому типу присваивается более широкий тип это ошибка. Единственный вариант - сделать явную проверку в коде, что значение широкого типа действительно попадает в узкий тип. Тогда внутри
if широкий тип становится узким и присваивание допустимо. Без всякого приведения типа.
И тестировать это все-таки уже не нужно. Все проверяется компилятором. :)
ЦитироватьВ правильном языке компилятору нельзя заткнуть рот приведением типа. Да и приведения типа как такового там не должно быть. Если узкому типу присваивается более широкий тип это ошибка. Единственный вариант - сделать явную проверку в коде, что значение широкого типа действительно попадает в узкий тип. Тогда внутри if широкий тип становится узким и присваивание допустимо. Без всякого приведения типа.
И тестировать это все-таки уже не нужно. Все проверяется компилятором. :)
Тут проблема, что нужно будет заранее просчитать все допустимые для ширины типа диапазоны входных значений. И это ОЧЕНЬ рутинный трудоемкий процесс, который тоже может принести ошибок.
Например, для y=x*x тип X должен быть более узким чем тип y. И если для такого простого случая можно действительно компилятором автоматически посчитать диапазоны, то для автоматизации более сложных случаев нужно либо ИИ либо тестирование.
Ну а даже если у вас этот самый IF поймал выход за пределы диапазона, что вы будете делать? - На этапе тестирования можно уточнить определение кода, а на этапе работы это просто песец - в лучшем случае сейф мод и срыв графика (ибо очевидно что на АМС компьютер не в тетрис играет), а в худшем случае провал миссии ввиду неисполнения критичных ко времени операций.
ЦитироватьВ правильном языке компилятору нельзя заткнуть рот приведением типа. Да и приведения типа как такового там не должно быть.
Да вы маньяк :D Вы сейчас говорили о каком то реальном языке, или о желаемом?
И как вы, например, будете приводить вещественыый тип к целочисленному и наоборот?
ЦитироватьТут проблема, что нужно будет заранее просчитать все допустимые для ширины типа диапазоны входных значений. И это ОЧЕНЬ рутинный трудоемкий процесс, который тоже может принести ошибок.
Все вполне считается компилятором. Но думать и писать действительно надо больше, нежли программирование "абы как". Это плата за надежное ПО. Альтернатива - ПО с багами.
ЦитироватьНапример, для y=x*x тип X должен быть более узким чем тип y. И если для такого простого случая можно действительно компилятором автоматически посчитать диапазоны, то для автоматизации более сложных случаев нужно либо ИИ либо тестирование.
Тестирование не гарантирует отсутсвие багов.Оно гарантирует их наличие ;)
ЦитироватьНу а даже если у вас этот самый IF поймал выход за пределы диапазона, что вы будете делать?
Реагировать в зависимости от задачи. Условный пример. Допустим, гироскоп выдает значение угла поворота от 0 до 360 градусов. Если мы получили значение вне этого диапазона, значит он неисправен. Нужно пометить его как неисправный и работать дальше на оставщихся гироскопах. Если это невозможно, перейти на ориентацию на звездных датчиках. Если опять невозможно то перейти в закрутку на солнце. Ну вобщем идея понятна, надеюсь :)
ЦитироватьЦитироватьВ правильном языке компилятору нельзя заткнуть рот приведением типа. Да и приведения типа как такового там не должно быть.
Да вы маньяк :D Вы сейчас говорили о каком то реальном языке, или о желаемом?
О желаемом ессно. Я еще на бог знает какой странице написал, что адекватных инструментов нет. Есть отдельные правильные фичи в разных языках, но нужной их комбинации нет ни в одном.
ЦитироватьИ как вы, например, будете приводить вещественыый тип к целочисленному и наоборот?
Зависит от выполняемой задачи. Есть масса способов: округление к ближайшему, округление к меньшему, округление к большему, возможны еще варинаты. Берете соотвествующую функцию и округляете.
У вас проблемы в личной жизни, на работе, в проекте ? Не отчаивайтесь! Отправьте байт-код 01001010 на адрес "Компилятор" (услуга платная, 1.5 млрд руб, с учетом НДС), и ваша проблема будет решена, о чем вы получите смс-уведомление :)
ЦитироватьЦитироватьТут проблема, что нужно будет заранее просчитать все допустимые для ширины типа диапазоны входных значений. И это ОЧЕНЬ рутинный трудоемкий процесс, который тоже может принести ошибок.
Все вполне считается компилятором. Но думать и писать действительно надо больше, нежли программирование "абы как". Это плата за надежное ПО. Альтернатива - ПО с багами.
Я об том, что пока известен только один метод верификации - фактически переборный ИИ - для простых случаев он уже уверенно работает, но для общего случая необходимая вычислительная мощность стремится сами знаете куда.
Более реальный вариант автогенерируемые тесты на весь диапазон допустимых значений, плюс что-нить вроде наказания долларом за слишком широкие диапазоны.
ЦитироватьЦитироватьНапример, для y=x*x тип X должен быть более узким чем тип y. И если для такого простого случая можно действительно компилятором автоматически посчитать диапазоны, то для автоматизации более сложных случаев нужно либо ИИ либо тестирование.
Тестирование не гарантирует отсутсвие багов.Оно гарантирует их наличие ;)
Не понятно значение данной фразы в этом контексте.
ЦитироватьЦитироватьНу а даже если у вас этот самый IF поймал выход за пределы диапазона, что вы будете делать?
Реагировать в зависимости от задачи. Условный пример. Допустим, гироскоп выдает значение угла поворота от 0 до 360 градусов. Если мы получили значение вне этого диапазона, значит он неисправен. Нужно пометить его как неисправный и работать дальше на оставщихся гироскопах. Если это невозможно, перейти на ориентацию на звездных датчиках. Если опять невозможно то перейти в закрутку на солнце. Ну вобщем идея понятна, надеюсь :)
Да, тут понятно. Только хочу сказать, что вы тут изобретаете велосипед - эрлангисты примерно так и поступают с выходом за диапазон допустимых в смысле оттестированных входных значений.
Во первых, просто принципиально код пишется ТОЛЬКО для тех диапазонов для которых есть уверенность что они встречаются в задаче.
Во вторых, при выходе за диапазон принципиально всегда генерируется исключение, далее обработка передается на уровень выше и там и принимается окончательное решение. Если на уровне выше решение не может быть принято, исключение передается выше, и выше, и выше, вплоть до уровня ВМ, где уже соответственно происходит сейф мод (если у нас даже солнечные датчики не работают, то уже всё, прилетели..)
ЦитироватьЦитироватьЯ знаю, что эрланг нативно поддерживает ASN.1
Но, увы, в реальных протоколах связи с КА он не применяется. И я не знаю почему. Поэтому разбирать пакеты всё равно придётся ручками.
Насколько я понимаю, ASN.1 это стандарт описания протоколов, по сути то-же что BNF.
Не применяется вероятно потому что КА проектируют люди, которые не хотят далеко уходить от Си, и на Си все привыкли к BNF.
Да, это стандарт формальных описаний структур данных. Позволяет автоматизировать сериализация/десериализация.
Наезд на Си тут несправедлив, т.к. этот стандарт вырос именно из Си, и существует масса компиляторов из ASN.1 в Си. Причина тут опять скорее всего в специфике КА, когда нужен полный контроль на данными на всех уровнях иерархии.
ЦитироватьНе обязательно фарш и не обязательно Си. Может быть и ТОЛЬКО Эрланг, и Паскаль, и Модула, да хоть Фортран.
Это возможно только на серийной платформе. Если перед вами голая специфическая железка, то трудозатраты на поднятие инфраструктуры для ЯВУ будут слишком велики. Только если размазать эти затраты по многим проектам.
Цитироватьпока известен только один метод верификации - фактически переборный
На сегодня известны следующие подходы к верификации ПО:
1. Группа формальных методов
2. Инспекции кода (взаимный просмотр, экспертный метод)
3. Группа методов, связанных с тестированием (исполнением)
Причем в данных группах имеются различные варианты конкретных методов, например, к формальным относят, кроме методов дедуктивных выводов о корректности программ, метод проверки моделей (model checking), а исполнение может являться, к примеру, символическим.
господа, а никто не в курсе - концепции построения надежных систем из ненадежных компонент не прижились в каком-то виде в бортовых машинах?
Цитироватьгоспода, а никто не в курсе - концепции построения надежных систем из ненадежных компонент не прижились в каком-то виде в бортовых машинах?
Прижилась. В виде троирования (резервирования).
а что-то не столь тривиальное? типа роевых систем/нейросетей/кластерных систем? Организация ECC озу в райд6 хотя-бы с подключением из резерва по необходимости? То-же для процессоров?
Цитироватьа что-то не столь тривиальное? типа роевых систем/нейросетей/кластерных систем? Организация ECC озу в райд6 хотя-бы с подключением из резерва по необходимости? То-же для процессоров?
Весит много, эффект невелик. Гораздо эффективнее повышать надежность существующих резервированных компонентов - например улучшать радиационную стойкость оных.
Университетские же разработки безусловно есть.
понял. А негде глянуть на эти разработки?
Цитироватьпонял. А негде глянуть на эти разработки?
Почитайте публикации, например, вот этого гражданина
http://www.csail.mit.edu/user/816
ЦитироватьProf. Williams' research concentrates on model-based autonomy -- the creation of long-lived autonomous systems that are able to explore, command, diagnose and repair them selves using fast, commonsense reasoning.
Спасибо!