Понятно, то есть вы склоняетесь к точке зрения, что «динозавры» не потянут, и революция начнется снизу.
Закат Китая как мировой фабрики изза возвращения пром производства на базе новых технологий на запад — действительно тренд, который уже полгода как описывается в бизнесс прессе.
продолжу шизофренический диалог сам с собой. Снова ответ мне от muzzy0 (Он на хабре read-only):
Есть полно производств, которые до сих пор работают если не на реле и говне мамонтов, то на S5 — запросто. И ещё столько же проработают. Технологию каждый год никто не апгрейдит — она остаётся прежней, соответственно, производство не меняется. Разные мелкие, не ключевые изменения — не в счёт. Соответственно, зачем там автоматику менять? Работает — не трогай, вот главный принцип :) Кроме того, ты не учитываешь — какой это геморрой — заменить автоматику производства. Это катастрофа хуже пожара. Один объём работ по (электро)монтажу влетит в копеечку и растянется на несколько месяцев. А если производству лет 10 и более — то вообще труба. Время идёт, кто-то ушёл, кто-то уехал на край света, кто-то умер, кто-то впал в деменцию и на производстве не осталось ни одного человека, который понимает от и до, как оно работает. А программу для новой автоматики педерастоит писать с нуля. Ты представляешь, насколько затянется наладка? ;)
И всё это время производство будет стоять. Не выпускать продукцию и приносить прибыль, а простаивать, сосать деньги (отопление, уборка, охрана, зарплата оставшимся сотрудникам и т.д.) + затраты на перевооружение. Чего ради, спрашивается?
Под эти критерии попадает, я думаю, процентов 90 химии, пищёвки, энергетики и многого другого.
PS Конечно, если производство работает совсем на говне и палках, то перевооружение оправданно. Для того, чтобы повысить качество регулирования, удобство управления, сократить количество ручных операций по местному управлению, вести архивы — но многое можно сделать без остановки, участок за участком — и такие проекты регулярно делаются. Ставишь свежую автоматику и она будет жить до тех пор, пока сама в говно мамонта не превратится :)
И, кстати, это причина, почему производители поддерживают свою автоматику десятилетиями: не будешь же ты из-за одного сгоревшего модуля менять ВСЁ. Тебя заказчики на вилы за такое поднимут и очень скоро ты лишишься заказов.
Я согласен, что отрасль очень консервативна, особенно конечные потребители (да и вендоры не на самом переднем крае IT програсса обычно).
Поэтому и хочется, чтобы с 4.0 все получилось, и «мерседесу» (абстрактному большому заводу) стало бы выгодно чаще апгрейдиться, чтобы иметь возможность быстрее перестраивать производственные процессы. Например завод БМВ в Мюнхене, например, гордится, что они выпускают 100% машин по предварительным заказам от покупателей, и каждый покупатель может выбрать конфигурацию из десятков тысяч вариантов.
Мой русский язык, наверное, уже поздно исправлять — последние 14 лет пишу только по-английски, и только здесь на Хабре иногда отрываюсь. Если у вас есть идеи, как лучше перевести некоторые сленговые слова из статьи, я с удовольствием исправлю.
Спасибо за истории о Российских умельцах. И еще я почему-то пропустил год назад ваш обзор Beckhoff, с удовольствием прочитал сейчас. Я их тоже очень люблю, как пионеров в использовании x86 для автоматизации и за некоторые технические инновации. (Типа поддержки многоядерности в Twincat 3, за Ethercat с циклом 12 микросекунд, интеграцию с Visual Studio)
Коммент от еще одного настоящего индустриального гуру ailuropoda-m:
Fieldbus-ы жили, живут и будут жить долго и счастливо. По той простой причине, что, к примеру, в тот же PROFIBUS есть FMS, есть DP и есть PA. И все три предназначены для очень разных вещей. И если FMS вытесняется Indusrial Ethernet, для устройств с DP уже сейчас есть много альтернатив c PROFINET, то для PA (а тем более, Ex-PA) альтернатив нет.
Получил личный коммент от индустриального гуру muzzy0 (Его пока нет на хабре), поэтому привожу его здесь:
Смотри, своя физика промышленной сети — это только недостаток, но и преимущество.
Например, профибас очень сложно собрать неправильно, чтоб он совсем не работал. Однако, таланты находятся и пару раз мне попадались сети, топология которых позволяла задействовать более 2-х терминаторов, а это сразу валит сеть :)
Но не так это страшно: полдня с бубном и матюками и всё работает.
Далее, его физика предусматривает реально детерминированное время доставки, в отличие от эзернета — там время доставки гарантируется софтварными надстройками.
С другой стороны, за счёт других рабочих частот эзернет более стоек к наводкам с силовых кабелей, особенно — в моменты коммутации. Но на моём опыте профибас от такого не падал :) В общем, практика показала: профибас был хорошо задуман и хорошо реализован, за счёт чего проживёт ещё довольно долго — думаю, не меньше, чем живёт RS-232 :) Единственное геморройное место, которое вспомню с ходу — это подключение периферии к дублированному профибасу от дублированного контроллера, если эта периферия имеет всего один интерфейс. Тут идут в ход костыли типа Y-Link и всплывает гадкое ограничение на количество данных, которое может отдавать ведомое устройство.
В общем, с осциллографом в профибас лазить нужды нет — по крайней мере, я не встречался с такими запущенными случаями.
Зато, его закрытость служит некоторой защитой — первый попавшийся мудак со своей собранной на коленке и толком не отлаженной железкой в него не залезет, равно как и второй попавшийся мудак не сможет, при всём желании, объединить в один сегмент обычную локалку с удалённой периферией.
Модбас — в том виде, в котором я с ним сталкивался — чудовищен. Как раз потому, что каждый мудак может сделать свою железку с 485 интерфейсом, и запросто эта железка будет не вполне соответствовать спецификациям на физику: на столе работает, на объекте — нет. Соответственно, если линия не метр на столе, а чуть побольше и на объекте — её надо терминировать. Но если передатчик имеет слишком малую мощность — она вся уходит на терминатор. В результате, без терминатора работает хоть как-то, с ним не работает совсем :) Кроме того, накосячить на монтаже этого модбаса можно просто тысячей и одним способом. То, с чем сталкивался я — талантливые монтажники посчитали, что на некотором участке экран кабелю не нужен и дальше пара пойдёт голой :) Я уж не говорю о маленькой сеточке, топологию которой даже звездой не назвать — больше на метастазы какие-то похоже :) Руководитель работ от подрядчика, чьи монтажники наплели это макраме, чуть не насмерть стоит и переделывать не хочет. Оно и понятно, желающих провозиться на улице в -30 мало, особенно, с неочевидным результатом (а то и им, гагарам, очевидным: у программистов чего-то не работает и они валят на здоровую голову монтажников, чтоб время потянуть).
В двух словах, каждый накосячит, как может, а ты потом налаживай связь. В результате, на наладку профибасной сети из 10-20 узлов времени и геморроя тратится меньше, чем на модбасную в 4 узла максимум, и работает эта профибасная сеть куда стабильнее.
Ладно, что-то меня в дебри понесло.
С эзернетовой физикой тоже не всё однозначно хорошо. С одной стороны, к ней проще прицепиться даже удалённо, с другой — любой дурак может в эту сеть засунуть свой дурацкий и неуместный в этой сети узел — вплоть до того, чтоб эту сеть уронить. Да и дальность связи на медном эзернете очень проигрывает медному профибасу (в частности, и 485, в целом) — если мы не заморачиваемся оптикой.
Поэтому решения типа распределённая периферия — на закрытом филдбасе, обмен между контроллерами и сереверами/операторскими станциями — по эзернету будут существовать ещё довольно долго. Ну, я так считаю :)
>Суть Индустрии 4.0 не заканчивается на адаптации сетевых стандартов из вычислительных сетей
> общего назначения.
Конечно. Адептация сетевых стандартов — только один маленький кирпичик, а не главный элемент.
Роботы всегда были соединены в сеть, даже 30 лет назад, когда они только появлялись на заводах. Но перепрограммировать их было длинной и сложной задачей.
Я думаю, что то, что вы описали как децентрализацию — одна ее половина. Целесообразность заказа мелкой серии на большом заводе — отчасти следствие прогресса в логистике, но отчасти проявление этой 4.0, которая снижает стоимость и время перестройки производственной линии на выпуск нового продукта.
Вторая половина — станут экономически более целесообразными маленькие, но локальные цеха, позволяющие делать то, что вы описали выше, но быстрее за счет расположения в одном регионе с заказчиком.
Главная особенность — в индустрии все поняли, что надо прекращать изобратеть велосипеды, и для всего, чего можно брать готовые решения и стандарты из IT и адаптировать их. Для нас, программистов, это означает расширение рынка труда на новую область, и новую область для стартапов.
Да, я помню общался с ними в 2003, мы вместе делали симуляции их IOU и некоторых крипто протоколов тогда на питоне. Удивлен, что они еще живы, и что-то даже выпустили. 10 лет это почти Дюкнюкем форева.
В начале прошлого года они анонсировали, что новые релизы WRL будут базироваться на Yocto. (Я первый раз об этом услышал прошлой весной на elektronic design в Нюрнберге). После этого примерно десять разработчиков стали активно коммитить в Yocto project upstream.
В прошлом августе вышла WRL5, на базе Yocto.
Интересно, что почти этот же подход можно применить и без эмулятора на живой линукс системе с заоффлайненым ядром:
загрузить ядро с дыркой в физ. памяти, например memmap=64M$0x19000000
заоффлайнить ядро в линуксе с echo 0 > /sys/devices/system/cpu/cpu2/online
скопировать бинарник в 0x19000000 физической памяти через /dev/mem,mmap. (в бинарник добавить настройку gdt,idt по вкусу)
и небольшой загрузчик в соответствующий адрес (линкскрипт настроить соответственно),
инициировать INIT/SIPIx2 через LAPIC адрес на ACPI ID заоффлайненого ядра (warning: ACPI ID не всегда = Linux kernel core ID)
Общаться потом можно через шаренную физ. память и например mwait.
Я, к сожалению, не имею права выражать официальную позицию Интел.
Моя должность — инженер в технической поддержке, и я работаю только с embedded клиентами. Поэтому embedded продукты я знаю хорошо, а вот десктопные и серверные — плохо. Так что ваш компьютер для меня — недостижимый хай энд. Поэтому и задал вопрос в конце, вдруг коллеги помогут, если читают пост.
Лет 10 назад, я тоже следил за десктопными компьютерами, но как-то перегорел. Теперь слежу только за тем, что нужно по работе — за микроархитектурой и за платформами своего сегмента.
По поводу микросекунд. Архитектура Интел всегда в первую очередь оптимизировалась под максимальную throughput производительность. В задачах, где важно время отклика (промышленность, алгоритмический трейдинг), часто требуется отдельная работа с софтом для выгадывания микросекунд. Так как человек — система не очень быстро реагирующая, десктопные нагрузки никто не оптимизирует в области микросекунд. Обычно речь идет о десятках миллисекунд.
На десктопных нагрузках вы вряд-ли заметите этот эффект.
1. Речь идет о микросекундах.
2. У десктопных нагрузок сложнее проявить этот эффект, так как у них есть spatial locality, и так как менее приоритетным задачам дается меньше времени на CPU, следовательно, у них меньше возможности вытеснить чужие данные.
3. Измерять можно при помощи Intel Vtune, но учитывая пункты 1,2 — просто незачем.
По поводу вашего вопроса о современном железе, я не знаю ответа, т.к. не интересуюсь десктопным железом. Может быть, мои коллеги ответят.
Очень интересно! В официальном документе упомянули фичу, но ничего не написали о том, как ее использовать. Если внимательнее почитать, там же можно найти более подробную ссылку на CQoS monitoring. Вы, очевидно, ссылаетесь на CQoS control. Если бы такая фича существовала и была публична, я бы с радостью запостил статью на публичном ресурсе — Хабре.
Закат Китая как мировой фабрики изза возвращения пром производства на базе новых технологий на запад — действительно тренд, который уже полгода как описывается в бизнесс прессе.
Есть полно производств, которые до сих пор работают если не на реле и говне мамонтов, то на S5 — запросто. И ещё столько же проработают. Технологию каждый год никто не апгрейдит — она остаётся прежней, соответственно, производство не меняется. Разные мелкие, не ключевые изменения — не в счёт. Соответственно, зачем там автоматику менять? Работает — не трогай, вот главный принцип :) Кроме того, ты не учитываешь — какой это геморрой — заменить автоматику производства. Это катастрофа хуже пожара. Один объём работ по (электро)монтажу влетит в копеечку и растянется на несколько месяцев. А если производству лет 10 и более — то вообще труба. Время идёт, кто-то ушёл, кто-то уехал на край света, кто-то умер, кто-то впал в деменцию и на производстве не осталось ни одного человека, который понимает от и до, как оно работает. А программу для новой автоматики педерастоит писать с нуля. Ты представляешь, насколько затянется наладка? ;)
И всё это время производство будет стоять. Не выпускать продукцию и приносить прибыль, а простаивать, сосать деньги (отопление, уборка, охрана, зарплата оставшимся сотрудникам и т.д.) + затраты на перевооружение. Чего ради, спрашивается?
Под эти критерии попадает, я думаю, процентов 90 химии, пищёвки, энергетики и многого другого.
PS Конечно, если производство работает совсем на говне и палках, то перевооружение оправданно. Для того, чтобы повысить качество регулирования, удобство управления, сократить количество ручных операций по местному управлению, вести архивы — но многое можно сделать без остановки, участок за участком — и такие проекты регулярно делаются. Ставишь свежую автоматику и она будет жить до тех пор, пока сама в говно мамонта не превратится :)
И, кстати, это причина, почему производители поддерживают свою автоматику десятилетиями: не будешь же ты из-за одного сгоревшего модуля менять ВСЁ. Тебя заказчики на вилы за такое поднимут и очень скоро ты лишишься заказов.
Поэтому и хочется, чтобы с 4.0 все получилось, и «мерседесу» (абстрактному большому заводу) стало бы выгодно чаще апгрейдиться, чтобы иметь возможность быстрее перестраивать производственные процессы. Например завод БМВ в Мюнхене, например, гордится, что они выпускают 100% машин по предварительным заказам от покупателей, и каждый покупатель может выбрать конфигурацию из десятков тысяч вариантов.
ОК. Напишу, что новенького у CoDeSys, KW и Сименса в PLC программировании.
Спасибо за истории о Российских умельцах. И еще я почему-то пропустил год назад ваш обзор Beckhoff, с удовольствием прочитал сейчас. Я их тоже очень люблю, как пионеров в использовании x86 для автоматизации и за некоторые технические инновации. (Типа поддержки многоядерности в Twincat 3, за Ethercat с циклом 12 микросекунд, интеграцию с Visual Studio)
Fieldbus-ы жили, живут и будут жить долго и счастливо. По той простой причине, что, к примеру, в тот же PROFIBUS есть FMS, есть DP и есть PA. И все три предназначены для очень разных вещей. И если FMS вытесняется Indusrial Ethernet, для устройств с DP уже сейчас есть много альтернатив c PROFINET, то для PA (а тем более, Ex-PA) альтернатив нет.
Смотри, своя физика промышленной сети — это только недостаток, но и преимущество.
Например, профибас очень сложно собрать неправильно, чтоб он совсем не работал. Однако, таланты находятся и пару раз мне попадались сети, топология которых позволяла задействовать более 2-х терминаторов, а это сразу валит сеть :)
Но не так это страшно: полдня с бубном и матюками и всё работает.
Далее, его физика предусматривает реально детерминированное время доставки, в отличие от эзернета — там время доставки гарантируется софтварными надстройками.
С другой стороны, за счёт других рабочих частот эзернет более стоек к наводкам с силовых кабелей, особенно — в моменты коммутации. Но на моём опыте профибас от такого не падал :) В общем, практика показала: профибас был хорошо задуман и хорошо реализован, за счёт чего проживёт ещё довольно долго — думаю, не меньше, чем живёт RS-232 :) Единственное геморройное место, которое вспомню с ходу — это подключение периферии к дублированному профибасу от дублированного контроллера, если эта периферия имеет всего один интерфейс. Тут идут в ход костыли типа Y-Link и всплывает гадкое ограничение на количество данных, которое может отдавать ведомое устройство.
В общем, с осциллографом в профибас лазить нужды нет — по крайней мере, я не встречался с такими запущенными случаями.
Зато, его закрытость служит некоторой защитой — первый попавшийся мудак со своей собранной на коленке и толком не отлаженной железкой в него не залезет, равно как и второй попавшийся мудак не сможет, при всём желании, объединить в один сегмент обычную локалку с удалённой периферией.
Модбас — в том виде, в котором я с ним сталкивался — чудовищен. Как раз потому, что каждый мудак может сделать свою железку с 485 интерфейсом, и запросто эта железка будет не вполне соответствовать спецификациям на физику: на столе работает, на объекте — нет. Соответственно, если линия не метр на столе, а чуть побольше и на объекте — её надо терминировать. Но если передатчик имеет слишком малую мощность — она вся уходит на терминатор. В результате, без терминатора работает хоть как-то, с ним не работает совсем :) Кроме того, накосячить на монтаже этого модбаса можно просто тысячей и одним способом. То, с чем сталкивался я — талантливые монтажники посчитали, что на некотором участке экран кабелю не нужен и дальше пара пойдёт голой :) Я уж не говорю о маленькой сеточке, топологию которой даже звездой не назвать — больше на метастазы какие-то похоже :) Руководитель работ от подрядчика, чьи монтажники наплели это макраме, чуть не насмерть стоит и переделывать не хочет. Оно и понятно, желающих провозиться на улице в -30 мало, особенно, с неочевидным результатом (а то и им, гагарам, очевидным: у программистов чего-то не работает и они валят на здоровую голову монтажников, чтоб время потянуть).
В двух словах, каждый накосячит, как может, а ты потом налаживай связь. В результате, на наладку профибасной сети из 10-20 узлов времени и геморроя тратится меньше, чем на модбасную в 4 узла максимум, и работает эта профибасная сеть куда стабильнее.
Ладно, что-то меня в дебри понесло.
С эзернетовой физикой тоже не всё однозначно хорошо. С одной стороны, к ней проще прицепиться даже удалённо, с другой — любой дурак может в эту сеть засунуть свой дурацкий и неуместный в этой сети узел — вплоть до того, чтоб эту сеть уронить. Да и дальность связи на медном эзернете очень проигрывает медному профибасу (в частности, и 485, в целом) — если мы не заморачиваемся оптикой.
Поэтому решения типа распределённая периферия — на закрытом филдбасе, обмен между контроллерами и сереверами/операторскими станциями — по эзернету будут существовать ещё довольно долго. Ну, я так считаю :)
> общего назначения.
Конечно. Адептация сетевых стандартов — только один маленький кирпичик, а не главный элемент.
Роботы всегда были соединены в сеть, даже 30 лет назад, когда они только появлялись на заводах. Но перепрограммировать их было длинной и сложной задачей.
Я думаю, что то, что вы описали как децентрализацию — одна ее половина. Целесообразность заказа мелкой серии на большом заводе — отчасти следствие прогресса в логистике, но отчасти проявление этой 4.0, которая снижает стоимость и время перестройки производственной линии на выпуск нового продукта.
Вторая половина — станут экономически более целесообразными маленькие, но локальные цеха, позволяющие делать то, что вы описали выше, но быстрее за счет расположения в одном регионе с заказчиком.
Это вряд-ли, там же первый слой — чистое серебро.
В прошлом августе вышла WRL5, на базе Yocto.
загрузить ядро с дыркой в физ. памяти, например memmap=64M$0x19000000
заоффлайнить ядро в линуксе с echo 0 > /sys/devices/system/cpu/cpu2/online
скопировать бинарник в 0x19000000 физической памяти через /dev/mem,mmap. (в бинарник добавить настройку gdt,idt по вкусу)
и небольшой загрузчик в соответствующий адрес (линкскрипт настроить соответственно),
инициировать INIT/SIPIx2 через LAPIC адрес на ACPI ID заоффлайненого ядра (warning: ACPI ID не всегда = Linux kernel core ID)
Общаться потом можно через шаренную физ. память и например mwait.
Моя должность — инженер в технической поддержке, и я работаю только с embedded клиентами. Поэтому embedded продукты я знаю хорошо, а вот десктопные и серверные — плохо. Так что ваш компьютер для меня — недостижимый хай энд. Поэтому и задал вопрос в конце, вдруг коллеги помогут, если читают пост.
Лет 10 назад, я тоже следил за десктопными компьютерами, но как-то перегорел. Теперь слежу только за тем, что нужно по работе — за микроархитектурой и за платформами своего сегмента.
По поводу микросекунд. Архитектура Интел всегда в первую очередь оптимизировалась под максимальную throughput производительность. В задачах, где важно время отклика (промышленность, алгоритмический трейдинг), часто требуется отдельная работа с софтом для выгадывания микросекунд. Так как человек — система не очень быстро реагирующая, десктопные нагрузки никто не оптимизирует в области микросекунд. Обычно речь идет о десятках миллисекунд.
1. Речь идет о микросекундах.
2. У десктопных нагрузок сложнее проявить этот эффект, так как у них есть spatial locality, и так как менее приоритетным задачам дается меньше времени на CPU, следовательно, у них меньше возможности вытеснить чужие данные.
3. Измерять можно при помощи Intel Vtune, но учитывая пункты 1,2 — просто незачем.
По поводу вашего вопроса о современном железе, я не знаю ответа, т.к. не интересуюсь десктопным железом. Может быть, мои коллеги ответят.