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

[Дмитрий Виницкий]

Гм, а как же с аудиовыходом? Или это не та?

[Aleks1961]

Гм, а как же с аудиовыходом? Или это не та?

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

[Not]

Оптоэлектронная развязка должна присутствовать на всех внешних портах ПК.

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

Вообще-то зависит от ПК. На многих есть. Но по сути вы правы - рисуем трансформатор с двума обмотками.

[KapYar]

Гм, а как же с аудиовыходом? Или это не та?

Ну да, пожалуй, "на коленке" быстрее всего взять сетевой трансформатор 220/12, делитель и подать на вход звуковой. При частоте дискретизации 44.1 кГц погрешность будет около 0.1%, то есть примерно 0.06 Гц. Хотя я так и не понял, как это относится к БВК АМС.

[Дмитрий Виницкий]

Гм, а как же с аудиовыходом? Или это не та?

Попробуйте подключить или выключить аудиоустройство, если ПК не перегружается  аудиовыход гальванически развязан. Были случаи, особенно у интегрированных :!:

Честно говоря, ничего не понял, но, полагаю, с моим HP Pro 3125, ничего не случится. Иначе, они бы забодались чинить.

[Aleks1961]

Гм, а как же с аудиовыходом? Или это не та?

Попробуйте подключить или выключить аудиоустройство, если ПК не перегружается  аудиовыход гальванически развязан. Были случаи, особенно у интегрированных :!:

Честно говоря, ничего не понял, но, полагаю, с моим HP Pro 3125, ничего не случится. Иначе, они бы забодались чинить.

При работающем! Уже поправил!

[zyxman]

усреднением мы мало что получим - скорее поймаем периодичность загрузки Windows, поскольку RS232 не гарантирует величину задержки - там есть понятие ожидания приема.

Возникает вопрос, что именно будем мерять?
- Вы хотите именно точно мерять периоды и фиксировать все короткие выбросы?
Просто я вот этим вариантом "из г-на и палок" собирался мерять количество импульсов за несколько минут - там буферизация будет очень слабо влиять, потому что импульсов во много раз больше чем размеры буферов. Конкретно если хотим точность 0.1% нужно мерять: 16*1000/50=320секунд минимум (16 размер буфера).
Можно и час мерять и сутки - в данной постановке не проблема :wink:

У меня тоже простейший измеритель выдает 59.9 - 60.0. Но речь то идет о более точном измерении.

Насколько более точном?

PS А насчет однокристалки надо подумать - кварцы у меня конечно есть, но дадут-ли они метрологическую стабильность при доступном в данный момент качестве исполнения? - Все-же компьютер у меня хоть как-то калиброван и постоянно подстраивается по ntp, а однокристалку я еще не готов по ntp подстраивать - ну то есть можно, но небыстро

[Not]

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

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

Это касается и построения аппаратной части, и выбора языка программирования, и выбора абстракций: синхронные или асинхронные, конечные автоматы или простой процедурный код.

[Ded]

Это моя точка зрения, но ПО должно:

1. Всегда находить решение.
2. Откатываться назад при нештатке как в аппаратуре, так и в ПО.

А главное - оно должно не мешать спасению КА.

[Unispace]

Главное, чтобы все было сделано грамотно и аккуратно, с вниманием к мелочам, и не на авось. Что в ПО, что в баках с горючим.

Вы знакомы с термином "тавтология" ?  

А как же. А вы знакомы с термином "когерентное накапливание", применительно к процессу познания и совершенствования ?  

[Unispace]

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

Это касается и построения аппаратной части, и выбора языка программирования, и выбора абстракций: синхронные или асинхронные, конечные автоматы или простой процедурный код.

Ничего особенного выдумывать не нужно. Потому что уже лет 50 существует разное ПО, на 2-3 порядка сложнее ПО ФГ, и оно работает. Все та же компетентность, четкость, прилежность, аккуратность, опыт. А то создается впечатление, что тут пишет очень много тестировщиков ПО, QA и прочее, крен в сторону.... Это все дело хорошее и нужное, но все-таки вспомогательное. Хороший инженер - генератор встроенного кода может при устремлении к пределу обойтись без проверок, а проверки без наличия кода никому не нужны.

[Feol]

С точки зрения практики, сказано совершенно точно

[zyxman]

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

Это касается и построения аппаратной части, и выбора языка программирования, и выбора абстракций: синхронные или асинхронные, конечные автоматы или простой процедурный код.

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

Я на данный момент знаю програмную систему Erlang/OTP, которая включает систему мер для высоконадежного программирования:
1. а "чистый" функциональный язык с переменными с однократной записью вообще не позволяет изменять переменные и этим избавляет от сторонних эффектов.
1.б Язык с автоматическим распределением памяти.
1.в язык построен так, что при разработке "автоматически" получается слабосвязанная система, которую легко изменять/дополнять

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

[Unispace]

zyxman пишет:
 

Я на данный момент знаю програмную систему Erlang/OTP, которая включает систему мер для высоконадежного программирования:
1. а "чистый" функциональный язык с переменными с однократной записью вообще не позволяет изменять переменные и этим избавляет от сторонних эффектов.
1.б Язык с автоматическим распределением памяти.
1.в язык построен так, что при разработке "автоматически" получается слабосвязанная система, которую легко изменять/дополнять

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

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

[zyxman]

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

Хотелось-бы ваши аргументы.

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

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

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

PS Это всё даже если не учитывать тот момент, что разработчики АМС также косвенно влияют на уровень техники страны, тк очевидно часто занимаются не только АМС а и разработкой других высокотехнологических систем.

[zyxman]

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

[Дем]

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

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

[zyxman]

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

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

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

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

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

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

Язык должен быть высокого уровня, тк на низком уровне человек быстрее устает, и больше делает ошибок на тех-же объемах ТЗ.

[Unispace]

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

Хотелось-бы ваши аргументы.

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

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

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

PS Это всё даже если не учитывать тот момент, что разработчики АМС также косвенно влияют на уровень техники страны, тк очевидно часто занимаются не только АМС а и разработкой других высокотехнологических систем.

В АМС нет задачи максимизировать эффективную загрузку. Многозадачность в АМС никоим образом не может увеличить эффективность использования ресурсов процессорного модуля, и это не система массового обслуживания. Защита памяти. Чтобы говорить об этом предметно, нужно знать конкретную реализацию процессорного модуля и его подсистемы памяти. Как увеличена производительность программиста (читайте - послабление для ленивых) от введения абстракций, мы видим на своих PC. Приложения, которые обязаны летать, работают медленно и очень медленно. Эти абстракции оказались нужны в первую очередь для того, чтобы заставить покупать все новые и новые PC, с большими тактовыми частотами и количеством памяти. Я хорошо помню этот переход и удивление людей, которые могли просчитать скорость работы ПО, написанного с применением старых техник и новых, с "абстракциями". За безмятежное существование программистов "абстракций" и создателей всевозможных нагромождений из протоколов и стандартов вы платите из своего кармана. Конечно, если вы сами не программист этих абстракций. Причем образовался еще и перекос в оплате труда. С абстракциями работать выгоднее, часто в несколько раз. Процессор перемалывает пустые массивы и команды, сгенерированные в угоду абстракциям, а реклама в это время призывает купить следующий N-тиум. Но к АМС это не имеет отношения. Моя мысль заключается в том, что нет большой разницы, на чем там написано. И качество ПО может быть обеспечено не каким-то особым углубленным выбором языка, подхода, платформы, тестирования, а прежде всего человеческим фактором. А вот защита от аппаратных сбоев - это уже отдельная тема. Выбор того или иного решения защиты от таких сбоев будет влиять на выбор тех самых платформ ПО и всего, что связано с софтом. Разработка АМС -  не та сфера, которая двигает компьютерное железо и софт. В этой сфере как раз возможен очень консервативный подход к проектированию цифровой вычислительной системы, без излишнего увлечения абстракциями и новомодными веяниями.

[Not]

У Unihorna смешались в кучу кони, люди... Зарплата, абстракции, многозадачность, реклама, и еще бог знает что. Давайте так:

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