Category: производство

Category was added automatically. Read all entries about "производство".

2021 год

Дополнительные приёмы по выявлению целевой системы

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

Предпринимательство и инженерия требований
Догадаться/guess о подходящей целевой системе, её месте в окружении (и потом прийти по цепочке обеспечения или системным уровням окружения к "нашей системе", совпадающей или не совпадающей с целевой) -- это задача прежде всего предпринимателя. Да, она в существенной мере пересекается с задачей инженера по требованиям, но инженер по требованиям всё-таки получает на входе от предпринимателя готовую идею/guess, которую критикует и дальше помогает улучшить (уточнить и дополнить, исправить возможные ошибки, документировать). Предпринимательство не алгоритмизируемо, оно базируется на диких догадках, и лучшие из них -- это взять какую-то конструкцию "сбоку" (из какой-то другой предметной области) и предложить её как основу для выполнения функции целевой системы (то есть предприниматель на выходе имеет грубую и недетализированную идею архитектурного решения, часто на паре уровней -- 1. целевая система в составе надсистемы и 2. архитектурное решение самой целевой системы: подсистемы в составе целевой).

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

Можно ли тогда уйти от определения целевой системы? Нет, нельзя. Ибо если не делаете целевую систему (не принимаете участия в её создании), не меняете мир, то деятельность ваша не имеет смысла. Вы должны понимать, чем занимаетесь.

Есть самые разные предпринимательские стратегии, варианты этих стратегий можно обсуждать как раз на схеме системного мышления и схеме системных уровней (я это делаю в докладе "Большие предпринимательские программы: Дженсен Хуанг, Элон Маск и все-все-все", https://vimeo.com/553816090 (первый на этом видео, слайды https://yadi.sk/i/6UCRvQq51ngj5Q). Например, можно потихоньку идти вверх по системным уровням (стратегия NVIDIA: делать платы вокруг чипов, сервера вокруг плат, датацентры вокруг серверов) или вверх по цепочкам обеспечения (предоставлять спутники связи, для их запуска делать свой космофлот, для производства ракет в космофлоте строить уникальные заводы -- планируется выпуск огромных кораблей Starship каждые 72 часа).

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

Так что верхнеуровневые рассуждения по поводу целевой системы и нашей системы лучше всего делать, поглядывая на диаграмму сути системного мышления и с мыслями о стратегии и стратегировании:



Представьте себе целевую систему в физическом мире
Вы должны прямо как Тесла (который по легендам умел представить у себя в голове работающее физическое устройство) представить вашу целевую систему в момент эксплуатации, в физическом окружении. Вот небольшой список контрольных вопросов:
-- это точно время эксплуатации/run-time, а не дизайн-тайм? Это не момент "продажа как эксплуатация людьми из обеспечения"? Там бенефициары/эксплуатанты из run-time?
-- система "перед внутренним взором" работает (то есть вы видите как бы "кино", а не статическую картинку) и выделяется из своего окружения вниманием (а не разбирается на части!). Скажем, печень в человеке представляется работающей, а не вынутой отдельно из человека. Надсистема физически вокруг ("окружение"! молекулы окружения вокруг или рядом с целевой системой. Всякие информационные интерфейсы тоже можно обсуждать, но и тут представить физичность очень помогает -- например латентность на этих интерфейсах вы сразу заметите!). Учитывать надсистему, представлять её обязательно! Почитайте пост одного из наших студентов, как нервно получается, если этого не делать: https://blog.system-school.ru/2021/06/26/osoznanie-rokovyh-oshibok-s-pomoshhyu-sistemnogo-myshleniya/
-- не забывайте, что в учебнике на эту тему ещё много чего говорится (например, "если у вас софт, то посмотрите на людей вокруг плюс софт как один из кандидатов, на описываемую базами данных софта систему как другой кандидат")
-- выделяйте вниманием такие границы системы, которые никто до вас не заметил. Пример: мышечные ленты в теле как целевые для каких-то проектов работы с телом (эти ленты как особые объекты выделены в системном фитнесе).

Попробуйте заменить тип какой-то системы в цепочке или окружении
Попробуйте теперь заменять какие-то системы по цепочке: что изменится? Если ничего, то берите что-то поближе к вашей системе. Например, вы делаете систему операционного управления сооружением/стройкой на стадии проектирования строительства завода на базе Synchro (куплен Bentley) или Navisworks (будете прокручивать на экране видеоролики строящегося завода в поиске коллизий типа возведения крыши в тот момент, когда ещё нет стен и даже колонн для поддержки крыши). И утверждаете, что завод -- это и есть целевая система, обеспечение завода -- это стройка, а вы обеспечиваете стройку (график выхода подрядчиков/план организации строительства корректируется с использованием вашей системы). Вопрос: то, что будет выпускать завод -- не это ли ваша целевая система? Предположим, что это самолёты, или обогащённая руда, или полупроводниковые чипы. Что поменяется в вашей системе при таких заменах? Завод-то будет другим! Но в вашей системе не поменяется состав, не поменяются практики: ваша система операционного управления стройкой будет ровно той же самой, хотя данные в ней и будут каждый раз по другому набору заводских систем. А если завод заменяем на дачный домик или ракету? Вот тут резко меняются методы сооружения (строительства и монтажа), и могут потребоваться совсем другие решения по системе операционного управления сооружением, в том числе выбор другого софта (и это означает, что у вас будет другой проект, другая ваша система). То есть целевой системой лучше таки считать завод, а не продукцию завода.

Никогда нельзя забывать, что целевая система это не "объективно существующая", а привязанная к вашему проекту. Поэтому "пошевелить" возможный состав потенциальной целевой системы (контрфактульное мышление, о возможных мирах, в которых всё то же самое, что в нашем, но какой-то один момент отличается) -- это хороший мыслительный приём, позволяющий оценить "наш" проект от потенциально бесконечного количества всех возможных проектов, хороший ход против переобобщения. Конечно, тянуть цепочку обеспечения как можно дальше (думать о клиенте клиента) это правильно, но нужно ещё и экономить мыслительные/вычислительные ресурсы. Ход с "мысленной заменой" позволяет обрезать лишние звенья цепи. Что при таких заменах не меняется -- это ваше, а что меняется -- это уже проекты людей дальше по цепочке обеспечения, или дальше по уровням окружения.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10221319900841077
2021 год

Цифровой -- это новый информационный, цифровая нить -- это новая интеграция данных

Цифровая трансформация, инженерия, модель, тень, нить и так далее
В языке медленно, но верно слово цифровой/digital заменяет слово информационный/information. Где лет десять назвали бы "информационный", сегодня называют "цифровой". Означает ли это хоть что-нибудь? Нет, ничего особенного, кроме как вы будете попадать в правильные строчки бюджетов, если будете следовать моде. Под "организационные изменения" и даже "организационную трансформацию", равно как и под "автоматизацию/компьютеризацию" деньги не дадут, а вот под "цифровую трансформацию" -- пожалуйста. Ещё объяснят, что это ж вы будете думать и о людях, и о компьютерах, и о бизнес-моделях, как будто это в голову не придёт при использовании более старых терминов для того же (подробней я писал об этом год назад в "Об цифровую трансформацию: то же оргразвитие, и даже не в профиль", https://ailev.livejournal.com/1497402.html, там был и слоган про "больше buzzwords богу buzzwords"). Но новых "цифровых" терминов в коропоративной цифре (раньше бы сказали "айти", но поддамся тренду) к началу 2021 года резко набежало, давайте с ними разберёмся.

Речь пойдет о digital transformation, digital engineering, digital engineer, digital twins, digital model, digital shadow, digital thread, SDM (simulation data management), model-based engineering, model-based systems engineering, digital mission engineering, и тут давайте пока остановимся (игнорируя всякие маркетинговые терминологические затеи одной фирмы, типа specification data management, который формулируется как "высокоуровневый PLM", https://specright.com/blog/specright/whats-the-difference-between-product-lifecycle-management-and-specification-data-management/).

Сразу оговорка: о значении этих терминов в мире так и не договорились. Поскольку нет ни одного законодательного органа одной страны, ни одного комитета по стандартизации, ни одного факультета в каком-то университете, где приватизировали бы язык, есть множество документов, в которых даются самые разные толкования этим терминам. А ещё язык живёт независимо от всех этих официальных документов и словарей, и люди в самых разных фирмах используют эти слова уж как бог на душу положит. И помним, что словарные значения -- это значения вне контекста какого-то проекта, а в конкретных высказываниях у всех этих слов появляется ещё и уточнённый контекстом смысл. Но не всё так плохо: несмотря на дикий разнобой в значениях можно понять, о чём идёт речь. Уж точно не о сыроварении и не о бирюзовых организациях! Нельзя сказать, что "эти термины вообще ни о чём".

С цифровыми двойниками мы разобрались ("Цифровые двойники: физика ведёт математику, математика ведёт компьютерную науку", https://ailev.livejournal.com/1549559.html). Цифровые двойники/digital twin -- информационные/цифровые модели aka виртуальные системы для киберфизических систем (реальных экземпляров hardware), существующие на всём протяжении их жизненного цикла, особенно включая эксплуатацию.

Если мы провалимся на системный уровень выше, то получим сеть цифровых двойников/digital twins network. Если провалимся на уровень ниже, то получим целый ряд моделей как по разным viewpoints на стадии эксплуатации, так и по жизненному циклу (все эти механические, электрические, тепловые и прочие модели).

Цифровая инженерия: делаем цифрового двойника и связываем его цифровой нитью
Цифровая нить/digital thread -- это технология (инструменты и практика федерирования-объединения-интеграции данных, обычно на основе так называемых семантических моделей данных/semantic data models, тысячи их), связывающая между собой все эти отдельные модели, а также цифровые двойники окружения и физического двойника. Инженер старой закалки скажет "интеграция данных жизненного цикла" и помянет множество PLM (а если это не машиностроение, то помянет "корпоративную шину данных"), менеджер новой закалки скажет "цифровая нить" и помянет PLM, ERP, EAM и даже CRM (и вообще всё остальное). И, поскольку "цифровой -- это новый информационный", то заметят, что для какого-нибудь здания или моста кроме BIM/building information model цифровая нить добавит к цифровому двойнику данные дронов, сенсоры интернета вещей и какой-нибудь искусственный интеллект обнаружения аномалий для ремонта по состоянию. А разве это не предусматривалось концепцией BIM? Предусматривалось, но тогда и деньги были бы прежние. А цифровая нить -- это новый бюджет, новые слова для новых денег! Скажем, вы просите денег на интеграцию данных жизненного цикла, какие слова будете говорить? А тут говорят так: Digital thread -- golden thread of information that runs right throuht the life cycle of a project, the thread that grows and gathers more strands until it develops the heft and weight of a digital twin (https://www.raconteur.net/technology/digital-engineering-what-is-it-and-why-you-need-to-know-about-it/). Инженеры старой закалки продолжают говорить "управление информацией" или "управление данными", их эта менеджерская поэзия не увлекает. Так, если нужно сшить между собой мультифизическую модель (модели нескольких физик -- механическую модель, электрическую модель, тепловую модель, акустическую модель и т.д.), то инженеры будут говорить управление данными имитационного моделирования/SMD/simulation data management, а менеджеры старой закалки предпочтут говорить управление информацией (имитационного/мультифизичного) моделирования/simulation information management (но говорят так довольно редко, менеджеры до этих тонкостей уже не доходят, они больше про "нить").

Цифровая инженерия/digital engineering -- это создание цифрового двойника путём сплетения цифровой нитью различных его моделей, экземпляра его физического двойника и цифровых двойников окружения. Цифровой инженерией занимается цифровой инженер/digital engineer, и сразу признаётся, что знания цифрового инженера должны быть настолько широки (вся просто инженерия и всё просто айти), что его роль выполняется обычно большими командами.

Если цифровая нить не привязывает экземпляр цифровой модели цифрового двойника к физическому двойнику (экземпляру киберфизической системы, чей двойник), то это просто цифровая модель/digital model, данные к ней и из неё попадают "вручную", асинхронно. Если цифровая нить привязывает физического двойника к модели, и модель обновляется автомагически, то это будет цифровая тень/digital shadow. И только если цифровая нить привязывает не только физического двойника как источника калибровочной информации для модели, но и модель как источник калибровочной информации для физического двойника -- вот тогда это полноценный цифровой двойник/digital twin. И помним, что формально для ответов на вопросы "а что если..." можно породить несколько digital siblings (ибо они не будут соответствовать полностью физическому двойнику, их не любят называть цифровыми двойниками, но признают кровное родство).

Вот в этой картинке (из https://www.cadmatic.com/en/resources/blog/digital-model,-digital-shadow,-or-digital-twin-%E2%80%93-what-is-at-the-core-of-data-driven-shipbuilding/) пунктирная нить означает ту самую цифровую нить:

Вот типичное софтовое предложение для организации цифровой нити, найдите хоть одно отличие от предложений по организации PLM и интеграции данных жизненного цикла: https://prostep.us/cpmn/apidt/digital-thread-and-digital-twin-solutions/ (и да, это предложение от фирмы, которая традиционно занималась тематикой PLM, а дальше просто переписала свои тексты с использованием модной лексики).

Вот картинка новой V-диаграммы от Boeing, в которой поминается ещё один синоним для цифровой инженерии: моделеориентированная инженерия/model-base engineering/MBE, и теперь это не V, а MBE-ромб/diamond, с 2018 (https://www.incose.org/docs/default-source/midwest-gateway/events/incose-mg_2018-11-13_scheurer_presentation.pdf):

В этой диаграмме к традиционной V-диаграмме физической системы/двойника добавлена симметричная Λ-диаграмма цифрового двойника, а серединка отдана цифровой нити (вместо показа традиционных для этой диаграммы проверок и приёмок).

MBE любят в NIST и туда включают модели требований, архитектуры мультифизику и всё остальное, в отличие от INCOSE, которая любит MBSE/model-based systems engineering/моделеориентированную системную инженерию с акцентом на модели требований и архитектуры и меньшим акцентом на мультифизику -- но в INCOSE тоже переобуваются на ходу, и ветер там дует с военной стороны (см., например, как определяют digital engineering в SEBoK, https://www.sebokwiki.org/wiki/Digital_Engineering -- прямо ссылаются на DoD и в тексте, и в литературе).

Цифровая трансформация/digital transformation -- это прежде всего постановка практики цифровой инженерии, переход к тому, чтобы физические двойники (предприятие в ходе его работы, пациенты в ходе операции, здания в ходе эксплуатации, самолёты в полёте) управлялись со стороны своих цифровых двойников. Если этого нет, а просто вы ставите какую-то ещё одну базу данных и ещё одну систему аналитики, вроде как можете говорить о big data всём таком прочем модном, можете добавлять что-нибудь про цифровую тень но слово "цифровой" для такой трансформации говорить должно быть неудобно. Но с этим, конечно, никто не считается.

Военная цифровая инженерия
Как всегда, волну новой терминологии оседлали военные, прежде всего США. Они сходу объявили, что у них теперь цифровая инженерия, а в ней цифровая инженерия (военных) миссий/digital mission engineering -- удостоверение того, что вся инженерная работа как-то повлияет на результативность военных миссий. Если вы начнёте искать в сети всю эту цифровую терминологию, то найдёте много военного (они хорошо разрабатывают регламенты, стандарты и прочее подобное, что в нормальном бизнесе аккуратно срезается lean-подходом) -- так что аккуратней с источниками. Вот вам ссылки на тексты военных, прелесть ведь как всё структурировано, но не факт, что именно в этом виде оно будет хорошо работать в коммерческом секторе (факт, что не будет):
-- "What Is Digital Engineering and How Is It Related to DevSecOps?", ноябрь 2020, https://insights.sei.cmu.edu/sei_blog/2020/11/what-is-digital-engineering-and-how-is-it-related-to-devsecops.html (помним, что DevSecOps -- это те же DevOps, только с добавкой безопасности. Это ж военные!). При этом чётко говорится, что это всё для спасения жизней в том числе разработчиков и испытателей (во время испытаний F100 в 50-е погибли 324 пилота и потеряно 889 самолётов, https://en.wikipedia.org/wiki/North_American_F-100_Super_Sabre, а "цифровые испытания" позволяют сократить потери в подобных проектах).
-- "Digital Engineering Metrics. Supporting Technical Report SERC-2020-SR-003", июнь 2020, https://sercuarc.org/wp-content/uploads/2020/06/SERC-SR-2020-003-DE-Metrics-Summary-Report-6-2020.pdf (в этом отчёте старинное MBSE/model based systems engineering из INCOSE используется как синоним с Digital engineering, хотя MBSE это только часть digital engineering, ибо в MBSE обычно поддержка работы с требованиями, архитектурой и планами испытаний, а в digital engineering ещё и non-architectural part of design как минимум, плюс ремонт и обслуживание на стадии эксплуатации, во время работы digital twin. И это ж военные и государственные: если вы хотите попросить приличных денег за цифровую инженерию, то вам сюда: десятки метрик для оценки этой самой цифровой инженерии! KPI получите в количестве, никаких денег не хватит, чтобы их выполнять и по ним отчитываться! И упор тут именно на digital transformation: как определить, идёт трансформация, или таки не очень. Но если вам вдруг выпало заняться информатизацией, тьфу, цифровизацией, тьфу, цифровой трансформацией в части постановки цифровой инженерии, то это хорошие чеклисты: о чём нужно подумать -- но ни в коем случае не делать всё сразу, ибо тогда точно не сделаете, но зато освоите много денег, по круглой сумме за каждую метрику. Вот прямо берёте метрику и заключаете какой-нибудь договор на её реализацию с кем-нибудь, будет не хуже, чем в армии США).
-- digital mission engineering, https://www.agi.com/digital-mission-engineering (больше всего тут материалов от AGI, an ANSYS company -- поставщик софта для системной инженерии в военных применениях, вот и смотрите материалы на этой странице). Можно ли это применить гражданским? Ну, считайте, что речь идёт о нацеленности всей инженерии на эксплуатацию в условиях разнородного окружения целевой системы.

Смотреть новости по всему этому богатству цифровой инженерии можно на порталах https://www.plmportal.org, https://www.digitalengineering247.com, на немецком https://www.digital-engineering-magazin.de/. А что со старинными названиями? Например, "автоматизация"? Тоже всё найдёте, https://www.automation.com/ -- ресурс международного общества автоматизации. Ну, вы поняли: где раньше занимались PLM, автоматизацией, САПРами, инженерным моделированием, там и продолжают заниматься. Но слов стало больше, и ресурсов стало больше. Ну, и старые слова тоже вполне живут, люди-то никуда не делись. По последней ссылке вы найдёте и smart manufacturing (Industry 4.0), и integrated manufacturing business operations, и IIoT/Industrial Internet of Things.

Для не-заводов всё тоже цифровое, но единства в терминологии ещё меньше
У банка, страховой компании, вуза, логистической компании и многих других нет PLM, но цифровая трансформация есть. У нас для них советы:
-- иметь таки для их целевых систем цифровых двойников, а для этого целевую систему придётся таки найти в физическом мире как физического двойника.
-- считать, что прохождение кейсов по проектированию, как бы "изготовлению" и как бы "эксплуатации" (как это у них называется? у всех ведь по разному) -- это цифровой банкинг, цифровое образование, цифровое страхование и т.д.. Тем более что все эти слова есть (и означают в том числе уход в онлайн плюс ту же автоматизацию и биг дату с data-driven enterprise, тьфу, это ж теперь цифровая трансформация!).
-- смело пересказывать тексты и идеи промышленников, заменяя слова, там ведь всё то же самое. Не забывайте только вставлять слова про privacy, safety и security, хотя и у промышленников compliance через слово. С другой стороны, там везде и своих слов хватает. Но если вам приходится работать и с промышленными предприятиями, и банками, то лучше бы как-то экономить мышление и научиться думать о самой разной цифровой трансформации одинаково.

Обычно непромышленные организации идут впереди промышленных, у них что сейчас происходит с цифровизацией? Ну, hyperautomation/AI-Transformation/Digital Process Automation/Intelligent process automation (и ряд других терминов от разных лавок, пока совсем-совсем не договорились, вот обзор терминологии: https://research.aimultiple.com/hyperautomation/ (там полный винегрет изо всех идей, абсолютно разноуровневый). Отличается всё это от цифровой инженерии только тем, что явно и специально поминается через слово искусственный интеллект и машинное обучение, но не говорится о том, куда этот интеллект употребляется (а тут как с людьми и употреблением естественного интеллекта: нельзя ничего сказать, использовать-то можно везде!). В инженерии проще: объявляем эти "искусственные интеллекты" просто какими-то отдельными моделями/вычислителями и вплетаем их цифровой нитью в состав цифрового двойника. А что тогда RPA? Ну, это инструментарий цифровой нити, который может связать и текущий корпоративный софт, и вплести в него а хоть и людей. Интерфейсы к живым людям в PRA тоже есть, Текущий RPA состоит из набора коннекторов к софту, набора коннекторов к человеку (все эти распознавания речи), плюс BPM-движка (можно думать, насколько там близко к case management -- они ж себя процессниками считают, и языки там типа CMMN есть, хотя пока выглядит как "голимый недоBPMN". Но это ж ровно то же самое, что PLM, только данные берём не сапровские, и не только через API, но и через формы, и непосредственно от живых людей!

Так что терминологию цифровизации/цифровой трансформации для всех этих разных предприятий меняем, а мышление -- нет. Оно продолжает быть системным и вычислительным, трансдисциплинарным.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10220193584883882, обсуждение в чате блога -- с https://t.me/ailev_blog_discussion/5866
2021 год

Доклад "Будущее инженерии"

Сделал сегодня доклад "Будущее инженерии" на стратегической сессии лаборатории робототехники "Сбербанка", вот слайды доклада: https://yadi.sk/i/u4ObuTYbbPgf-g (видео не писалось).

Многое я уже рассказывал в других местах, но кое-что было и новое. Например, цикл жизни технологий (обсуждалось недавно в https://us13.campaign-archive.com/?u=67bd06787e84d73db24fb0aa5&id=320c223523):
-- Standardisation [deep learning – ONNX, и весь AI сейчас по факту ещё и этой фазы не достиг, то есть это всё ещё игрушки и эксперименты, а не промышленность]
-- Usability (удобные интерфейсы)
-- Consumerization (массовое потребление)
-- Foundationalization (изо всех утюгов, «потребление незаметно»)

Один из ведущих трендов в AI сегодня: «индустриализация» -- уменьшение затрат (в том числе денег, энергии, материалов, времени) на единицу пользы. Гипотеза Rich Sutton: прогресс определяется доступной вычислительной мощностью при простых алгоритмах. Вот максимизировать использование вычислительной мощности -- это и есть задача индустриализации. Ускорить сетку вдесятеро, или уменьшить потребную мощность вдесятеро -- вот это всё и есть индустриализация. Сегодня AI очень дорогой по времени и ресурсам, вот это и решается индустриализацией -- переход к массовости возможен после обрушения цены. И вот эти standardisation-usability-consumerization-foundationalization и есть стадии, по которым лабораторная технология становится промышленной.

Вот ещё модифицированная V-диаграмма с парой трендов на ней:
Vtwins

Штука в том, что digital twin идёт из воплощения системы в обеспечение (традиционное обсуждение того, зачем нужен digital twin -- диагностика, эксперименты what if, данные для дообучения алгоритмов управления, данные для улучшения варианта следующей конструкции и т.д.), а документация системы из обеспечения в воплощение (автономность, resilience, самодиагностика, самодонастройка и прочее для resilience).
2021 год

Встраивание проекта в программу: анонс курса

Вот видеоанонс доклада А.Турханова по встраиванию проекта в программу, который будет 8 февраля 2018 года на заседании сообщества Школы системного менеджмента (https://www.facebook.com/alex.turkhanov/videos/10215024391140284/):


Мы обсуждали этот материал на заседании методсовета Школы 25 февраля 2018, и обратите внимание на русскоязычную терминологию -- там есть много интересных наших находок последнего времени.

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

Увы, содержание доклада без прохождения курса онто-логического фитнеса (или аналогичной самоподготовки) и системного мышления (или аналогичной самоподготовки) просто не понять. Все эти "обеспечивающие системы" да "онтики". Поэтому доклад главным образом будет для сообщества выпускников Школы (http://system-school.ru/event/seminar-soobshtestva-shkol-kak-polyzovatysya-spektrom-mshleniya-vo-vsm-diapazone-ot-intuitivnogo-do-formalynogo-2018-02-08/). Они поймут. Это не сектантство, это не эзотерика. Все слова из международных стандартов, ничего сами не выдумываем. Просто за пару часов доклада и обсуждения нужно обсудить довольно много материала, и нужно его уметь компактно излагать. Без "умных слов" получится впятеро дольше, обсуждения "на пальцах" займут два дня. Собственно, и сам доклад во многом про это: без специальных знаний по инженерии предприятия и знаний по системной инженерии втыкаться в более-менее сложные промышленные кооперации уже сложно, а будет ещё сложней. Так что придётся садиться за парту и осваивать все эти многочисленные практики, а в них хитромудрые дисциплины и навороченные технологии. Никто не обещал, что в 21 веке с бизнесом будет легко.
* * *
А пока потихоньку готовится этот новый тренинг (или даже не тренинг, а практикум -- не только новый материал, упражнения и решения задач, но и рабочие сессии на реальном материале участников), Александр будет вести 10-11 февраля 2018 очередной поток тренинга "Основы системного лидерства": http://system-school.ru/event/kurs-osnov-sistemnogo-liderstva-2018-02-10/.
2021 год

Онлайн курсы системной инженерии: насколько современной?

Перед тем, как брать западные онлайн-курсы системной инженерии, нужно прочесть, например, текст "Сколько стоит вертолёт" -- https://lenta.ru/articles/2017/01/18/helidev/ (зажравшийся аэрокосмос, на три четверти военный и на четверть регуляторно гипербезопасный по сравнению почти с чем угодно) в сочетании с текстом "что на свете всех сложнее? автомобили вырываются вперёд!" https://ailev.livejournal.com/1398456.html. Ну, или материал о том, как космическая инженерия ULA отличается от космической инженерии SpaceX с точки зрения траты денег американских налогоплательщиков (к нашей космической промышленности эта дискуссия тоже относится): https://www.nextbigfuture.com/2018/01/spacex-crushing-ula-in-terms-of-value-for-us-taxpayer-dollars.html

На планете сейчас много разных системных мышлений, много разных системных инженерий. И много дедушек (часто в форме! военные системные инженеры!), готовых поделиться рецептами выигрыша в прошлой войне. Крайне дорогими рецептами выигрыша, которым они выигрывали деньги и бюджеты лет тридцать назад, а десять лет назад которые они переложили в курсы и вот сейчас довели их до онлайна.

Вот NASA и Boeing делали курсы моделеориентированной системной инженерии с MIT, по сходной цене: https://mitxpro.mit.edu/courses. Догадайтесь с трёх раз, какая из самых разных вариантов системных инженерий там представлена? Дорогая и медленная, или быстрая и подешевле? Кстати, я всегда выступал против курса https://www.coursera.org/learn/systems-engineering -- заучивать стадии жизненного цикла типового военного проекта IMHO просто бессмысленно, для меня это не системная инженерия, а "военная инженерия" (но, конечно, в самом курсе никто этого уточнения про "военность" не сделает, об этом не принято говорить).

В курсах от MIT, конечно, SysML, как же иначе. Мне очень по совокупности причин не нравится SysML. AADL в этом плане может быть не хуже. И даже для многих случаев ArchiMate 3.0 (который к тому же теперь расширяемый) тоже может быть использован. И это не учитывает самые разные варианты развития DSL для моделирования -- информатика-то на месте не стояла. Так, можно бы возвращаться к разговорам про SysMoLan на базе а хоть и Julia, особенно после того как Modelica и Julia нашли друг друга: https://ailev.livejournal.com/1366789.html

Так что я бы сейчас ориентировался в методах даже больше не на аэрокосмос, где бегают лишние деньги и поэтому не всё эффективно, сколько на automotive -- и какой-нибудь совсем-совсем передовой automotive, а не тех дедушек, которые ушли на пенсию и помнят как круто делались автомобили в 2008 году. В 2018 году совсем другой time to market, делать нужно совсем другую киберфизику (роботакси), на совсем других САПР и PLM, с совсем другим станочным парком на производстве. Это другая системная инженерия, и учить нужно этой другой системной инженерии.

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

Так что чему учить в системной инженерии прямо сегодня, нужно тщательно выбирать. В университетах раньше были авторские курсы всегда, исследователи-профессора читали самое свежее ими наработанное. Сейчас ВУЗы разделились на "вторичные" и "первичные" ровно по этому признаку. В одних читается свежатинка и state-of-the-art, в других -- "классика". С одной бедой: в инженерии "классика" (классика -- это ведь "образец для подражания") безнадёжно устаревает каждые несколько лет. И её нужно безжалостно менять, инженерам нечего подражать инженерам древности, им не нужно пользоваться кульманами и логарифмическими линейками. К учебным программам системной инженерии это тоже относится, они не должны учить системной инженерии прошлого.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10212099338732787
2021 год

WiFi роутер как радиолокатор

Самые интересные фразы в современных работах по WiFi-локации, так это typical household Wi-Fi transmitters operating in the 2.4 and 5 gigahertz bands were sufficient ... Even Bluetooth and cell phone signals can be used. The wavelengths of these devices correspond to a spatial resolution of a few centimeters. ... Future Wi-Fi frequencies, like the proposed 60 gigahertz IEEE 802.11 standard will allow resolutions down to the millimeter range -- https://www.tum.de/en/about-tum/news/press-releases/detail/article/33897/. И речь идёт не просто о радиолокации, а о построении трёхмерной голограммы.

И применения WiFi-локаторов могут быть самые необычные. Ссылка вверху говорит про отслеживание движения заготовок по цеху. Но могут быть и более оригинальные применения, типа эмоции-радиолокатор. Измеряют ритм сердцебиения и дыхания по отражениям WiFi сигнала, из них определяют эмоции с 87% вероятностью -- http://eqradio.csail.mit.edu/, http://bigthink.com/robby-berman/new-tech-can-accurately-read-the-emotions-you-may-be-hiding

И это в тот самый момент, когда алгоритмы компьютерного зрения на базе deep learning показывают чудеса в оптическом диапазоне. Как будто мало этих чудес, ещё давай! Микроволновую голограмму давай, от WiFi роутера, и чтобы через стену видел и под одеждой!

UPDATE: обсуждение https://www.facebook.com/ailevenchuk/posts/10210258988045170
2021 год

Автомагическое моделирование данных

Сегодня с одним из западных инженеров обсуждали странное: он утверждал, что любые попытки автоматизировать инженерную работу будут наталкиваться на саботаж со стороны инженеров -- ибо общепринятый способ оплачивать инженерный труд это почасовка, а автоматизация эту почасовку значительно уменьшает. Про конкуренцию ему, похоже, ничего не известно, "все инженерные компании во всех странах не хотят автоматизировать работу с данными -- там везде технологии 80-х, большие стройки идут на эксель-таблицах". Он считал, что "не хотят". Моя точка зрения -- "не могут".

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

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

Я рассказал про интересные новости в части прохода от формального языка к естественному языку для работы с данными -- Naturalizing a Programming Language via Interactive Learning, https://arxiv.org/abs/1704.06956. we start with a core programming language and allow users to "naturalize" the core language incrementally by defining alternative, more natural syntax and increasingly complex concepts in terms of compositions of simpler ones. ... Over the course of three days, these users went from using only the core language to using the naturalized language in 85.9\% of the last 10K utterances.

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

Например, ещё есть заход Wolfram language с попыткой принимать запросы на естественном языке (с переспросами, если что-то неочевидно).

Экспериментов много, но промышленного прорыва, как с тем же самым экселем или реляционными базами данных, нет. Таблицы вместо текста оказались killer application. Графы вместо текста много, много богаче таблиц. Они радуют глаз, когда они на страницу. А когда они в промышленных масштабах, то глаз радуется, а мозг огорчается. А таблицы в промышленных масштабах мозг не расстраивают, хотя таблицы и не так красивы для глаза. Следствие: нерасстроенный и радостный мозг не знает, как все эти таблицы объединять! Поэтому строит граф, но "в уме", а не "в компьютере".

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

Искусственный интеллект, решающий задачи моделирования, выделения важного из неважного, абстрагирования (специально не пишу тут слова "автоматизация", потому как речь не идёт о замене человека -- тут будет какой-то совсем другой набор практик. Так, персональный компьютер не автоматизировал работу секретарей и операторов ЭВМ, хотя и отнял у них работу. То же самое будет и с моделированием данных: ИскИн не автоматизирует работу сегодняшних модельеров-онтологов, он предложит совсем другие способы решения проблем.

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

Есть много идей, как восстанавливать и верифицировать инженерные модели данных масштаба жизненного цикла. Но это пока исследования. Промышленных технологий нет, купить на рынке пока можно только обещания сладкой жизни путём невероятных затрат ручного, тьфу, головного труда. Но всё будет, никуда не денется. Более того, всё будет относительно быстро.

Разговор с тем инженером закончился приятно: он похвалил наш инструмент -- .15926, https://github.com/TechInvestLab/dot15926. Славный был проект, мы многому в ходе этой работы научились.

UPDATE: дискуссия в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10210042527753798
2021 год

Разговорчики в сети

На этой неделе:

-- у Корнилова про одновременное существование многих разных будущих наряду с устаревшим "настоящим": в настоящем станочки, в будущем ЧПУ и ардуинки, и тут же работают какие-то тёмные фабрики, хотя пока и небольшие. ВУЗы ориентируются на "близкое будущее" с ЧПУ и ардуинами, но "тёмные фабрики" уже не менее близкое будущее. Я там много комментирую (вон она, сингулярность, когда сам чёрт не понимает, что происходит на фронтире, а фронтир везде), заканчивается всё неожиданно в диалоге с Боровковым -- "глобальные рынки" и палитра разных "будущих уже сейчас, хотя и неравномерно распределённых" существуют там, где много политической и экономической свободы, а в остальных местах получаются местечковые рынки и палитра разных "настоящих". Читать тут: https://www.facebook.com/alx.kornilov/posts/1879718158906411.

-- в Школе системного менеджмента с Вячеславом Колесниковым, он вдруг не читая (а потом "читая по диагонали") начал обсуждать полезность и осмысленность курса системного мышления, сравнивая его с подходами СМД-методологии. Как будто мне не ясно, что за два дня тренинга системного мышления не освоишь! И как будто эти два тренинга для освоения системного мышления бесполезны! И как будто на свете есть только одна методология, системомыследеятельностная, которая верна на момент остановки в своём развитии в начале 90-х! Читать тут (хотя я там не так много ссылок даю, можно было бы и больше): https://www.facebook.com/system.school.ru/posts/625992154258022

-- у Шперха вопрос про жизнь сетевых сообществ, почему она такая короткая. Я там комментировал про разницу между предприНятиями (коллективами, командами) и собственно сообществами (тусовками). Одни дело делают и продукт/сервис предоставляют, а другие лялякают. Одни поддерживаются "форумами" и прочими "социальными сетями", а другие системами управления конфигурацией и изменениями (типа GitHub, википедия -- это ж движок управления версиями текста!). Читать очередной трёп сообщества по поводу сообществ тут: https://www.facebook.com/photo.php?fbid=10158403732220153&set=a.10150756245230153.722787.658410152&type=3

-- мои комменты к видео Laurent and Adeline, которых топикстартер назвал "повелителями музыкальности" в kizombamoscow: https://vk.com/wall-24773547_9362, а ещё там же коммент к смешной картинке про "созерцание вместо тренировок", где я указываю, что дзен тоже может быть "визуальный" против "кинестетического", и даю ссылки на идеокинезис как "полезное для танцев созерцание": https://vk.com/wall-24773547_9357

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

Об отрасли

Отрасли -- это очень условная нарезка, подведение под произвольно выбранный классификатор. Часто отрасли были просто предприятиями, которые подчинялись одному министерству. Но сейчас и этого по бОльшей части нет (кроме напрочь зарегулированных, типа банков или больниц). Например, производящий насосы для атомных электростанций завод -- это атомная отрасль, или просто машиностроение? А если этот завод производит насосы и для нефтяников тоже? Или нужно смотреть, что этим заводом владеют, например, те же люди, которые владеют судостроительным заводом -- это что, уже будет судостроение? Но заказы для судостроителей на этом заводе могут занимать небольшое место.

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

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

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

Это я опять поругал профессии (напомнил про "закат профессий" http://erazvitie.org/article/zakat_professij), и заодно коснулся отраслей вот тут, в дискуссии про "Атлас профессий": https://www.facebook.com/shperk/posts/10157628132965153. В этой дискуссии Павел Лукша заметил, что и отраслей в будущем не будет -- и этому там удивились. Моя же точка зрения, что отраслей давно уже нет, фиктивное это понятие. Подведение предприятия под "отрасль" обычно непродуктивно и отражает не производственные, а регуляторные или прикладные маркетинговые реалии. Хотя в речи слово есть, и будет использоваться ещё много лет, как и слово "профессия", но его использование обычно не добавляет понимания. Нужно менять язык.

Хотя я сам раньше пользовался словом "отрасль", как и все -- ибо жил бок о бок с регуляторами. Вот, поглядите, например на мой текст 2004г., где я критиковал отраслевую концепцию развития ("рынка IT"): http://ailev.livejournal.com/246534.html. Там отрасль на отрасли и отраслью погоняет. Но уже в 2010 году я и использовал слово "отрасль" и возражал против этого (например, в пункте 1): http://ailev.livejournal.com/843404.html. А сейчас и вовсе избегаю, вполне сознательно. Слово "рынок" тут и то лучше. Ибо на рыке платежей сейчас и банки (по регулированию), и провайдеры сотовой связи с их телефонными платежами, и фирмы типа QIWI, а говорить об "отрасли" уже трудно -- ибо кто в эту "отрасль" из перечисленных попадает?!

UPDATE: в фейсбуке обсуждение тут -- https://www.facebook.com/ailevenchuk/posts/10208471452517899
2021 год

lytdybr

Обновил список системных мышлем в http://ailev.livejournal.com/1278600.html (по итогам обсуждений curriculum learning http://ailev.livejournal.com/1282190.html и с учётом предложений vvagr). До сих пор не могу определиться, как лучше: литературней, вроде, "мыслемы", но мне-то не мысль нужно, а мышление тренировать -- и язык всё время хочет говорить "мышлемы", элементы мышления.

В фейсбуке ввязался дискуссию про системную инженерию в СССР (и как сладко и державно в СССР было жить) по мотивам цитаты из моего учебника: https://www.facebook.com/mikhail.sofonov/posts/10210276152965443. Как всегда, набежали системотехники и начали рассказывать про великость системного подхода 1.0 и достижения отечественной системотехники.

В deep learning ложное затишье. Просто раньше было кап-кап-кап -- и каждая капелька была событием. А сейчас идёт бурный поток, и не понимаешь уже, что отслеживать -- героический период уже заканчивается, начинаются промышленные будни. Ну, типа полупроводниковой промышленности через пару лет после выхода Intel 4004. Дальше нужно придумать аналог закона Мура, типа "удвоения IQ вдвое за год" -- что бы там это IQ ни значил для слабого искусственного интеллекта. Помним, что этот IQ определяется как скорость решения множества мелких разнородных тупых задачек -- он на низкоуровневый процессинг. Вот тут трёхдневной давности список likely AI andvancements in the next 5 to 10 years от Yan LeCun, и по каждому направлению там кипит-бурлит: https://www.quora.com/What-are-the-likely-AI-advancements-in-the-next-5-to-10-years (и добавьте туда causal и counterfactual inference из https://www.quora.com/What-are-some-exciting-but-overlooked-developments-in-ML-research, а я ещё считаю, что уменьшение размерности плавающих в обучении, AutoML и аппаратный разгон ещё добавят жару). В любом случае, отслеживать происходящее уже очень сложно. Вон, почитайте ленту: https://vk.com/deeplearning.

Отрок осваивает синусы-косинусы, но шутки типа "в военное время синус до трёх доходил" понять пока не может. И вообще, вернулся из каких-то странствий Виталик, поэтому сегодня никакой геометрии и физики не было, был полный день Space Engineers, до состояния невменяемости. Завтра опять без геометрии и физики: тёща берёт его и жену за шкирку и отвозит на десять дней в Светлогорск (я опять вежливо выслушал традиционную тёщину лекцию про йод в воздухе из Балтийского моря, его безусловную пользу для подрастающих организмов, но сам останусь в Москве: у них троих уже сейчас коренные разногласия про времяпрепровождение в тамошних краях, я не буду им в этом мешать. Пусть тёща повоспитывает дочку и внучка эти десять дней без моего участия).

Вчера умер Сеймур Пейперт -- https://habrahabr.ru/company/edison/blog/277799/. Я в какой-то мере считаю себя прямым наследником каких-то его идей -- по лини Пейперт-Ершов-группа Аттик мехмата МГУ-я. Вот буквально пару дней назад поминал его в дискуссии, http://ailev.livejournal.com/1282836.html.