Фабрика разработана как устройство способное собирать что угодно, если продукт укладывается в пределы по 3-м измерениям, списку материалов и типу соединений. Например, сейчас фабрика поддерживает: glue (metal to metal, composite to composite, composite to metal, glass to composite, glass to metal), bolting, FDS and Insert; 6m*3m*4m; aluminum, composite, plastic. Есть еще несколько детальных ограничений по максимальному весу подсборки (robot payload). Все что нужно поменять для нового продукта это тулинг (jigs, grippers) - как и показано в статье это product specific часть, но она может меняться не влияя на большую часть фабрики. Туллинг это примерно 8% от всей фабрики. При наличии продукта, можно перенастроить фабрику за 9-10 мес.
Понимаю, что звучит как про "пуговицы", но фабрика сама по себе бесполезна, если продукта, который собирать нужно, нет. Продукт вышел не оптимальным по итоговой цене и функциям - с фабрикой не связано, но производить смысла нет. Идет сборка только для тестирования, "milage" и тд
Фабрика зашла, а вот автомобиль не получился таким, как планировался. В итоге, пока, нечего этой фабрике собирать. Конвейер для таких объемов не выгоден - в 3 раза дороже. От 100 тыс в год выпуск нужен, а лучше 300тыс+
Согласен. Тут дядя Вася должен работать как био-робот - строго по задаче. Мы кстати и называем вместе HMI - MHI - machine-human-interface - подчеркивая что система говорит что делать, а человек не может отступать от инструкций
Маршрут меняется автоматом - Factory OS (мульти-агентная система) - перестраивает его на лету. При изменении операций Digital factory create прогоняет сначала сверки с factory capabilities - если ок, то опять же Factory OS перестраивает процесс. Если нет, то система говорит какого Application (tool, fixture не хватает)
Вычислительные мощности были не те, CV практически никакое - без этого не взлетает. Это как с нейронками - математически им несколько десятков лет, а вычислительные мощности появилось сравнительно недавно
Это все нужно для универсальности фабрики - собирать несколько разных продуктов с разной длинной и составом процесса. Если продукт 1, то тогда система логистики вырождается в то, что вы описали. Иначе нам нужна шина - и ту без мобильных роботов не обойтись. Система логистики определяет все производство, буквально все - и inbound и outbound. Радио-метки на полу это как рыбе зонтик - если нет гибкости, тогда лучше просто конвейер и не морочить голову радио-метками.
У меня речь идет о сборочной фабрике - операции вставки, болчения, склеивания, клепки, сварка и тд. И это уже работает. В вашем примере CNC. С ним мы только начали работать. G-code генерировать и подгружать не проблема. Мы делаем примерно тоже самое для Trimming ячеек, где роботу нужно пройтись по кромке композитной детали и отрезать лишнее, просверлить отверстие и т.д. Код tool (сверла) генерится на основе CAD. Далее, на основе траектории tool генерится траектория робота. ВАЖНО - это делает не MES - ее нет. Это делает OS ячейки - то есть ячейка это такой независимый "3D printer" со своими capabilities и автогенерацией кода для операций. Это происходит в "soft PLC". А Factory OS оркестрирует ячейки как ресурсы.
При этом, согласен, с CNC будут свои особенности, особенно с точки зрения анализа качества и точности полученной детали. В сборочной ячейке это сделать проще - CV - и доступ нормальный и "пыли" нет.
Датчиков там тысячи. Думаю, что проблема в консервативности отрасли. За исключением SpaceX все остальные программы ведутся правительственными учреждениями, которым уже по 40-50 и более лет. При всей светлости умов, избежать legacy мышления невозможно. Плюс, думаю что жесткие ограничения по весу, обьему и энерго-потреблению любого оборудования на борту могут сдерживать внедрение. Впрочем, я уверен что дело скорее в привычке. У меня нет данных, но, думаю SpaceX использует эти технологии
Концептуально, любая База данных с заданной структурой, в которую вы сохраняете состояние вашего обьекта (датчиков) + real-time механизм регистрации событий и их чтения и есть Digital twin
То есть, у нас схема: Датчик + Микро-сервис (слушает события датчика и бросает JSONы в шину) + real-time Шина Сообщений + Data robot (разбирает очередь сообщений и распихивает по структурам данных) + База данных + Интерфейс чтения (подписки)
В качестве БД мы взяли MongoDB, в качестве шины Kafka. Оба продукта open source и по ним много литературы
Data роботов пишем на Scala. Микро-сервисы на python.
Для больших компаний есть конечно enterprise решения от Microsoft, Oracle и тд. Но начинать с них, на мой взгляд сложно, да и не нужно.
Информация
В рейтинге
Не участвует
Зарегистрирован
Активность
Специализация
Исполнительный вице-президент по роботическим технологиям
Фабрика разработана как устройство способное собирать что угодно, если продукт укладывается в пределы по 3-м измерениям, списку материалов и типу соединений. Например, сейчас фабрика поддерживает: glue (metal to metal, composite to composite, composite to metal, glass to composite, glass to metal), bolting, FDS and Insert; 6m*3m*4m; aluminum, composite, plastic. Есть еще несколько детальных ограничений по максимальному весу подсборки (robot payload). Все что нужно поменять для нового продукта это тулинг (jigs, grippers) - как и показано в статье это product specific часть, но она может меняться не влияя на большую часть фабрики. Туллинг это примерно 8% от всей фабрики. При наличии продукта, можно перенастроить фабрику за 9-10 мес.
Понимаю, что звучит как про "пуговицы", но фабрика сама по себе бесполезна, если продукта, который собирать нужно, нет. Продукт вышел не оптимальным по итоговой цене и функциям - с фабрикой не связано, но производить смысла нет. Идет сборка только для тестирования, "milage" и тд
Фабрика зашла, а вот автомобиль не получился таким, как планировался. В итоге, пока, нечего этой фабрике собирать. Конвейер для таких объемов не выгоден - в 3 раза дороже. От 100 тыс в год выпуск нужен, а лучше 300тыс+
Согласен. Тут дядя Вася должен работать как био-робот - строго по задаче. Мы кстати и называем вместе HMI - MHI - machine-human-interface - подчеркивая что система говорит что делать, а человек не может отступать от инструкций
Маршрут меняется автоматом - Factory OS (мульти-агентная система) - перестраивает его на лету. При изменении операций Digital factory create прогоняет сначала сверки с factory capabilities - если ок, то опять же Factory OS перестраивает процесс. Если нет, то система говорит какого Application (tool, fixture не хватает)
Вычислительные мощности были не те, CV практически никакое - без этого не взлетает. Это как с нейронками - математически им несколько десятков лет, а вычислительные мощности появилось сравнительно недавно
Про "эффективное расходование" - такая фабрика в 3 раза дешевле и в 2.5 раза быстрее по запуску
Это все нужно для универсальности фабрики - собирать несколько разных продуктов с разной длинной и составом процесса. Если продукт 1, то тогда система логистики вырождается в то, что вы описали. Иначе нам нужна шина - и ту без мобильных роботов не обойтись. Система логистики определяет все производство, буквально все - и inbound и outbound. Радио-метки на полу это как рыбе зонтик - если нет гибкости, тогда лучше просто конвейер и не морочить голову радио-метками.
Спасибо за потраченное время и отзыв!
У меня речь идет о сборочной фабрике - операции вставки, болчения, склеивания, клепки, сварка и тд. И это уже работает. В вашем примере CNC. С ним мы только начали работать. G-code генерировать и подгружать не проблема. Мы делаем примерно тоже самое для Trimming ячеек, где роботу нужно пройтись по кромке композитной детали и отрезать лишнее, просверлить отверстие и т.д. Код tool (сверла) генерится на основе CAD. Далее, на основе траектории tool генерится траектория робота. ВАЖНО - это делает не MES - ее нет. Это делает OS ячейки - то есть ячейка это такой независимый "3D printer" со своими capabilities и автогенерацией кода для операций. Это происходит в "soft PLC". А Factory OS оркестрирует ячейки как ресурсы.
При этом, согласен, с CNC будут свои особенности, особенно с точки зрения анализа качества и точности полученной детали. В сборочной ячейке это сделать проще - CV - и доступ нормальный и "пыли" нет.
Датчиков там тысячи. Думаю, что проблема в консервативности отрасли. За исключением SpaceX все остальные программы ведутся правительственными учреждениями, которым уже по 40-50 и более лет. При всей светлости умов, избежать legacy мышления невозможно. Плюс, думаю что жесткие ограничения по весу, обьему и энерго-потреблению любого оборудования на борту могут сдерживать внедрение. Впрочем, я уверен что дело скорее в привычке. У меня нет данных, но, думаю SpaceX использует эти технологии
Концептуально, любая База данных с заданной структурой, в которую вы сохраняете состояние вашего обьекта (датчиков) + real-time механизм регистрации событий и их чтения и есть Digital twin
То есть, у нас схема: Датчик + Микро-сервис (слушает события датчика и бросает JSONы в шину) + real-time Шина Сообщений + Data robot (разбирает очередь сообщений и распихивает по структурам данных) + База данных + Интерфейс чтения (подписки)
В качестве БД мы взяли MongoDB, в качестве шины Kafka. Оба продукта open source и по ним много литературы
Data роботов пишем на Scala. Микро-сервисы на python.
Для больших компаний есть конечно enterprise решения от Microsoft, Oracle и тд. Но начинать с них, на мой взгляд сложно, да и не нужно.