Comments 42
Ножницы сработали 20 раз — значит, на линии должно быть 20 изделий. Логично? Логично
Но ведь 21, разве нет? Или изделием считается, условно, только правый отрезанный кусок, а всё что слева ещё нет?
Да, мы считаем те куски, что уже отрезаны. Как колбасу на бутерброд режем — сколько раз отрезали, столько кусков и получилось. Понятно, что в конце серии останется еще кусок, но это немного другая история с точки зрения алгоритма.
МНЛЗ в идеале льет непрерывную полосу (сляб), и тот кусок, который остался слева, ещё привязан к МНЛЗ, поэтому не является отдельным и не учитывается. Грубо, слева от ножниц всегда есть сталь, которую МНЛЗ подает вперед, поэтому каждое срабатывание ножниц на выходе - один отрезанный кусок, а остатку взяться неоткуда - нет второго конца.
Пасибки. Напомнили мне построение мат. модели авто на треке при подготовке к соревнованиям сына Робофест-217, где он занял первое место в квалификационных заездах с большим отрывом и третье в финале. Просто не повезло, никто не ожидал, но .. физика там тоже продемонстрировала Шредингера и даже дважды.
Также .. вроде бы трение шины о полотно выражается вот такой формулой в повороте .. ззамеряем и .. получаем что резина от Лего по рекламному баннеру имеем к-т трения .. больше единицы! Но, ведь так не бывает, верно? не всегда, не всегда.. бывают нюансы.
Или ПИД-регулятор мотора колеса .. в общем, пасибки. Напомнили. Читал как детектив, хорошо написано.
Коэффициент трения, кстати, бывает больше единицы. ЕМНИП резина по асфальту в справочнике имела разброс от чего-то вроде 0.6 до трех, что ли, было это лет 30 назад. Но этот коэффициент есть соотношение сил, а не передача энергии, поэтому ему ничто не мешает быть больше единицы.
Если коэффициент равен единице, то шины можно хранить на вертикальной стене без крепежа. Если больше - то на потолке.
В реальности, для рекордов, примерно так и поступают - мажут разгонную полосу специальным клейким составом и/или прогревают резину до состояния когда она липнет. Так и получают время разгона до 100 меньше 100/(3.6 *9.8) = 2.8c
На стене ни при каком коэффициенте хранить не получится. Можно легко посчитать при каком угле наклона деталь начнёт соскальзывать. Получается, что тангенс угла наклона, когда трение перестаёт держать равен коэффициенту трения. То есть при коэффициенте mu=1 угол соскальзывания окажется 45 градусов
Вроде как даже обычная резина может липнуть при определённой нагрузке, просто делает это плохо, поэтому для замеров используют специальную, равно как и разгонную полосу)
А так, школьная формула сухого трения просто имеет ограничения – объекты не деформируются, не липнут, не подскакивают и околоидеально гладкие, что в реальном мире сложно выполнимо
А в чём проблема в коэффициенте трения, большим единицы? Я сходу вспоминаю из бытового опыта, что, например, две наждачных бумаги одной зернистости, прижатые шершавыми поверхностями друг другу, имеют коэффициент трения по ощущениям гораздо больший, чем единица. Аналогично две детали из мягкого силикона по ощущению сильно больше единицы трутся (даже прилипают).
70 % алгоритма — это IF для разных случаев жизни
Это одна из лучших иллюстраций закона Конвея:
Любая организация, проектирующая систему (трактуется здесь шире, чем просто информационная система), неизбежно создаст такую модель, которая будет повторять коммуникационную структуру самой организации.
Код, состоящий из IF, как правило признак костыльности.
При всей моей любви к суровому производству, скажу, что архитектор со стороны к вам после этой статьи не придет. Потому что невозможно построить архитектуру из костылей. Строить можно, а построить нельзя.
Растите архитектора внутри коллектива.
Про архитектора — в самую точку. Так и поступаем.
А вот про костыли — тут вопрос философский. Что считать костылем, а что элегантным архитектурным решением? Это настолько тонкая грань, что можно различить только по запаху: где сильнее всего пахнет — там костыль ))
Как мерило можно использовать отношение: финальный результат (принесенная бизнесу польза) деленный на сложность доработок и поддержки.
Могу сказать, большая часть этих самых IF'ов описываются в конфигах и добавлялись без жестоких страданий. Хотя были и тяжелые случаи )) Куда же без них.
А если в целом — какие данные на входе, такие и решения в логике обработки.
Есть еще один аспект, который мне однажды подсказали:
"перед началом работы спроси себя, кому я смогу это продать?"
Понимать нужно в самом широком смысле, но в случае ИТ-специалиста это значит "перед вхождением в долгий проект спросите себя, насколько полезна будет в вашем резюме эта запись, увеличит ли она вашу ценность в глазах следующего работодателя"
И вот у костылей есть одно важное отличие - они уникальны для каждой системы. Опыт, полученный на проекте, состоящем из костылей, довольно сложно потом применить "по специальности". Там, конечно, будет прокачана целеустремленность, вера в светлое будущее и стрессоустойчивость, но это типа софт-скиллы. А по основному роду деятельности - костыли, непригодные для других компаний.
Это как те приколы с робототехникой.
В идеальном мире: повернул щуп кватернионами по узлам и свел клешню, чтобы взять что-нибудь, снова повернул кватернионами чтобы переставить в другое место, разжал клешню.D В реальном мире: механические узлы оказались не настолько точными, как математика, в итоге поворот произошёл с различными скоростями по разным осям и оказался на пол сантиметра в стороне от ожидаемой позиции из-за инерциальности системы, а обратный поворот заставляет гнуться узлы на неадекватные углы, в итоге после десятка попыток перетащить объект один из локтей или выходит из строя или начинает клинить, при этом продолжая регистрировать, что происходит движение. Как итог начинают появляться "костыли" для компенсации и тюнинга под конкретные железки в системе.
Или, коротко: физические системы без обратной связи не дают практической надёжности.
В идеальном мире: повернул щуп кватернионами по узлам и свел клешню, чтобы взять что-нибудь, снова повернул кватернионами чтобы переставить в другое место, разжал клешню.
В идеальном мире никакие кватернионы не нужны. Там достаточно просто кнопку нажать.
В реальном мире: механические узлы оказались не настолько точными, как математика, в итоге поворот произошёл с различными скоростями по разным осям и оказался на пол сантиметра в стороне от ожидаемой позиции из-за инерциальности системы, а обратный поворот заставляет гнуться узлы на неадекватные углы, в итоге после десятка попыток перетащить объект один из локтей или выходит из строя или начинает клинить, при этом продолжая регистрировать, что происходит движение.
То что кто-то не в курсе что такое погрешность, не понимает необходимости учитывать инерцию, не знает о наличии такой концепции как "граничные условия", не думает о возможности отказов - никак не связано с математикой.
Как итог начинают появляться "костыли" для компенсации и тюнинга под конкретные железки в системе.
Всё что можно запрограммировать - подмножество математики. Причём очень маленькое подмножество. Просто кто-то не умеет в нормальное матмоделирование.
Здесь другая история. Абстрактная модель технологического процесса оказалась слишком упрощённой для решения поставленной задачи. Модель приходится дорабатывать.
Как я регулярно упоминаю на производствнных совещаниях, невозможно управлять бардаком. Править -- да, и двадцатилетний опыт нашего директора производства подтверждает: править -- можно. Упроавлять (детерминированно) -- нет!
PS. Для архитектора и интегратора это неважно, это входные характеристики.
Архитектор, умный адекватный мужик, привыкший работать с синтетическими данными и чистой математикой, чуть не сошёл с ума на нашем реальном производстве.
И уволился посреди проекта со словами, что его психика этого больше не выдержит.
Анализ данных и производственных процессов, где табличные данные являются лишь частью анализа - не одно и тоже. Без походов в гемба здесь не обойтись.
Сколько различных ветвлений в алгоритмах ПЛК для обработки специфичных ситуаций — столько и нам нужно расставить if'ов для обнаружения и обработки этих ветвлений (к примеру включение шинкования обрези), в этом и особенность данных из «живого» мира.
Да, сценарии ИТ-системы должны повторять сценарии в жизни. Из вышеописанного я понял, что психика архитектора не выдержала, так как цифры/логика не сходилась с процессами. А не из-за количесва IF.
Этим отличается работа в ИТ в промке от сферически кровавого энтерпрайза:
"Смотри, ничего понять не могу, третий день бьюсь: вот этот столик (микроскопа на моторчике) двигаю вперед-назад, и .. он уезжает вбок на 0.5микрона .. да не, там есть и прижим, и температурная компенсация и катается всё на прецезионных подшипниках, и атмосфера чиста - 5 пылинок на кубометр.. просто туда-сюда и ушел в сторону. Ладно бы в одну.."
и сравните с "Надо сделать фабрику хелперов для драйверов СУБД. И что, что у нас один Мускуль? А вдруг мы завтра решим поменять Мускуль на Постгрес или даже MSSQL? По нашим требованиям, драйвер обязан(!) поставляться фабрикой в сервис".. а ничо, что это "микросервис" ровно для одного запроса: получить агрегат из БД в стиле EAV, при том, что проектировано с мощными костылями внутри БД? 15 лет пашет, и "мы не можем перейти с Мускуля 5.6 на 8-ю версию, у нас очень много старого кода" .. (делается легко, есть доки)
Ощутите разницу.
Стойкое ощущение что для поставленной задачи используются данные с датчиков, которые для этой задачи не содержат истинных данных, поэтому всё так больно.
Датчик срабатывания ножниц говорит правду только о ножницах, но не говорит ничего о том что они резали или не резали.
Чтобы получать данные о результате разрезов надо смотреть на результат разрезов. Возможно, это могут быть камеры+алгоритмы машинного зрения или оптоэлектронные датчики, установленные в правильных местах.
Я понимаю, что приходится использовать то, что есть.
Во, тоже так подумал. Сам часто работал раньше с датчиками и микроконтроллерами. Они реально иногда чушь несут, просто из-за того что могут быть дикие электромагнитные помехи и зашумленный радиочастотный фон. Вот и появляются всякие костыли в логике обработки, которые не костыли а целая методика.
Не так давно я прикручивал датчик открытия двери в homeassistant. Так вот эта дурнина шлёт несколько событий подряд открыто, закрыто, открыто на одно физическое открытие. Там для этого придумали замечательные вещи "Ваше устройство открыто сколько по времени?". То есть фактически игнорировать события в последовательности на временной шкале. Так как они могут быть ложными.
Итого любой физический датчик рано или поздно начинает врать, причём всегда с определенной частотой. Именно поэтому стоит посмотреть в сторону камер и компьютерного зрения. Настроить её на подозрительные вещи и она будет делать их фото самостоятельно.
Ну а если жить на датчиках - просто надо принять что они иногда чушь несут просто потому что это микрухи и где то рядом с ними в момент чуши электромагнитная волна пролетела, которая может даже возникать из за неочевидных вещей - трение ножниц о металл. Ну а если датчики дешёвые - и производители no-name. Не исключено что там просто баги в коде самих датчиков.
так и что все же случилось?
какой нежный архитектор
Чем-то напомнило анекдот, где "ну так садитесь на воздушный шар и сваливайте с этого острова"))))
Прежде чем соваться что то делать данные нужно изучить, рыться в данных ваш горе Аархитектор не захотел. Вот и весь фокус.
Подержите мой коньяк.
Перекресток. 6 распознающих камер, еще 6 обзорок. Надо чтобы все камеры щелкали картинки с точностью 1мс. Что бы любое событие можно было зафиксировать с разных камер.
Решается элементарно. Все обмазываем навигационными приемниками, нтп серверами. А потом начинаются приключения, то гпс не ловит, то сеть лагает, то пакеты теряются, обзорка может устать и не отдавать нормальные метки времени в кадрах. И еще тысячи нюансов. Одно радует. У нас нет непрерывного розлива стали.
Добро пожаловать в реальный мир.
Господи, зачем 1 мс? Фазу мерцания ламп регистрировать? И это решается только показом прямо в матрицу какого-то маркера времени, иначе тормоза считывания с матрицы и работы постпроцессинга всю точность похерят (1 мс -- это 1000 FPS).
Затем что нужно точно.
На этапе поверки конечно испульзуеься специальный "маркер". Дальше без него.
Тормоза считывания конечно есть (там много всякого есть). Но точность обеспечивается. Я бы даже сказал с точностью 100мкс. Этотне специально, простот решение сразу дает такой результат.
И это все на 12фпс. На 1000 никто не снимает.
Все так. Любая реальность усеяна костылями. Работаем с платежными системами - кодовая база костылей все растет и растет.
Мне кажется, если к каждому датчику приделать элементарные часы реального времени, с ходом хотя бы 3с/сутки - то и с законами физики, и с законами логики всё будет ок. Кейс очень сильно не "бигдата"; архитектор, кажется, был чуть ленив, чтобы хотя бы на метр зайти в кроличью нору (про ныряние туда вообще речи нет).
Но для сравнения с кейсом совсем не настолько "провального в случае фейла" производства - выглядит круто. Были бы все кейсы именно такими - работа бы вдохновляла. А когда "у нас впервые за полгода случился креш... Вот вам 2 гига логов в текстовом виде, разберитесь, что там не так" - скорее перманентно удручают. И даже 200М, и даже всего 2М...
Утрируя, на каждой машине есть контроллер, который непосредственно управляет автоматикой узла. Над контроллером — АСУТП, которая снимает с него данные и говорит ему, что делать.
неправильно сказали.
контроллеры принципиально входят в состав АСУТП. Нет никакой мифической АСУТП, которая говорит ему что делать. Может быть разве что контроллер верхнего уровня, который передает данные на локальный ПЛК, или SCADA-система, где оператор производит настройку режимов, или осуществляет ручное управление.
Вообще есть три слоя автоматического управления производством: MES (обычно, но не обязательно) -> слой автоматизации уровня производства (здесь его называют АСУТП, но есть и другие аббревиатуры) -> слой автоматизации оборудования (тоже бывают аббревиатуры).
SCADA - она вообще сбоку этой схемы стоит. Может участвовать (если надо управлять подачей мощности, воды/газов/вакуума, запрещать при выходе, например, температуры цеха за параметры), а может и нет (если оборудование умное и может всё это внутри себя делать).
Так что я бы не сказал, что люди некорректно высказались - просто у них АСУТП устроенно так.
Какой-то у вас ранимый бывший архитектор. Первый раз столкнулся с реальностью? Так даже на рафинированных академических курсах изучают аномалии данных и чистку данных.
А вообще, как говорит мой друг, "жизнь сложнее математики", это надо принять и не психовать от первый же аномалии.
Такое на всех производствах. Берешь любое производство и историю, связанную с автоматизацией процессов, it, данными и т.п. Везде будет тоже самое, что и в статье. Не зря многие как чуда ждут массового внедрения квантового компьютера. На нем, как предполагается, как раз и будут активно моделировать подобные системы с сотнями сочетаний возможных факторов-вмешательств.
А архитектор, видимо, сгорел куда раньше этого проекта, просто тут "выстрелило".
Тот самый датасет, где архитектор чуть не сошёл с ума