comtemichel (comtemichel) wrote,
comtemichel
comtemichel

Обучение робототехнике: для какого системного уровня?

Оригинал взят у ailev в Обучение робототехнике: для какого системного уровня?
Вчера побывал на тусовке по обучению робототехнике в Московском политехническом институте (то бишь МАМИ). Проектный подход к обучению и всё вокруг него, специализация "Управление в технических системах". В зале представители KUKA, FANUC, пары российских робототехнических предприятий, преподаватели, завучи разного уровня (как их ещё назвать?) и -- неожиданно -- я. Вот пара моих мыслей с той тусовки:

1. В проектном подходе обсуждается всё что угодно, кроме проекта в целом. Студенту не даётся никаких представлений, как устроен проект в целом ни с предпринимательской стороны, ни со стороны инженерной (системная инженерия), ни со стороны менеджерской (управление задачами и лидерство), ни со стороны технологической (методология разработки). Как и в советской школе инженерии, проект делается "по наитию" руководителя проекта, а у студента ожидается получение "опыта проектной работы" -- при этом ни одного термина ни одной дисциплины сборки проекта как целого студенту не дают, он при этом может получить, а может и не получить то самое "наитие", которое было у руководителя проекта, как в средних веках подмастерье учился у мастера -- просто жил рядом был на подхвате.

При этом организаторы этой проектной работы бодро произносят слова "жизненный цикл", но ни в одной учебной дисциплине студента с этим понятием не ознакомят, да и не факт что руководители проекта будут с ними обсуждать этот самый жизненный цикл. Организаторы проектной работы всё-таки снаружи от этих проектов. В учебных программах этими предметами и не пахнет, зато есть история, физкультура, русский язык и культура речи. Культуры выбора модели жизненного цикла в соответствии с профилем риска проекта нет, только культура речи. Инженерии требований нет, практик моделеориентированной архитектурной работы нет, инженерии проверки и приёмки (V&V, испытаний) нет, управления конфигурацией нет. А проектной работы много. У меня в голове это не укладывается, как так может быть: проекты есть, а делать проекты не учим -- учим делать отдельные действия внутри проектов.

Казалось бы, что проще: бери системную схему проекта и обсуждай эти проекты по ней, чтобы ничего не забыть. Но для начала эту схему нужно знать. Вот она, адаптация из OMG Essence:


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

Ну, и ещё одна проблема -- все эти рассуждения про системную инженерию бесполезны, если не учить системному мышлению, а рассуждения про системное мышление бесполезны, если не учить рациональным основаниям мышления (http://ailev.livejournal.com/1311261.html). Мышлению нужно учить, нельзя надеяться, что он возникнет само собой, просто от нахождения рядом с хорошо мыслящими людьми. Вот мои архитектурные требования к мышлению, можно проверять разные обучающие мышлению курсы на соответствие этим требованиям -- http://ailev.livejournal.com/1342372.html.

2. Учебная программа вся пронизана системным подходом первого поколения: внимание к обеспечивающей системе ноль (собственно, об этом первый пункт этого поста), стейкхолдеры и работа с ними не обсуждаются: людей в программе нет, поэтому никаких view и viewpoints, никаких concerns, ничего этого. Зато кибернетика в количестве: алгоритмика самая разная и немножко математики для неё. Но поскольку людей нет, то ни промышленного дизайна, ни конструирования человеко-машинных интерфейсов (не говоря уж о UX).

Это обучение как раз той самой робототехнике, которая стагнировала много лет, концепции которой не менялись десятилетиями, пока не пришло машинное обучение и не изменило буквально всё: у роботов появились глаза, уши, адаптируемые плавные движения -- и это за последнюю пару лет. Теперь берём студентов-абитуриентов, начинаем их учить по-старинке, и через четыре года у нас бакалавры не-пойми-чего в мире машиннобучаемых роботов, потому как тренд на машинное обучение уже абсолютно понятен и поэтому нужно срочно менять обучение людей, чтобы его учесть (вот я на эту тему выступал в МТИ: http://ailev.livejournal.com/1267994.html, и с тех пор за год доклад уже устарел, да и для робототехники его можно было бы дополнить).

Поменялось в современной робототехнике всё, начиная от контроллеров: для автономного робота, который собирается видеть и слышать нужен суперкомпьютер NVIDIA TX2 (http://www.nvidia.com/object/autonomous-robots.html), автомобильщиков -- PX2, а через четыре года будут уже совсем другие модели компьютерного хардвера, и учить нужно будет им -- и даже не особенностям хардвера, а вообще тому, что это за такой специальный робототехнический компьютерный хардвер. Про это ж никто не знает, это ж не учебные Raspberry Pi или Arduino, современным роботам же нормальные высокопроизводительные нейронные мозги нужны, а не калькуляторы для движения по линии! И начинать заниматься этим нужно уже сейчас, чтобы через четыре года получить выпускников, которым это всё знакомо.

3. Основная идея совещания была -- "производство должно дать заказ на студентов и чему их учить". Для этого нужно иметь конкурентный рынок и фирмы, которые озабочены своей позицией на этом рынке через четыре года (по факту пять -- год на раскачку, потом четыре года на обучение, и только потом собирать урожай студентов). Вот ни разу не верю, что это так работает. Я задал вопрос, как там мыслится образование без исследований рядом?! В ответ было рассказано, что исследования есть, в этих исследованиях потом заинтересовывают промышленность, и только после этого у промышленности появляется заказ на новых студентов и новые проекты для этих студентов. Но это не был основной жизненный цикл студенческого проекта, который рассматривался на этом совещании. Тут хорошо бы помог подход "экстремального жизненного цикла", который я даю в своём курсе -- выход за пределы этого цикла в начале его и в конце его, но поскольку мышление в терминах жизненного цикла на этом совещании не присутствовало, было это трудно обсуждать.

Тут я мог бы указать на работы Марка Акоева с его жизненным циклом науки в университете (http://incose-ru.livejournal.com/54648.html, рассмотрение того, что происходит со студентом и университетом за пределами учёбы студента в университете и как эта учёба в университете влияет на эти отношения, причём подход тут бизнесмоделирования) -- и это тоже нужно учитывать, пользу самому университету и человеку-студенту, а не только пользу работодателю.

4. Основная проблема с учебными проектами -- это ранние стадии жизненного цикла, а именно работа предпринимателя и инженера по требованиям. Вот схема предпринимательства (http://ailev.livejournal.com/1289942.html):

Вот как концептуальное проектирование показано в работе Steven J. Saunders "Return on Investment Using Model-Based Concept Design", INCOSE INSIGHT том 17 выпуск 4, декабрь 2014:

Можно ещё указать на современные варианты ТРИЗ+ (Gen3Methodology, системная методология инноваций -- не путать с "просто АРИЗ/ТРИЗ" тридцатилетней давности), которые уделяют этой стадии концептуального проектирования много времени.

Эти работы не осознаются как специальные, требующие времени и особой организации, поэтому не рассматриваются их практики, не рассматриваются стейкхолдерские роли, место этих работ в общих работах проекта, трудозатраты на эти работы -- этого всего как бы нет, а оно есть!

Это иногда обсуждается как technology management (вот тут я пару лет назад это обсуждал): http://ailev.livejournal.com/1160014.html. То есть запрос тут есть даже у самих организаторов обучения, и им бы нужно думать о том, чтобы развернуть именно такое обучение, хотя бы на уровне crash course для всех причастных.

5. Интересно, что инженеры при обсуждении проектов способов их организации вдруг перешли на айтишный язык -- это так они понимают робототехнику? Договорились до того, что "инжиниринговый центр" вдруг обозвали "интегратором". Объяснений этому феномену не нашлось, хотя в кулуарах мы немного это пообсуждали.

Заодно в кулуарах признались, что слова "киберфизические системы" много более точны по отношению к предмету обсуждения, но считаются чем-то детским и далёким от промышленности, этот термин как бы "менее денежный"(!).

Но был и военный инженер, который сразу сказал, что студентов нужно обучать ГОСТам, ибо без знания этих ГОСТов конструторам-из-ВУЗа нельзя дать даже третьей категории. Опять же, стандарты военных и мирных инженеров разные, и учить военных инженеров и гражданских нужно разному. Я лично вообще против этих ГОСТов: а) в разных отраслях они разные, б) это очень специфично для страны, в) ГОСТы маркируют старинный технологический уклад, и нет лучше способа застрять в прошлом, чем эти ГОСТы. Если рядом случится инноватор, который пойдёт в международной кооперации мимо всех этих ГОСТов, то он и выиграет. Но самое ужасное -- ГОСТы несистемны, системным подходом в них не пахнет, и нужно тратить сок мозга на то, чтобы упихнуть в них результаты более современных подходов. По ГОСТам получится дорого и некачественно, отстало и дремуче, зато со всеми преимуществами стандарта: все будут говорить на одном языке, кривом и неточном. Я считаю, что если припрёт, то студент выучит в рамках дополнительной профессиональной подготовки, за деньги того предприятия, на котором эти ГОСТы применяются.

И да, я понимаю, что весь мой пост в целом и данный пункт в частности вызывает волну возмущения в советских инженерах. Ну что же, мне к этому не привыкать.

6. Самое интересное случилось потом: беседы с Александром Корниловым, найденный мной тут же в лаборатории мой студент из числа техпредпринимателей, а также организуемый между WordSkills и Политехом новый формат обучения детей робототехнике -- и я планирую пристроить на это обучение своего сына (дай бог здоровья всем причастным).

Основная идея этого курса (хотя она и выражается его организаторами не в слишком системном языке, но как идея абсолютно осознана) -- это явное разделение системных уровней в робототехнике. Давайте я перескажу это на системном языке. Основные отношения в системах -- это отношения "часть-целое", а система представляет из себя холон (целое, которое одновременно и часть объемлющего целого, и внутри себя тоже имеет части). Холоны собираются в холархии (иерархии по отношению "часть-целое"). На каждом уровне холархии (т.е. сборки по отношениям "часть-целое") обсуждаются какие-то свои свойства, свои особенности, присутствуют какие-то свои интересы своих стейкхолдеров -- и эти свойства обычно отсутствуют в рассмотрениях предыдущего уровня. Это появление новых рассмотрений, новых свойств при сборке (composition) называют эмерджентностью, в противовес редукционизму.

На пример системного фитнеса я уже демонстрировал безумие такого подхода: на вопрос "чем танцует человек" нельзя отвечать "мышцами и костями", ибо это неправильный системный уровень. "Мышцы и кости" тут ответ не лучше, чем "клетки" или "молекулы", или даже "атомы". Подробности кратенько в докладе http://ailev.livejournal.com/1341660.html и особо пристально там смотреть там слайд 7 с системной холархией.

Вот робототехника (особенно "образовательная робототехника" -- http://ailev.livejournal.com/1278294.html, http://ailev.livejournal.com/1280086.html) в России насквозь пронизана редукционизмом: все свойства роботов обсуждаются так, как будто они выводимы из свойств составляющих этих роботов, а сами эти роботы состоят из дискретных деталей. Отнюдь!

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

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

Итак, мой отрок умеет уже паять и программировать управление датчиками и моторчиками на ардуино. Это означает, что он вполне в состоянии сделать манипулятор робота. Нужно ли его учить дальше этим заниматься? Да, если он хочет побить в конкуренции KUKA и FANUC. Но дальше просто движемся по этой линии: эти знания не помогут ему собрать робота из манипулятора, тележки и всего остального -- ибо для этого по необходимости придётся обсуждать производственную или бытовую киберфизическую систему, частью которой будет робот. Если не будет обсуждать эту производственную или бытовую киберфизическую систему -- то просто требований к этому роботу не будет, ибо не будет потребностей (описания использующей системы), которые сфокусируют эти требования. На этом уровне всё другое: паять не нужно, манипуляторы уже есть, нужно научиться с ними работать как со сложными киберфизическими устройствами, делать из них сложную киберфизическую систему (в которой несколько устройств). То есть та же механика, то же программирование -- но на совсем-совсем другом системном уровне, это просто другая специализация.

На совещании как раз говорилось, что KUKA и FANUC отмечают недостаток именно таких спецов и готовы их всячески трудоустраивать -- а вот спецы, которых учат сделать манипулятор, такие спецы им не помощники, а конкуренты.

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

И вот задумка нового курса для деток (которые могут оказаться в том числе и студентами, но и школьниками -- почему бы и нет?) ровно в том, чтобы шагнуть в обучении робототехнике на уровень выше. Вот вам готовые манипуляторы -- и учитесь работать с ними, не особо вникая в их внутреннее устройство. Интернет вещей, в котором вещей много, они все уже разработаны, изготовлены и работают сами по себе и имеют стандарты для их сервисов ("функции компонент и сервисы модулей" -- http://ailev.livejournal.com/1344171.html), но из них нужно собрать что-то полезное и осмысленное.

Вот я там сфотографировал два манипулятора, которые взаимодействуют друг с другом (играют в шахматы или находятся в производственной линии a la Industrie 4.0 -- типичная ситуация в этом "интернете вещей"):
twoarms
Задача: научить деток работать с этими манипуляторами. Ставить для них задачу (разрабатывать требования), программировать их взаимодействие, думать о них двух таких отдельных как о целой системе.

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

Вот на это я с удовольствием отдам своего вьюноша, мопед в данном случае мой. Полезно бывать на тусовках по обучению робототехнике -- несмотря на то, что на самой тусовке эти вопросы не обсуждались, кулуары там удались на славу. Спасибо Тимуру Идиатуллову (https://www.facebook.com/timour.idiatoullov) и Алексею Корнилову (https://www.facebook.com/alx.kornilov) за доставленное удовольствие.

Tags: образование, одобряэ, перепост, системное мышление
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments