Не я, но постараюсь не забыть. Но что-то у меня не открывается alternathistory. Власти скрывают, что ли…
Эт ты сейчас с кем разговаривал)))
Я поискал копии
https://pikabu.ru/story/kak_odin_malenkiy_bag_ugrobil_28_amerikantsev_5673436
и ещё
https://drgrand.livejournal.com/60060.html
Почитайте, очень познавательно, как ребята в двух разных частях системы имели расходящиеся со временем временные шкалы
@ЕвгенийП , вот цитата из той статьи
“Внутренний таймер ЗРК Patriot устроен как счетчик количества интервалов времени, прошедшего с момента включения системы. Длина такого интервала — 0,1 секунды. Чтобы перевести количество этих отрезков в секунды, его, понятное дело, нужно разделить на 10. Что для этого предложили разработчики? Естественно, умножить на 0,1.”
А зачем вообще переводить в секунды? Так и измеряли бы время в количестве этих интервалов, т. е. в децисекундах. Это целочисленная арифметика и ошибка бы не накапливалась. Что скажете?
1 лайк
Насколько я понял - в lastSec-что-то там читается с сервера и это время считается точкой отсчета?
Однако - запись МК1 и чтение МК2 происходят в разные моменты времени. Цифирь одна, а физическое время разное.
Плюс - TCP-пакет может задержаться , у него негарантированное время доставки. Поправки на скорость прохождения не производятся.
Плюс - ESP8266 приоритетно на одном ядре обслуживает вайфай, а не пользовательский код. Т.е. цифирь со временем от МК1 может попасть на сервер позже, а на МК2 ещё позже.
И т.д. и т.п.
Т.е. тут синхронизация такая же, как бы два в умат пьяных мужика пытались одновременно на снегу желтым определенную фигуру выписывать.
Логически рассуждая, применив алгоритм отправки с разными интервалами, вы, вроде , имеете железную вероятность избежать коллизий. Однако, на шкале реального времени такой алгоритм покажет столкновения ничем не лучше илии хуже рандомайза. Это все, что я пытался донести.
Я не настолько знаком с системой управления “патриотов”, чтобы знать какие там у них были ограничения и проблемы, потому ничего не скажу. Скажу только, что при разработке отечественных систем “с другой стороны” (в смысле бортовых вычислителей, которые на изделиях стоят) иногда приходилось сталкиваться с совершенно неожиданными ограничениями и проблемами, которые зачастую и обуславливали “через-заднепроходные” технические решения. Думаю, что у американских коллег то же самое. Это же профессиональная деятельность, а она везде одинаковая.
Иногда маразм залазит в ТЗ в виде скромной опечатки, а потом … изменить ТЗ - это пройти ад согласований на полгода и напрочь провалить график разработки, проще его (маразм) исполнить 
В lastSec получаем количество сек с момента последней записи в канал.
Читается как детектив
Чуть получше, чем я полагал, но всё равно - синхронизация достаточно условная. Впрочем, если не сбоит и юридических последствий не порождает - только рад за успех.
Вот, кстати, свеженький пример. В 2018 у решили разработать несекретную (!!!) гиперзвуковую ракету-мишень “Гвоздика”. Там в ТЗ из-за того, что правили Word копипастом с последующим подправлением, допустили опечатку (скопипастили кусок, а подправить в нём забыли) в последовательности отстыковки кабелей в момент пуска. По идее там вплоть до самого пуска бортовые системы питаются извне, а перед самым пуском системы переводятся на бортовое питание, а внешние кабели отстреливаются (они на пироразъёмах). Так перепутали последовательность перевода на бортовое питание и отстрела. Вносить исправления? Полгода - минимум! Делать с нарушением ТЗ - сесть можно. Вот и делали … по ТЗ.
Выкрутились! Насколько я знаю, изделие сдали в срок, хотя … это был ужас. Прикиньте как вообще можно сделать несекретную ракету - это ж никакие наработанные узлы использовать нельзя - они все секретны.
Не про эту ли ракету сочинено следующее хокку:
"Дымилась, падая, ракета.
И от нее бежал расчет… "
1 лайк
Не знаю. “Гвоздика”, вроде, успешно летает.
Что за “двоичное число 0,00011001100110011001100”, упоминаемое в рассказе про пэтриот, интересно…
Давно ли в “двоичных числах” запятые ввели? ))
С интересом прочитал, но несколько был шокирован одной цифрой, а именно: время в системе, если верить автору, измерялось с дискретностью 0.1 с. При указанной скорости ракеты 1700 м/с это соответствует неопределенности в ее положении 170 м.
Насколько нам сейчас известно, стандартным квантом времени для МК является 1 мс = 0.001 с (для и для ПК типа Wintel 1 мс - это минимальный размер кванта, хотя по умолчанию он, конечно, больше).
Я думаю, либо автор тупо пропустил два нуля и речь идет об обычном кванте 1 мс (путь ракеты 1.7 м), либо просто перепутал миллисекунды с секундами, и речь идет о кванте 0.1 мс (путь ракеты 17 см).
Я думаю, “разные части системы” - это:
- радар,
- командный пункт,
- пусковая установка,
- ракета.
В каждой из этих частей был собственный блок управления, причем, вероятнее всего, на уникальной для этой части элементной базе. Т.е., говоря современным языком, МК во всех этих частях стояли разные. Вполне вероятно, разрабатывались они также разными группами программистов. Руководству у них, естественно, было общее, ну и кто-то отвечал за взаимодействие.
Это вопрос сложный и неоднозначный.
Первоначально вообще в любых вычислениях рекомендовали пользоваться ПИ-теоремой и переводить все величины к безразмерному виду. Теоретически так можно было минимизировать объем вычислений для конкретной задачи. (я веду речь не об МК, а вообще обо всех вычислениях, включая серьезный научные задачи на мейнфреймах)
Но в дальнейшем быстро пришли к выводу, что такой подход чреват многочисленными труднообнаруживаемыми ошибками, и в последующих рекомендациях уже придерживались мнения, что вычисления разумнее проводить в естественных физических величинах.
Вполне возможно, что разработка Patriot уже велась, исходя из последних рекомендаций.
Обычное двоичное число с фиксированной точкой:
0, - 1 - это разряд единиц,
0 - 0.5 - это разряд половинок,
0 - 0.25 - это разряд четвертинок,
0 - 0.125 - это разряд восьмых,
1 - 0.0625 - это разряд шестнадцатых,
1 - 0.03125 - это разряд тридцатьвторых,
0 - 0.015625 - это разряд шестьдесятчетвертых,
0 - 0.0078125 …
…
Система же первоначально не рассчитывалась на гиперзвуковые цели и пресловутая ошибка может быть связана именно с этой доработкой.
Это частота сканирования неба - нормальная до появления гиперзвуковых ракет. У Патриотов она такая и есть.
Данная ракета (кстати, очень древняя!!!) (SCUD, она же 8К14) чисто баллистическая с высокой траекторией, т.е. она очень быстрая. В атмосферу входит по сути на гиперзвуке. Потому, с нею у Патриотов изначально были проблемы и их патчили под ракеты такого типа раньше. Но всё же скорость 8К14 пока ещё нормальна и 10 герц на сканировании вполне работает.
Здесь нельзя слишком мельчить. Если сканировать слишком часто, то ракета не успеет сместиться настолько, чтобы по двум засечённым точкам построить её траекторию с достаточной точностью. Вот Вы привели пример “1.7 м” - что Вам даст то, что Вы засечёте ракету в двух точках на таком расстоянии? Это расстояние в зоне погрешности измерения расстояния до ракеты, а значит в реальности Вы будете иметь не две точки а по сути одну (с учётом погрешности измерений) и ничего не сможете сказать о траектории (хоть с какой-то достоверностью). А 170 метров - очень хорошее расстояние, всё с ним в порядке.
1 лайк