Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Вычислительное мышление, декабрь 2020: думаем о современных digital twins

Алгоритмический стек

Итак, мы говорим о чём-то типа "алгоритмического стека", определяемого в минимуме как:
-- прикладные алгоритмы ("бизнес-логика"), где понятия предметного мышления отмоделированы и мышление ведётся в них
-- алгоритмы Домингоса-Саттона (как описано в книжке The Master Algorithm и как помянуто в "горьком уроке" от Sutton)
-- алгоритмы Кнута-Шора (классика как описана в книжках Кнута и квантовые алгоритмы типа Шоровского разложения на множители, а ещё аналогичный уровень есть для спайковых нейронных и нейроморфных вычислителей типа мозга или спайкового хардвера)
-- физические вычислители (хардвер: классика, нейроморфика, оптика, аналоговые вычислители, квантовые и т.д.)
-- физика вычислителей (вещество и поля, из которых состоят вычислители)

Онтологическое замечание: конечно, алгоритмы -- это функциональные (как работает, а не из чего сделаны) описания физических вычислителей. Обсуждая платформенные/алгоритмические/вычислительные стеки мы обсуждаем вычислители как системы в физическом мире. Заморочки про то, что речь идёт о понятиях/типах (описания даются в типах, речь не идёт об описаниях экземпляров), нас пока не касаются: по этой линии примерно понятно как рассуждать. Вообще, если у вас есть понятие модели/описания и физического вычислителя как интерпретатора этой модели, то прокладывается мостик к системному мышлению с частями-целыми описаний, где эти части-целые трассируются к частям-целым вычислителей, с этими частями работающими. Да, там эмерджентность и несводимость онтологий (каждый уровень описывается в своей онтологии, а общей высшей/upper или даже foundational онтологии для описания всего стека нет), но наличие вычислителей в физическом мире даёт возможность для приземления/grounding всей этой понятийной конструкции. А ещё интеллект -- это вычислитель, он описывается алгоритмом интеллекта, и поэтому резервируем примерно этот же стек для алгоритмов, имея ввиду их вычислители. Оставим эти тонкости для онтологов и эпистемологов, пообещаем им когда-нибудь потом сделать описание стека получше, а сами пойдём дальше.

Стек интеграции данных (и вычислителей) жизненного цикла
Для объединения всего этого зоопарка (помним про no free lunch theorem, что для многих классов задач в проекте нужно много разных вычислителей) потребуется какая-то интеграционная платформа, что-то понимающая про интеграцию всех этих данных и маршрутизацию их для всех этих вычислителей. И отмечаем, что я тут впервые произнёс слово "проект": обратился к деятельностному взгляду на вычислительное мышление. Вычислительное мышление мы используем при обсуждении вычислителей не самих по себе, а работающих в проектах: моделирующих целевые системы проекта в их системном окружении, а также обеспечение (включая сами вычислители из обеспечения). По сути дела, тут я затрагиваю две линии дальнейших рассуждений:
-- линия вычислителя, моделирующего виртуальную реальность (разбирается Дэвидом Дойчем в его книгах). По этой линии выходим на эпистемологию: обсуждаем всё более и более точное моделирование в виртуальной реальности, разницу абстрактных/математических моделей и физического моделируемого мира, эволюцию этих моделей. В проекте мы строим виртуальную реальность этого проекта, всё более и более точно. Упор тут на многомасштабное/физическое/имитационное моделирование.
-- линия интеграции данных жизненного цикла/управления информацией, ибо речь идёт об описаниях систем в проекте. Это линия использования вычислителей в проекте (системы обеспечения), традиционно тут упор не на сами вычислители, а на их данные и моделирование данных (подготовка к имитационному моделированию/simulations окружения с целевой системой, управление конфигурацией при создании системы -- работа с данными сборки, проектирования, поддержка архитектуры расширенного предприятия проекта. В общем, возня с данными жизненного цикла, а жизненный цикл указывает на обеспечение.

Вычислительное мышление мы используем для выделения объектов внимания в обсуждении многомасштабного моделирования run-time и интеграции жизненного цикла в design-construction time каких-то проектов примерно так же, как системное мышление используем для обсуждения объектов внимания в проектах. Вычислительное мышление и системное мышление помогают организовать коллективное мышление в проектах, они тем самым прагматичны.

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

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

Интеграционная платформа тоже многоуровнева (и тоже помним, что вычислители, их алгоритмы, описания алгоритмов -- всё это мы онтологически потом почистим, об этом было замечание. Не пугайтесь разнородности описанных уровней, они про части-целые физических вычислителей, они системны):
-- вычислитель уровня цивилизации (всегда помним, что есть системные уровни выше нас интересующих. Вот производственная культура земли использует все мозги и компьютеры как вычислители. Ага, автостопом по галактике, результатом будет 42).
-- вычислитель алгоритма интеграции результатов вычислений прикладных алгоритмов
-- вычислитель алгоритма интеграции алгоритмов Домингоса-Саттона (раньше я называл это "когнитивная архитектура", "болван для искусственного интеллекта -- платформа когнитивной архитектуры общего вида, которая способна относительно легко и задёшево выучиться чему угодно -- примерно так же, как относительно легко и задёшево чему угодно может выучиться человек", это я писал в 2017, https://ailev.livejournal.com/1356016.html, за пару лет до выхода в ноябре 2019 работы Chollet и его формализации понятия интеллекта, https://ailev.livejournal.com/1498481.html).
-- вычислитель алгоритма интеграции алгоритмов Кнута-Шора, все эти application frameworks/библиотеки прикладных алгоритмов
-- интеграция физических вычислителей (электроника и квантроника: кластеры и шины)

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

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

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

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

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

Используем результаты моделирования телесного мышления: стек рассматриваем "изнутри наружу", с какого-то среднего уровня, где уже видна необходимость нижних уровней, и просто обрезаем верхние уровни и нижние -- временно. Мы для моделирования телесного мышления обрезали уровни прикладных дисциплин (спортивных и танцевальных), основное моделирование вели на примерах общетанцевального уровня и общевокального уровня (до мелодики и сольфеджио), а также общей для них мышечной работы -- не доходя до анатомии/медицины, всех этих названий мышц и костей. Оказалось, что для прикладных уровней обсуждение мышц -- редукционизм. Обсуждение здания в терминах кирпичей (а не стен) -- редукционизм. Строители при этом могут пообсуждать кирпичи в сборе, но вот в выбор глины для кирпичей они уже не идут, этим занимаются узкие спецы, их немного по сравнению со строителями. Обсуждение вычислений в проекте/системах обеспечения в терминах алгоритмов Кнута-Шора и тем более хардвера вычислителей -- редукционизм! Обсуждать нужно более высокие системные уровни, а к нижним нужно переходить по мере возникновения проблем.

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

Понимаем, что программирование-в-малом это уровень кнута-шора, а дальше пошло развитие вверх, понятие программирования-в-большом появилось в 1975, https://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small. Критика современной информатики, в частности, была в продолжении обучения информатике как "программированию в малом", а реальная жизнь идёт сегодня на уровне программирования-в-большом. Я много об этом писал, последний раз в "Умненькие дебилы: умны в деле-в-малом, дебилы в деле-в-большом". Акценты в современной информатике не лежат в школьной информатике.

Начинаем с digital twins
Мой ход в информатике -- идти в интеграционную платформу уровня проекта (по факту и уровня предприятия -- затрагиваем хлеб архитекторов предприятия, у которых описание IT-архитектуры предприятия это как раз описание "совокупного вычислителя"). Когда мы рассматриваем классический уровень programming-in-the-large (программирование больших приложений), то уже найдём много интересного для вычислительного мышления. Но мой ход ещё выше: уровень интеграции данных жизненного цикла. И именно в описании вычислителя для виртуальных миров проекта/моделей целевой системы (product data management systems для design-time, систем construction management, и digital twins как развитие систем asset management в сторону имитационного моделирования) и моделей систем в обеспечении (product lifecycle management systems).

Вот в описании этих PDM, PLM, EAM, digital twins мы и найдём все слова для описаний вычислений и их данных: ибо в этих системах вы должны описать "совокупный вычислитель" интегрированных данных жизненного цикла. И тут ещё нужно подумать над терминологией. Например, не "интегрирования", а более точно в смысле ISO ISO 11354-1:2011 -- федерирования, вот я об этом в 2016 году, https://ailev.livejournal.com/1307116.html (если системы разработаны так, чтобы взаимодействовать между собой -- это интеграция, если так, чтобы соответствовать стандарту взаимодействия -- унификация, а вот если нужно налаживать взаимодействие систем, которые друг о друге ничего не знали в момент разработки -- это федерирование).

Итак, смотрим, в каких терминах описывают итоговые вычислители люди, которым это позарез нужно: это архитекторы предприятий (если речь идёт о самых разных типах целевых систем), но если взять более классический случай системной инженерии, когда нас интересует сложность итоговой системы и сложность моделирования -- то берём вот эти самые PDM, PLM, EAM, digital twins и смотрим, в каких терминах описывают итоговые вычислители люди, это и будет SoTA вычислительного мышления на этом системном уровне.

SoTA тут не в PDM, PLM, EAM системах, а в digital twins -- это относительно новый класс систем. И это самое важное: моделирование/описание и связанные с этим вычисления идут на стадии эксплуатации, для готовой уже системы. В PLM никакого полного жизненного цикла по факту не оказалось, только проектная информация. В digital twin основное -- привязка исторических данных к экземплярам (PLM работает с данными проектирования, а оно ведётся "в типах"). По идее, в digital twin входят и данные "промежуточных" между design и run систем, использующихся, например, в управлении стройкой (digital construction management, наиболее известны Synchro, Navisworks).

Так что же в SoTA digital twins, какой язык используют для описания федерирования вычислений? Вот свеженький релиз Azure Digital Twins, 8 декабря 2020 -- https://venturebeat.com/2020/12/08/microsoft-launches-azure-digital-twins-in-general-availability/. И выписываем прямо оттуда (крупными кривыми мазками) заготовки для понятийного минимума вычислительного мышления для этого уровня, нужный для описания вычислений виртуальной целевой системы. И там сразу наши старые знакомые понятия:
-- knowledge graph, based on digital models of entire environment. Services that rely on virtual representations of objects, equipment, and work environments. Customers define the digital entities that represent the people, places, and things in their physical environment using custom twin types called models. For their parts, models define semantic relationships between entities so that companies can connect twins into a knowledge graph that reflects their interactions.
-- Digital Twins enables users to model environments such as buildings, factories, farms, energy networks, railways, stadiums, and cities by connecting assets like internet of things devices and existing business systems. Ура, наш директор стадиона тут тоже посчитан!
-- simulation. Helping users to track the past and then attempt to predict the future.
-- translating the real world into a version that can be understood by machines.
-- Models are defined in a language called Digital Twins Definition Language (DTDL), and they describe twins in terms of their state properties, telemetry events, commands, components, and relationships.
-- Digital models in Azure Digital Twins are live, up-to-date representations of the real world. Using the relationships in DTDL models, customers can connect twins into a live graph representing their environment.
-- Customers can connect external compute resources to drive data processing, extract insights from the live execution environment.

То есть мы попали в эпицентр вроде как очень низкоуровневого онтологического/эпистемологического разговора: есть мир систем, есть виртуальная реальность с моделями этого мира -- и предложен язык для описания систем в этой виртуальной реальности. Судя по всему, в основе этого языка лежат графы знаний, как-то привязанные к событиям (слово events там повторяется чуть не в каждой строчке) в физическом и виртуальных мирах.

Так что вроде всё сходится, научить нашего директора стадиона нужно говорить на этом языке. И он сможет обсуждать закупку системы digital twins, которая объединит и его системы IoT, и его системы IoB (новая фишка: интернет поведений -- камеры везде отслеживают ваше поведение, не скроетесь и не смоетесь), и системы AI (какие бы они ни были -- чистая аналитика или творчество с синтезом решений и выдачей управляющих предписаний).

Если берём не PLM, а SoTA digital twins для этого разбирательства, то сразу попадаем и в семантические системы (knowledge graphs), и многомасштабное моделирование (simulations). Ибо там нет legacy со стороны старинных PLM, где ничего такого нет и до сих пор пережёвываются идеи более чем двадцатилетней давности консорциума по разработке стандарта интеграции данных Epistle (1997 год, оттуда пошёл проект ISO 15926, так и закончившийся ничем. Но вот, в digital twins сразу knowledge graph -- то же самое, только в майкрософтовский профиль). ОК, с этой постановкой задачи всё устраивает.

А что с нижними уровнями? Квантовыми вычислениями?
А как же квантовый компьютинг? Он же получается где-то в самом низу стека? Да, и его не забываем. Он взорвёт всю организацию этого стека, всю организацию вычислений проекта -- ибо при смене физики нижних уровней приходится обычно перетряхивать весь стек до самого верха. Набор понятий, при помощи которого мы будем обсуждать вот этот взрыв, эту перекомпоновку стека -- это и будет язык вычислительного мышления, язык computer science, экспериментальной/естественной науки о доказательствах/выводе/вычислении/рассуждении.

Сколько у нас времени до этого волшебного момента очевидной победы квантового компьютинга? Года три ещё есть. Вот поглядите, broad quantum advantage (термин для момента превосходства квантовых компьютеров перед суперкомпьютерами и облаками в бизнесе), будет достигнут по плану в 2024-2025 годах. Помним, что через неделю уже будет 2021, то есть речь идёт о трёх годах: “Most people agree at about 72 qubits or so is the place where broad quantum advantage starts,” Chapman said. “That’s where quantum computers start to take on supercomputers. We’re probably looking into a roughly 2024-2025 timeframe for that. “What we’re talking about here is a line of application developer sitting at some corporation and making a decision as to whether or not to run it on a quantum computer, on the cloud, or on supercomputers. It’s not an academic exercise. It’s really at that point where average developers are saying, ‘Oh, I think this would be better on a quantum computer.'” -- https://venturebeat.com/2020/12/09/ionq-roadmap-quantum-machine-learning-2023-broad-quantum-advantage-2025/.

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

UPDATE: обсуждение в https://www.facebook.com/groups/771940449578453/permalink/3281825581923248/
Subscribe

  • lytdybr

    Очередной апдейт "Методологии" закончен (порядка 50 страниц вписаны за 7 дней -- это была переработка материала из постов, посты были переработкой…

  • Опубликована новая версия курса "Методология"

    Опубликована новая версия курса "Методология". В текущей версии графы создания стали графами создателей. Также добавлены подразделы, описывающие…

  • Двухдневный открытый семинар "Инженерия всего на пороге 2025"

    Я решил провести открытый двухдневный лекционный семинар "Инженерия всего на пороге 2025". Пройдёт в Москве (если кто хочет участвовать очно, но…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 2 comments