Почему со временем неизбежно изменяются методы программирования

На этом шаге рассмотрим понятие и причины сложности систем программного обеспечения.

Как известно, не все системы программного обеспечения являются сложными. Существует класс приложений, проектируемых, разрабатываемых, сопровождаемых и используемых одним и тем же человеком, — либо начинающим программистом, либо профессионалом, работающим в одиночку. Такие системы имеют очень ограниченную область применения и очень недолго используются. Как правило, их проще заменить новыми программами, чем пытаться повторно использовать, переделывать или совершенствовать.

В области разработки промышленного программного обеспечения можно найти программы, демонстрирующие самые разные виды поведения, например, системы с обратной связью, которые управляют или управляются событиями физического мира; программы, поддерживающие целостность баз данных, содержащих сотни тысяч записей; системы управления и контроля за реальными объектами. Такие системы используются долго, и со временем от их нормального функционирования начинают зависеть многие пользователи.

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

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

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

Требования, предъявляемые к системе программного обеспечения, в процессе разработки часто изменяются. Это еще больше повышает ее сложность. Как правило, техническое задание корректируется из-за того, что в процессе проектирования системы постановка задачи постепенно уточняется.

Системы со временем эволюционируют, по плану или спонтанно. Иногда этот процесс по ошибке называют сопровождением программного обеспечения. Точнее говоря, сопровождением (maintenance) называется исправление выявленных ошибок, эволюцией (evolution) — реакция на изменение технических требований, а сохранением (preservation) — попытка всеми возможными средствами продлить функционирование устаревших и распадающихся частей программного обеспечения. Как показывает опыт, значительная доля ресурсов, выделенных на разработку программных систем, тратится именно на сохранение.

Основная задача разработчиков программного обеспечения — создать иллюзию простоты, чтобы защитить пользователей от огромной и часто произвольной сложности проекта.

Для уменьшения размеров программ изобретаются методы, создающие иллюзию простоты и позволяющие повторно использовать существующие коды и проектные решения. Тем не менее требования, предъявляемые к системе, часто вынуждают проектировщиков либо создавать заново большое количество программ, либо использовать существующий код, адаптируя его к новым условиям.

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

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

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

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

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

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

На следующем шаге рассмотрим признаки сложной системы.

Теория сложности и проблема управления жизненным циклом изделий аэрокосмической промышленности Текст научной статьи по специальности «Компьютерные и информационные науки»

ЖИЗНЕННЫЙ ЦИКЛ ИЗДЕЛИЯ / УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ / PLM-СИСТЕМА / ПОДДЕРЖКА ПРИНЯТИЯ РЕШЕНИЙ / АДАПТИВНОЕ УПРАВЛЕНИЕ / СЕТЕЦЕНТРИЧЕСКАЯ АРХИТЕКТУРА / МУЛЬТИАГЕНТНАЯ ТЕХНОЛОГИЯ / СТРАТЕГИЧЕСКОЕ ПЛАНИРОВАНИЕ / ОНТОЛОГИЯ ПРЕДМЕТНОЙ ОБЛАСТИ / КИБЕРФИЗИЧЕСКАЯ МОДЕЛЬ / PRODUCT LIFECYCLE / LIFECYCLE MANAGEMENT / PLM-SYSTEM / DECISION-MAKING SUPPORT / ADAPTIVE MANAGEMENT / NETWORK-CENTRIC ARCHITECTURE / MULTI-AGENT TECHNOLOGY / STRATEGIC SCHEDULING / DOMAIN ONTOLOGY / CYBER-PHYSICAL MODEL

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Лахин Олег Иванович, Полников Александр Сергеевич, Симонова Елена Витальевна, Скобелев Петр Олегович

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Теория сложности и проблема управления жизненным циклом изделий аэрокосмической промышленности»

ОБРАБОТКА ИНФОРМАЦИИ И УПРАВЛЕНИЕ у/

ТЕОРИЯ СЛОЖНОСТИ И ПРОБЛЕМА УПРАВЛЕНИЯ ЖИЗНЕННЫМ ЦИКЛОМ ИЗДЕЛИЙ АЭРОКОСМИЧЕСКОЙ ПРОМЫШЛЕННОСТИ

О. И. Лахина, руководитель направления А. C. Полникова, аналитик

Е. В. Симоноваа’ б, канд. техн. наук, доцент, ведущий аналитик

П. О. Скобелева> б, доктор техн. наук, профессор, генеральный директор

аООО «Научно-производственная компания «Разумные решения», Самара, РФ

бФГАОУ ВПО «Самарский государственный аэрокосмический университет им. акад. С. П. Королева

(национальный исследовательский университет)», Самара, РФ

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

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

При проектировании, производстве и эксплуатации изделий аэрокосмической промышленности (ИАП) ставится задача повышения качества используемых технологических процессов и конечной продукции при различных условиях эксплуатации. Все в большей мере для экономии времени и денежных средств при управлении жизненным циклом изделий (ЖЦИ, PLM — Product Lifecycle Management) используются программные средства, основанные на знаниях, учитывающие особенности эксплуатации каждого отдельного изделия и позволяющие не только автоматизировать наукоемкие инженерные задачи, но и осуществлять поддержку принятия решений при эксплуатации и обслуживании изделия. В настоящее время в связи с растущей сложностью управления ЖЦИ и усиливающейся конкуренцией, а также высоким уровнем и динамикой изменения индивидуальных требований,

предъявляемых клиентом к изделию, необходимо применять сквозное и связное адаптивное управление ЖЦИ на всех его этапах [1].

В настоящей статье предлагаются новые принципы управления ЖЦИ аэрокосмической промышленности на основе применения сетецентри-ческого подхода, позволяющего создать интеллектуальную «систему систем» для повышения эффективности управления всеми основными этапами жизненного цикла сложных изделий, от проектирования и производства — до эксплуатации и утилизации.

Изделие аэрокосмической промышленности как сложная система

Управление ЖЦИ предполагает создание сложных организационно-технических систем, обеспечивающих управление всеми его этапами, начиная от концепции изделия, через его проектирование, конструирование и производство,

до эксплуатации, обслуживания и утилизации. В аэрокосмической промышленности изделиями являются такие сложные технические объекты, как космические и ракетные комплексы, космические корабли и аппараты, летательные аппараты (ЛА) и их системы, отдельные приборы и др. [2].

Несмотря на существенный прогресс последних двух десятилетий, по-прежнему наблюдаются значительные трудности, связанные с внедрением существующих автоматизированных PLM-систем. Главная проблема заключается в том, что вопреки декларируемым целям полного охвата жизненного цикла, на практике использование программных средств PLM до сих пор зачастую ограничивается стадией разработки и проектирования. Другой причиной низкой эффективности внедрения PLM-систем является отсутствие единообразных правил моделирования и сопутствующих методик программирования систем. Вследствие того, что в традиционных PLM-системах большая часть знаний содержится в неструктурированном виде, затрудняется отслеживание информации по стадиям жизненного цикла. Это ограничивает доступ к знаниям о каждом отдельном изделии в середине и конце его жизненного цикла и не позволяет передать достаточно информации на стадию проектирования и производства [3].

Знания неизбежно изменяются со временем, поэтому приложения, использующие их, могут стремительно устаревать. Существующие и разрабатываемые системы должны своевременно реагировать на происходящие изменения знаний об изделии в течение его жизненного цикла. В качестве решений проблемы предлагаются следующие: полное или частичное перепроектирование системы, инвестиции в интенсивное и высокозатратное обслуживание или полное прекращение поддержки системы, неизбежно приводящее к ее устареванию. Поэтому уже в процессе разработки PLM-системы необходимо предусматривать возможность изменения знаний в ходе ее эксплуатации и использовать методы, поддерживающие изменения на уровне программной реализации [4].

Сопровождение ЖЦИ аэрокосмической промышленности является сложной задачей вследствие высокого уровня неопределенности, постоянно присутствующего в системе. На практике это означает необходимость своевременного устранения отказов, происходящих в различных узлах с трудно прогнозируемой частотой. Можно выделить семь признаков сложности, на основании которых ИАП следует отнести к сложным системам [5].

1. Наличие связей — ИАП состоит из очень большого количества компонентов, отказы которых независимы друг от друга ввиду их функци-

онального назначения либо взаимного расположения. Задача управления заключается в своевременном выявлении узлов, способных отказать, фактически произошедших отказов, их возможных последствий и обстоятельств, приводящих к возникновению отказов. Кроме этого, обслуживанием ИАП занимаются различные наземные инженерные службы, при взаимодействии которых периодически возникают проблемы. Задача анализа состоит в выявлении человеческого фактора, влияющего на отказы, и в их устранении.

2. Автономность — способность действовать при отсутствии прямых указаний сверху. Хотя комплектующие ИАП не имеют физической автономности, они обладают автономностью в плане динамики отказов, а также частичной автономностью при выполнении их технического обслуживания. Задача заключается в выявлении степени автономности каждого компонента и ее влияния на динамику возникновения и устранения отказов.

3. Эмерджентность — динамика отказов системы является следствием проявления непредсказуемых индивидуальных отказов отдельных узлов. Вместо точного прогнозирования ставится задача выявления динамики вероятностей отказов. Если вероятность отказа отдельного узла непрерывно возрастает и в определенный момент превышает допустимое значение, надежнее заменить узел, не дожидаясь окончательного выхода его из строя.

4. Неуравновешенность — ИАП можно представить в виде динамической системы, которая не успевает вернуться в состояние равновесия в промежуток времени между двумя соседними внешними воздействиями. Например, отказавший узел может отличаться по своим рабочим характеристикам от узла, установленного на замену, что может повлиять на возникновение отказов в дальнейшем.

5. Нелинейность — сравнительно малый при прочих обстоятельствах отказ может привести к катастрофическим последствиям в системах ИАП. Задача состоит в своевременном выявлении всех возможных изменений, способных оказать влияние на надежность всего ИАП.

6. Самоорганизация — многие авиационные системы имеют резервные компоненты на случай отказа основных систем. При принятии решений относительно целесообразности замены компонентов необходимо учитывать уже существующие средства поддержки отказоустойчивости.

7. Сопряженность — поскольку отказы зависят от условий эксплуатации и технического обслуживания ИАП, можно представить динамику отказов как функцию от изменения этих условий. Другими словами, процессы возникновения и устранения отказов сопряжены не только друг

с другом, но и с изменяющимися внешними условиями.

Информация об изделии, содержащаяся в PLM-системе нового поколения, должна базироваться не просто на цифровом макете объекта, а на его действующей компьютерной модели, которая должна эволюционировать вместе с реальным изделием, интегрируя в себе знания о требованиях к изделию, о структуре и принципах его функционирования, особенностях эксплуатации, текущем состоянии и т. д. [6].

Новые принципы создания интеллектуальной системы управления ЖЦИ

Для решения поставленной задачи предлагается новый подход к созданию интеллектуальной системы управления ЖЦИ Smart PLM, построенной на принципах сетецентрического управления, мультиагентных технологий, онтологий предметных областей и киберфизических моделей изделий (рис. 1) [7].

Smart PLM представляет собой решение, которое строится «над» традиционными PLM-системами. Выделяется верхний уровень системы, который создается автономными интеллектуальными системами с использованием сервис-ориентированной архитектуры и общей информационной шины предприятия, что обеспечивает интеграцию данных всех подсистем в едином информационном пространстве для достижения заданных целей управления.

Таким образом, вместо одной большой PLM-системы на всех этапах будет строиться адаптивная р2р сеть взаимодействующих через общую шину мультиагентных планировщиков отдельных этапов ЖЦИ, подразделений предприятий или даже сотрудников. Планировщики смогут размещаться на персональных компьютерах, планшетах и сотовых телефонах, обеспечивая со-

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

Концепция «сетецентричности» жизненного цикла представляет собой новую систему взглядов на управление, ориентированную на конечный результат и достижение превосходства. Новизна предлагаемого подхода состоит как в использовании интеллектуальных систем управления этапами жизненного цикла, так и в обеспечении адаптивного р2р взаимодействия между основными интеллектуальными системами (к чему не способны традиционные системы), заменяя традиционные каскадные бизнес-процессы на адаптивные р2р взаимодействия систем по принципам «каждый с каждым» и «равный с равным».

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

Основными системами Smart PLM являются:

1) Smart Strategic PLM Planner — стратегический планировщик, обеспечивающий планирование жизни изделия на большой промежуток времени и координацию между отдельными системами;

2) Smart Design — поддержка принятия решений при проектировании изделий в ходе научно-исследовательских и опытно-конструкторских работ (НИОКР), во время которых части изделия самоорганизуются с учетом предлагаемых требований;

Smart Strategic PLM Planner

■ Рис. 1. Архитектура распределенной интеллектуальной PLM-системы

3) Smart Project — управление проектами НИОКР с поддержкой процессов командного управления в сложных междисциплинарных командах;

4) Smart Factory — оперативное управление цехами производства «точно в срок» и «под заданную стоимость» по целям и событиям в реальном времени;

5) Smart Transport — управление транспортом (грузовиками, РЖД, морскими перевозками и др.);

6) Smart Supply Chain — поддержка цепочек закупок и поставок внешних комплектующих при производстве и ремонтах, техническом обслуживании изделий;

7) Smart Maintenance / Smart Reliability — поддержка эксплуатации изделий, технического обслуживания и ремонтов.

Указанные системы будут интегрироваться с существующими классическими системами и использоваться для поддержки принятия решений и их согласования по методике виртуального «круглого стола» на базе общей шины предприятия/изделия.

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

Каждая из указанных систем должна поддерживать работу с моделями знаний предметной области, представленными в виде онтологий на основе семантических сетей классов понятий и отношений, что необходимо для формирования баз знаний, а также поиска и сопоставления вариантов для принятия управленческих решений [8].

Cетецентрический подход к построению системы управления ЖЦИ

В связи с большой сложностью задачи управления ЖЦИ аэрокосмической промышленности предлагается декомпозировать исходную задачу на последовательность локальных оптимизационных задач, решаемых по мере появления событий. Это означает, что структуры плана действий строятся не централизованно, а создаются в разных областях сцены мира агентов, связанных между собой. Такой метод, в отличие от прямых оптимизационных методов или обычных эвристик, основанных на правилах приоритета при централизованном планировании, называется сетецентрическим.

Сетецентрический подход к построению решения для управления ЖЦИ обеспечивает не просто передачу данных между системами, а выработку

согласованных решений в ответ на появление того или иного события. Предполагается, что системы постоянно работают в параллельном и асинхронном режиме, но в случае важных событий, нарушающих ранее принятые ими обязательства, могут обращаться друг к другу с сообщениями типа «Запрос», «Просьба», «Информирование», «Варианты», «Подтверждение», «Встречное предложение» и т. д. [7].

Предлагаемая интеллектуальная система управления ЖЦИ состоит из интеллектуальных подсистем управления его отдельными этапами с изначальной ориентацией на возможность адаптивного построения и согласованной корректировки планов по событиям, поступающим в реальном времени. Согласованность решений отдельных интеллектуальных систем при этом обеспечивается за счет разработки многоуровневой адаптивной р2р сети указанных систем, в отличие от традиционно используемых отношений «ведущий-ведомый» в каскадной модели бизнес-процессов управления предприятиями (рис. 2). Такая архитектура реализует основной принцип сетецентрического подхода — «Решать проблемы настолько локально, насколько возможно, и настолько глобально, насколько требуется». Только в том случае, если не удается решить проблему в одной из систем, начинается цепная реакция взаимодействий с другими системами, подобная расходящейся волне.

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

Общая схема работы «системы систем» под управлением стратегического планировщика показана на рис. 3. Системы нижнего уровня обеспечивают проектирование изделия (Smart Design), его производство (Smart Factory) и эксплуатацию (Smart Maintenance). Различные центры обслуживания конкретного экземпляра изделия собирают и обрабатывают информацию и статистику отказов, наработку узлов, динамику изменения показателей работы. В случае выхода одного или нескольких параметров за пределы нормативных планировщик передает запрос о возможности изменения либо требований к изделию и его перепроектирования или изменения конструкции, либо особенностей технологического процесса изготовления изделия.

■ Рис. 2. Сетецентрический подход к управлению в распределенной интеллектуальной PLM-системе

Smart Strategic PLM Planner

Изменение конструктивных элементов

Smart Maintenance («север»)

Smart Maintenance («пустыня»)

Дополнительные требования по результатам эксплуатации

Smar t Maintenance (общий центр обслуж иван ия)

■ Рис. 3. Взаимодействие систем в рамках Smart Strategic PLM Planner

В такой системе стратегический планировщик, построив первую грубую версию плана, «сбросит» ее вниз на согласование оперативным планировщикам центров компетенций, которые, спланировав свою работу автономно, начнут переговоры по горизонтали для согласования своих оперативных планов. Успешно созданные «внизу» планы будут взяты в разработку, а воз-

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

Модели и методы

для реализации сетецентрического подхода

Система построена на базе мультиагентного подхода [9]. Каждому элементу реальной конструкции и оборудования ставится в соответствие программный агент, выступающий от имени своего элемента. Задачи, возникающие на различных этапах ЖЦИ, должны быть запланированы и затем выполнены в реальном времени. Таким задачам также ставятся в соответствие агенты. При выполнении задач используются разнообразные ресурсы. Все сообщество агентов может быть реализовано в виде динамической сети задач и ресурсов, представляющей собой сеть потребностей и возможностей [10]. Поведение мультиагентных систем не определяется одним детерминированным алгоритмом, а формируется эволюционным путем как результат взаимодействия составляющих ее агентов.

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

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

Пример возможной реализации и взаимодействия систем управления ЖЦИ

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

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

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

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

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

Новое решение в плане пользовательского интерфейса заключается в том, что рядом с реальным ЛА постоянно «летит» его компьютерная киберфизическая модель, которая подсказывает,

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

Если при постоянных условиях эксплуатации один и тот же узел постоянно выходит из строя, можно сделать заключение о наличии изъянов в его конструкции. После того как в системе Smart Maintenance сделано такое заключение, вся информация об изделии, условиях его эксплуатации и отказах передается в систему Smart Design, где может оказаться целесообразным осуществить полное или частичное перепроектирование изделия в целях получения на выходе новой модификации, не подверженной столь частым отказам в заданных условиях эксплуатации.

Выработанные решения доступны в системе Smart Design через общую шину стратегического планировщика Smart Strategic Planner, который включается в планирование и функционирование Smart Maintenance при невозможности достижения консенсуса в системе, когда полученные планы противоречат планам и функционированию других систем.

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

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

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

В предлагаемом подходе будет реализовано взаимодействие мультиагентных систем, показывающее коэволюцию самоорганизующихся систем. Создание такого рода новых интеллектуальных систем для перехода к реальному времени при управлении ЖЦИ аэрокосмической промышленности, позволяющих работать в условиях неопределенности и высокой динамики изменений, когда ни динамика будущих отказов, ни условия обслуживания ЛА заранее не известны, когда необходимо согласование бизнес-процессов баз технического обслуживания, находящихся на расстоянии в тысячи километров и в разных часовых поясах, будет достигнуто впервые в мире, заместив устаревшие в этом отношении компоненты традиционных систем, ориентированных на классические «пакетные» формы обработки.

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

Ожидается, что результатом проводимых исследований и разработок станет создание целого ряда интеллектуальных систем управления ЖЦИ нового поколения, не имеющих аналогов в мире, обеспечивающих существенный рост в 15-40 % эффективности работы предприятий по управлению изделиями на всех этапах жизненного цикла.

Работа выполнена при финансовой поддержке Министерства науки и образования РФ.

1. Колчин А. Ф., Овсянников М. В., Стрекалов А. Ф., Сумароков С. В. Управление жизненным циклом продукции. — М.: Анахарсис, 2002. — 304 с.

2. Гореткина Е. В. Что такое PLM? // PCWeek. Russian Edition. 2003. № 34. http://www.pcweek.ru/in-dustrial/article/detail.php?ID=65311 (дата обращения: 01.12.2014).

3. Краснухин А. А. Team PDM. Система управления жизненным циклом, которую действительно можно внедрить // САПР и графика. 2001. № 7. http:// www.smarteam.ru/publications/article3/article3.htm (дата обращения: 05.12.2014).

4. Скобелев П. О. Интеллектуальные системы управления ресурсами в реальном времени: принципы разработки, опыт промышленных внедрений и перспективы развития // Приложение к теоретическому и прикладному научно-техническому журналу «Информационные технологии». 2013. № 1. С. 1-32.

5. Rzevski G., Skobelev P. Managing Complexity. — WIT Press, 2014. — 198 p.

6. Судов Е. В. Интегрированная информационная поддержка жизненного цикла машиностроительной продукции: Принципы. Технологии. Методы. Модели. — М.: МВМ, 2003. — 240 с.

7. Новая концепция создания интеллектуальных систем управления жизненным циклом на принципах сетецентрического управления, онтологий и мультиагентных технологий / В. И. Баклашов, В. А. Комаров, О. И. Лахин, Е. В. Полончук, П. О. Скобелев, В. Ф. Шпилевой // Изв. Самарского научного центра Российской академии наук. 2014. Т. 16. № 1(5). С. 1296-1298.

8. Абрамов Д. В., Андреев В. В., Симонова Е. В., Скобелев П. О. Разработка средств построения и использования онтологий для поддержки процессов принятия решений // Проблемы управления и моделирования в сложных системах: тр. VII Между-нар. конф., Самара, 27 июня-1 июля 2005 г. / СНЦ РАН. Самара, 2005. С. 435-440.

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

9. Мультиагентные технологии для разработки сете-центрических систем управления/ А. В. Иващен-ко, О. В. Карсаев, П. О. Скобелев, А. В. Царев, Р. М. Юсупов // Изв. ЮФУ. Технические науки. 2011. № 3. С. 11-23.

10. Виттих В. А., Скобелев П. О. Мультиагентные модели взаимодействия для построения сетей потребностей и возможностей в открытых системах // Автоматика и Телемеханика. 2003. № 1. С. 177-185.

11. Распределенные онтологии и их применение в решении задач интеграции данных/ В. А. Виттих, Д. В. Волхонцев, А. Н. Гинзбург, М. А. Караваев, П. О. Скобелев, О. Л. Сурнин, М. А. Шамашов // Проблемы управления и моделирования в сложных системах: тр. VIII Междунар. конф., Самара, 24-28 июня 2006 г. / СНЦ РАН. Самара, 2006. С. 451-459.

Complexity Theory and Challenges of Aerospace Products Lifecycle Management

Lakhin O. I.a, Project Manager, lakhin@yandex.ru Polnikov A. S.b, Analyst, polnikov@smartsolutions-123.ru

Simonova E. V.a> b, PhD, Associate Professor, Leading Analyst, simonova@smartsolutions-123.ru Skobelev P. O.a> b, Dr. Sc., Tech., Professor, Chief Executive Officer, petr.skobelev@gmail.com aSoftware Engineering Company «Smart Solutions», 17, Moscovskoe St., 443013, Samara, Russian Federation bSamara State Aerospace University, 34, Moskovskoe St., 443086, Samara, Russian Federation

Purpose: All the existing product lifecycle management systems use different techniques and their knowledge is poorly structured. For that reason, newly introduced systems are used only partially and often just at the early stages of the product lifecycle. A novel network-centric approach to complex aerospace product lifecycle management is discussed in this article. Methods: An intelligent network-centric system Smart PLM (which is a superstructure over the traditional PLM systems) is proposed. Smart PLM consists of interconnected systems of control over separate lifecycle stages in which all the occurring problems are solved locally whenever possible and globally otherwise. Results: A network-centric architecture concept was developed for control over traditional systems of product lifecycle management. Benefits of the proposed approach were shown on the example of complex aerospace products. The basic components of Smart PLM were described along with their interaction mechanism. The decision was justified to use ontologies for the domain area description and multi-agent approach for building up a demand-resource network for the scheduling of all stages of the product lifecycle. Logical architecture of a distributed multi-agent system was designed. The developed models, methods and algorithms of decision-making support in separate system components help to provide an appropriate response to any events which occur through all the stages of the aerospace products lifecycle. Practical relevance: The developed system architecture can be applied either autonomously or through the integration in a single complex with the existing PLM systems. The proposed adaptive approach to the lifecycle management of aerospace products will help to increase their reliability and reduce the operating costs through timely interaction and considering the requirements of all the participants at various lifecycle stages.

Keywords — Product Lifecycle, Lifecycle Management, PLM-System, Decision-Making Support, Adaptive Management, Network-Centric Architecture, Multi-Agent Technology, Strategic Scheduling, Domain Ontology, Cyber-Physical Model.

1. Kolchin A. F., Ovsiannikov M. V., Strekalov A. F., Suma-rokov S. V. Upravlenie zhiznennym tsiklomproduktsii [Management of the Product Lifecycle]. Moscow, Anakharsis Publ., 2002. 304 p. (In Russian).

2. Goretkina E. V. Chto takoe PLM? [What is PLM?]. PCWeek. Russian Edition, 2003, no. 34(400). Available at: http://

www.pcweek.ru/industrial/article/detail.php7ID-65311 (accessed 1 December 2014).

3. Krasnukhin A. A. Team PDM. Sistema upravleniia zhiznennym tsiklom, kotoruiu deistvitel’no mozhno vne-drit’ [Team PDM. Lifecycle Management System, Which Can Be Really Integrated]. SAPR i grafika, 2001, no. 7.

Available at: http://www.smarteam.ru/publications/article3/ article3.htm (accessed 5 December 2014) (In Russian).

4. Skobelev P. O. Intelligent Systems for Real Time Resource Management: Principles, Experience and Perspectives. Prilozhenie k teoreticheskomu i prikladnomu nauchno-tekh-nicheskomu zhurnalu «Informacionnye Tehnologii», 2013, no. 1, pp. 1-32 (In Russian).

5. Rzevski G., Skobelev P. Managing Complexity. WIT Press, 2014. 198 p.

6. Sudov E. V. Integrirovannaia informatsionnaiapodderzhka zhiznennogo tsikla mashinostroitel’noi produktsii: Print-sipy. Tekhnologii. Metody. Modeli [Integrated Information Lifecycle Support of Engineering Products: Principles. Technology. Methods. Models]. Moscow, MVM Publ., 2003. 240 p. (In Russian).

7. Baklashov V. I., Komarov V. A., Lakhin O. I., Polonchuk E. V., Skobelev P. O., Shpilevoy V. F. The New Concept of Creation the Life Cycle Intellectual Control Systems on the Principles of Network-Centric Management, Ontologies and MultiAgent Technologies. Izvestiia Samarskogo nauchnogo tsen-tra Rossiiskoi akademii nauk, 2014, vol. 16, no. 1(5), pp. 1296-1298 (In Russian).

8. Abramov D. V., Andreev V. V., Simonova E. V., Skobelev P. O. Razrabotka sredstv postroeniia i ispol’zovaniia ontologii

dlia podderzhki protsessov priniatiia reshenii [Development of Tools for Ontologies Design and Application for Decision-Making Processes Support]. Trudy VII Mezhdunarodnoi konferentsii «Problemy upravleniia i modelirovaniia v slozh-nykh sistemakh» [Proc. VII Intern. Conf. «Problems of Control and Modeling in Complex Systems»]. Samara, 2005, pp. 435-440 (In Russian).

9. Ivaschenko A. V., Karsaev O. V., Skobelev P. O., Tzarev A. V., Usupov R. M. Multi Agent Technology for Development of Network-Centric Control Systems. Izvestiya IuFU. Tekh-nicheskie nauki, 2011, no. 3(116), pp. 11-23 (In Russian).

10. Vittikh V. A., Skobelev P. O. Multi-Agent Interaction Models for Constructing the Needs-and-Means Networks in Open Systems. Avtomatika i Telemekhanika, 2003, no. 1, pp. 177-185 (In Russian).

11. Vittikh V. A., Volkhontsev D. V., Ginzburg A. N., Kara-vaev M. A., Skobelev P. O., Surnin O. L., Shamashov M. A. Raspredelennye ontologii i ikh primenenie v reshenii zadach integratsii dannykh [Distributed Ontologies and their Application to Data Integration Problems Solving]. Trudy VIII Mezhdunarodnoi konferentsii «Problemy upravleniia i modelirovaniia v slozhnykh sistemakh» [Proc. VIII Intern. Conf. «Problems of Control and Modeling in Complex Systems»]. Samara, 2006, pp. 451-459 (In Russian).

Научная электронная библиотека (НЭБ) продолжает работу по реализации проекта SCIENCE INDEX. После того как Вы зарегистрируетесь на сайте НЭБ (http://elibrary.ru/ defaultx.asp), будет создана Ваша личная страничка, содержание которой составят не только Ваши персональные данные, но и перечень всех Ваших печатных трудов, имеющихся в базе данных НЭБ, включая диссертации, патенты и тезисы к конференциям, а также сравнительные индексы цитирования: РИНЦ (Российский индекс научного цитирования), h (индекс Хирша) от Web of Science и h от Scopus. После создания базового варианта Вашей персональной страницы Вы получите код доступа, который позволит Вам редактировать информацию, помогая создавать максимально объективную картину Вашей научной активности и цитирования Ваших трудов.

12 У ИHФOPMAЦИOHHO-УПPABЛЯЮЩИЕ СИСТЕMЫ

Что такого в IT, что с ним все носятся. И когда всё это закончится

Изначально хотел назвать статью «Почему у айтишников большие зарплаты и когда это закончится». Статья создана по мотивам внутренних митапов и докладов.

Привет! Меня зовут Игорь Симдянов, я работаю архитектором решений в Нетологии, пишу книги, читаю курсы. Часто студенты, коллеги, знакомые задают вопрос о том, куда будет развиваться IT, не закончится ли оно завтра. Есть модные темы, которые не успев начаться сразу заканчиваются. IT у нас работает с прошлого столетия. Видимо, есть какой-то источник, который подпитывает интерес, может ли он исчерпаться и когда? Попробуем найти топливо IT, промоделировать развитие индустрии и предсказать признаки, по которым можно будет определить, что отрасль движется к стабилизации или деградации.

Иными словами, попробуем заглянуть в будущее. Однако для этого надо слегка откатиться назад, чтобы посмотреть, как IT-отрасль развивалась. Тогда будет проще оценить, что нас ждёт впереди.

Да, нам нужно IT

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

Некоторые из наших инструментов трудно охватить взглядом или осмыслить, они больше напоминают стихию или предмет изучения: интернет, СМИ, транспортная система. Их даже трудно назвать инструментами, скорее — это отражение нашей деятельности. Для простоты всё, что делают люди своими руками, мы будем называть инструментом, имея в виду, что они нас ускоряют, делают нашу жизнь проще и комфортнее.

Зачем же нам нужны инструменты? С одной стороны, они помогают решать возникающие проблемы, с другой — повышают уровень жизни. Мы получаем удовольствие от создания инструментов. Я бы сказал, это один из наших инстинктов.

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

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

Стивен Пинкер в своей книге «Язык как инстинкт» развивает идеи Ноама Хомского, что язык является инстинктом нашего вида. Люди за два поколения формируют язык — это зашито в мозге. Идея tabula rasa (чистая доска) не работает: мы не изобретали тысячелетиями наши языки, просто по факту рождения мы можем пользоваться языковыми структурами почти в готовом виде. Первые три года у человека включается «программа» на адаптацию к текущему языковому окружению. Многообразие языков обусловлено как раз тем, что люди не могут контролировать язык. Он постоянно изменяется, но это не является проблемой для вновь рождающихся, так как правила использования языков, программа развития у всех людей одна и та же. Главная особенность нашего вида: мы извлекли эволюцию из ДНК, так как научились кодировать и передавать информацию и передавать её не генетически, а в виде символов. Мы разговариваем на языках, делаем инструменты не потому, что нас к этому подталкивают обстоятельства, а потому что мы не можем этого не делать. Как перелетные птицы не могут не лететь осенью на юг, а весной — на север.

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

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

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

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

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

Почему заработные платы у них выше, чем у других инженеров? Проектировать суда или электроподстанции не проще, чем создавать веб-формы и обслуживать CRUD-запросы. За IT-кадры идёт конкуренция, их не хватает. А как так получилось, что за 70 лет не было подготовлено нужного количества разработчиков? Для проектирования подстанций инженеров хватает, а куда деваются разработчики? Маловероятно, что в определённый период жизни им резко перестают быть нужны деньги, которые бизнес вливает в IT-сферу многие десятилетия. Как долго может продлиться такой период и что будет служить признаками перехода IT-отрасли в обычную не разогретую инженерную специальность? Попробуем ответить на эти вопросы ниже.

Топливо для IT

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

Мне кажется, что топливом, при помощи которого движется IT-отрасль, долгое время был закон Мура. Гордон Мур, основатель компании Intel, в 1970-х годах сформулировал эмпирическое правило. Оно гласит, что каждые 18 месяцев количество транзисторов в интегральных схемах удваивается. Обычно его отображают в логарифмической форме:

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

С 70-х годов прошлого столетия в IT-отрасли наблюдается экспоненциальный рост. Именно так происходит взрыв. Следствием этого является взрывообразное развитие всей компьютерной отрасли. Только мы какую-то технологию начинаем отрабатывать, совершенствоваться в ней, у нас появляются более мощные компьютеры, процессоры, видеокарты, и нам нужно переключаться на другую технологию — использовать подход, учитывающий возросшие возможности. Начинаем разрабатывать новую технологию, происходит что-то ещё: компьютеры объединяются в сети, появляется интернет, образуется новая отрасль. Выясняется, что интернетом пользуется множество людей, туда проваливаются целые страны. И вот у нас уже большие данные, с ними надо что-то делать, появляется ещё одна отрасль по их обработке. Не справляемся с большими данными — нужно подключать какие-то математические модели, нейросети, и вот у нас уже формируется направление искусственного интеллекта.

Здесь я прямыми линиями нарисовал оптимистичную картину, как люди развивают отдельно взятую технологию (ассемблер, язык высокого уровня, базу данных).

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

Это приводит к тому, что концепции в языках программирования меняются скачками, примерно как у Томаса Куна в его «Структуре научных революций». Только здесь не нужно ждать, когда вымрут поколения учёных, действующих в старой парадигме. Здесь «умирает», точнее, устаревает железо. Для программирования нового железа приходит молодое поколение разработчиков с альтернативным подходом, часто с другими языками программирования и инструментами.

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

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

Вехи в IT

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

Вернёмся в середину прошлого века и посмотрим, как работали программисты. Вам вручают процессор, в котором все команды пронумерованы. Комбинация номеров команды и адресов — это программирование в кодах. Фактически такая программа — это готовый исполняемый файл, который процессор может исполнять напрямую. Например, 44-я команда складывает, а 23-я вычитает. Ячейки памяти тоже пронумерованы. Вот вы начинаете их комбинировать, и у вас получается длинная цепочка из цифр.

cffa edfe 0700 0001 0300 0080 0200 0000 0f00 0000 5007 0000 8500 0000 0000 0000 1900 0000 4800 0000 5f5f 5041 4745 5a45 524f 0000 0000 0000 0000 0000 0000 0000 0000 0000 0100 0000 0000 0000 0000 000

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

setcom proc far push ds push es mov ax,cs mov ds,ax mov es,ax pop ax

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

Все усилия и работа над программами идёт за счёт бизнеса, который извлекает прибыль. Задача коммерции считать деньги и оптимизировать расходы. Первый вопрос, который возникает у бизнеса: «Почему мы каждый раз переписываем программы? Давайте сделаем возможность переносить их с одного компьютера на другой».

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

#include int main()

Можно писать операционные системы, игры, офис, и эти программы начинают жить годами. Они растут в объёмах, в них становится трудно разбираться, и следующим этапом становятся специализированные языки. Последние оперируют не компьютерными терминами, а сущностями предметной области. Вместо адресов, указателей и файлов, вы можете оперировать учётной ставкой, налогом, счётом, сотрудником. Составлять программы на языке предметной области гораздо удобнее.

Список = Новый СписокЗначений(); Список.Добавить("ВвестиСчетФактуру", "Счет-фактура");

Здесь ↑ я в качестве примера привёл кусочек 1С. Идея такая: зачем мы вообще говорим на языке компьютера, используем файлы, переменные, сокеты? Это сложно. Давайте создадим язык, где сразу будут счета-фактуры, пользователи, заработные платы — так проще выражать свою бизнес-идею. Там будет меньше ошибок, нам потребуется меньше программистов.

Разработать специализированный язык — это очень дорого. На это требуется несколько лет. Более того, необходимо создать сообщество вокруг языка, чтобы был кадровый резерв, энтузиасты, которые будут обучать языку других разработчиков. Собственный язык вообще для всех видов деятельности — это нереальная задача.

Поэтому следующим этапом стало создание объектно-ориентированных языков программирования. Когда вы сначала строите язык предметной области, а затем используете его для решения прикладной задачи. Например, в случае игры: сначала создаём объекты игрового мира, а потом собираем из них саму игру.

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

В конце 1980-х — начале 1990-х годов было создано много языков. Сейчас живых языков программирования на порядок меньше. Всё это благодаря объектно-ориентированным языкам. Мы можем изучить Python или С++, а написать на них всё что угодно.

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

А что произойдёт, если закон Мура остановится? Кто-то говорит, что он уже остановился. Кто-то считает, что этого ещё не произошло. Почему возникла проблема остановки закона Мура, и есть ли она вообще? Давайте попробуем разобраться.

Остановка закона Мура

Допустим, что закон Мура прекратил работать. У IT-отрасли не было десятков и сотен лет, как у других инженерных специальностей, на то, чтобы отточить компьютерные технологии, сделать их совершенными. Развитие IT вызвано не подъёмом человеческого сознания, а взрывообразным ростом микроэлектронной промышленности: массовостью, миниатюризацией, снижением цены. Человеческое сознание со скрипом успевает перестраиваться. Приходится отказываться от старых достижений, так и не доведя их до совершенства.

IT-отрасль — это такой слоёный пирог из плохо пропечённых слоёв. Над каждым из слоёв ещё работать и работать.

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

Если закон Мура останавливается, IT-отрасль продолжает развиваться по инерции. Да, нет топлива для движения вверх по экспоненте. Но есть набранная скорость и инерция отрасли. Скорее всего, мы выходим на S-образную кривую, а в конце неё — на плато.

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

Ответа на этот вопрос пока нет. Это примерно как с биржевыми графиками: просматривая исторические котировки, очень легко понять, где минимумы и максимумы, где нужно было покупать, а где продавать. В реальности у вас есть лишь начало графика и неизвестное будущее, предсказать которое непросто. По некоторым данным, перелом произошёл уже в 2010 году, по другим — произойдёт в ближайшее время. Главный вопрос: что нас ждёт там, в будущем, когда мы начнём выходить на плато S-образной кривой?

Почему закон Мура должен остановиться

Распространённая шутка: количество предсказателей остановки закона Мура удваивается каждые 18 месяцев. На чём же эта армия предсказателей основывает свои выводы? Если посмотреть на микросхемы под увеличением, можно увидеть что-то похожее на картинке ниже.

На увеличенной картинке видны слои проводника, а пустое пространство занято диэлектриком.

Толщина стенки диэлектрика в наших микросхемах достигает 5 нм, это 50 ангстрем. Обещают 3 или 2 нм, то есть 20–30 ангстрем. Для сравнения длина молекулы воды — 1.5 ангстрема. Если мы станем уменьшать стенку диэлектрика, у нас начнутся квантовые туннельные эффекты. Электроны будут бегать там, где им не положено. Это не значит, что нельзя строить процессоры на туннельных эффектах, но свежих идей для реализации в ближайшие 18 месяцев не видно.

Более того, нам стало очень трудно делать даже современные процессоры. Медь, которая используется в качестве проводника, начинает диффундировать через стенку диэлектрика. Появляется брак.

Литография даёт в лучшем случае разрешение в 150 нм. А нужно 3 или 2 нм.

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

Видимый свет начинается с 380 нанометров. Если мы используем ультрафиолет, то предел это — 100 нанометров. Для рентгена и гамма-излучения уже вряд ли получится подобрать материал шаблона. Да, и работать с ними непросто. Дополнительная неприятность заключается в том, что свет — это волна, — после мелкого рисунка он ещё интерферирует на полуволну. То есть в реальности типоразмеры, которых можно добиться при помощи такой длины волны, ещё меньше. А нам нужно разрешение в 3 или даже 2 нанометра.

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

В современном технологическом процессе чудовищное количество брака. Выход составляет только 5%. Например, когда вы покупаете процессор с 4 ядрами, в нём может быть 16 ядер, просто 12 из них бракованные и отключены.

Предельные типоразмеры создаются при помощи пучка электронов.

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

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

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

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

Что дальше: можем ли мы предсказать, как изменится IT

Конечно, мы далеко ещё не исчерпали возможности текущих технологий. Нельзя увеличивать частоту (скорость) процессора за счёт уменьшения стенки диэлектрика? Можно рядом на кристалле расположить несколько ядер. Ядра слишком большие и много не разместить? Можно их упростить (RISC), специализировать, как в случае видеокарт, на которых уже размещаются тысячи ядер.

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

Можно попробовать предсказать, как мы будем жить в мире после остановки закона Мура, опираясь на инженерные области, которые точно так же взлетали: пар, электричество, самолётостроение, космос, строительство. Большинство из них вышли на плато и продолжают размеренно развиваться, часть — вышли на пик или даже деградировали (пар, отчасти космос).

Понять, выходим мы на плато или действуем в рамках закона Мура, можно по ряду признаков.

Навёрстывание разрыва между аппаратной и программной частями

После окончания действия закона Мура нас ещё ждёт период сокращения между аппаратной и программной частью. Если сейчас написать на ассемблере обычный калькулятор для Windows, его размер можно довести до 14 Кб (я пробовал). Да, конечно, он будет не таким красивым, а графика будет потреблять память, плюс мы опираемся на библиотеки Windows. Но калькулятор сейчас занимает 280–500Кб. Это в 20–40 раз больше, чем мог бы. Причём калькулятор Windows это небольшая, оптимизированная программа.

Повальное увлечение пакетами и пакетными менеджерами приводит к гигантскому объёму всего программного обеспечения. Подобные примеры может привести любой разработчик: множество npm-пакетов, зачастую выполняющих дублирующие функции в проекте и приносящих зависимости, проекты на Ruby on Rails, которым тесно в 2 Гб памяти, даже если выводят лендинг.

У нас есть куда оптимизировать программное обеспечение: «допекать» слои пирога, на подготовку которых не было времени во времена работы закона Мура. Такая ситуация сложилась, потому что время разработчика стоит дороже, чем память. Мы очень долго разменивали память и процессор на скорость разработки.

Если вы замечаете, что на работе требуется всё больше и больше математики или алгоритмов, если вы задумываетесь о том, чтобы не нарастить, а сократить количество серверов, — возможно, это один из признаков остановки закона Мура.

Типовые проекты

Если посмотреть на соседние инженерные специальности, нас с высокой долей вероятности ждут типовые проекты, когда со школьной скамьи вам говорят, какие базы данных использовать, как программировать, вот готовые библиотеки. Это уже есть, но не в таком виде. Например, мы в Нетологии можем прийти и сказать: «Так, нам нужна MongoDB, давайте попробуем. Ну, не получилось, уберём». В случае типовых проектов этого сделать будет уже нельзя, чуть ли не на законодательном уровне, на уровне министерства будет прописано: мы в отрасли используем такую-то базу данных, ничего больше. То есть нас ждут не просто известные алгоритмы или паттерны, а прямо сертифицированные базы данных, сервера, программное обеспечение, без использования которых продать программу будет невозможно.

Падение заработных плат

Так как не будет креативности, не будет этой огромной маржи, которую даёт экспонента, то и заработные платы будут падать. А с чего они будут большими, если и бизнес мало зарабатывает?

Выравнивание гендерного состава

Несмотря на то что первым программистом считается Ада Лавлейс, в честь которой назван язык программирования «Ада», в IT-отрасли до недавнего времени был большой перекос в мужскую сторону.

Дело в том, что природа экспериментирует на мужских особях. Считается, что даже отклонения в генотипе мужчин происходят чаще, чем в генотипе женщин. Женщин нужно беречь — им вынашивать потомство, а мужчины идут убивать мамонта — их затопчут или они друг друга по дороге перебьют. Вот на последних и поэкспериментируем.

В результате эволюционно сложилось, что мужчины более склонны к риску, а девушки — к систематизации, более аккуратны и осторожны. Даже статистика вложения денег говорит, что мужчины склонны к более рискованным вложениям (акции), чем девушки (облигации, депозиты).

То есть мужское население чаще склонно к авантюрным областям, чем женское. Скорее всего, этим и объясняется малое количество девушек в IT в период действия закона Мура: когда полученные навыки и знания обнулялись слишком быстро, а правила игры менялись слишком часто.

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

Точки роста

Что будет, если у нас всё-таки закон Мура остановится, и мы выйдем на S-образную кривую? Жизнь не прекратится, деньги никуда не денутся, бизнес будет по-прежнему креативен и искать точки приложения. Например, такие как:

космос;
термоядерная энергетика;
биотехнологии;
квантовые компьютеры.

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

Космос

Космос долго рассматривался, как источник бесконечной экспансии человечества, в том числе экономического роста и расширения. На космическую гонку выделялись гигантские бюджеты, привлекались лучшие кадры. Ровно до того момента, пока не выяснилось, что Солнечная система состоит из того же, из чего состоит Земля. Нет экономической выгоды от полётов в космос.

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

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

Потенциально надежда на космос, как на источник очередного инженерного взрыва остаётся. С позиции человека — это почти бесконечные пространства и ресурсы. Однако «бесконечные» расстояния не дают воспользоваться результатами вложений в течение жизни. Последнее не даёт вовлечь в космическую экономику много людей. Если в IT-отрасли мы говорим про S-образную кривую с выходом на плато, то в космосе можно говорить, что наблюдается даже некоторый регресс.

Термоядерная энергетика

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

Источником энергии в атомной и ядерной энергетике служит преобразование вещества в энергию по знаменитой формуле Эйнштейна:

При прочих равных условиях насколько у вас уменьшится масса исходного топлива, столько энергии вам удастся извлечь из этого процесса. Скорость света — очень большая величина, поэтому уничтожение даже небольшого объёма вещества приводит к высвобождению большого количества энергии.

В настоящий момент в атомных электростанциях мы сжигаем уран 235 U. Содержание этого изотопа в природном уране — 0.7%, остальное составляет 238 U, из которого за ненадобностью делают броню танков и сердечники снарядов. Изотопа 235 U на рынке не хватает, в том числе поэтому количество новых атомных электростанций не велико — на всех правильного урана не хватит. Немного спасает ситуацию наработка плутония в ходе распада 235 U. Его можно использовать не только для создания ядерного оружия, но и как топливо в атомных электростанциях.

Переход на реакторы на быстрых нейтронах позволит задействовать всю массу природного урана, в том числе накопленного за предыдущие годы. Этот проект называется «замкнутым ядерным топливным циклом» и в настоящий момент реализуется только в Российской Федерации. Все остальные страны заморозили развитие реакторов на быстрых нейтронах. В немалой степени из-за катастроф на атомных электростанциях и сложности устранения последствий. Реакторы на быстрых нейтронах предполагают гораздо более высокую температуру в реакторе, и обычная вода в первом контуре охлаждения не подходит. До недавнего времени в них использовался сплав калия и натрия в качестве охладителя. Учитывая, что они активно взаимодействуют с водой, авария на таком объекте скорее закончится грандиозным взрывом. Поэтому в качестве теплоносителя планируется использовать свинец.

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

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

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

Биотехнологии

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

КПД биопроцессов достигает 80–100%, в то время как наши двигатели внутреннего сгорания достигают всего лишь 40%. Нам ещё очень далеко до реакций, которые протекают со 100% селективностью. Ферментативным катализом мы можем только пользоваться, создавать катализаторы такого класса нам пока не под силу.

Про то, как бы мог выглядеть мир с биотехнологиями, рассказывает каждый первый фантаст: Станислав Лем, Гарри Гаррисон, Уильям Гибсон, Сергей Лукьяненко. Список можно продолжать бесконечно. Тема биотехнологий часто поднимается в компьютерных играх: Fallout, Deus Ex, Cyberpunk 2077. Уверен, что и тут полный список тоже очень внушителен. Почти ни у кого не возникает сомнений в огромном потенциале технологий, развивающихся в течение времени, которого у человечества нет. В случае успеха здесь аналог закона Мура мог бы действовать гораздо дольше. Человечество вышло бы на новый уровень жизни, экономики, появились бы новые профессии и развлечения.

Квантовые компьютеры

В последнее время много разговоров о квантовых компьютерах. Фактически это аналоговый компьютер, позволяющий моделировать квантовые процессы. Когда заходит речь о квантовых компьютерах, часто упоминается криптография, так как квантовые алгоритмы позволяют понизить криптостойкость существующих алгоритмов шифрования. Однако создавались они совершенно не для этих задач.

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

В квантовой механике мы можем аналитически решить задачи для систем с одной частицей. В случае нескольких частиц уравнение Шрёдингера решается только численно, приближённо. Это не проблема, когда частиц мало: например, при обсчёте первых трёх периодов периодической таблицы без учёта релятивистских эффектов и того, что ядра атомов ведут себя как квантовые объекты. Точность вычислений страдает, но более или менее бьётся с экспериментальными данными. Если мы спускаемся ниже по таблице Менделеева, атомы элементов обрастают «шубой» электронов. Наши приближённые модели рассыпаются. В сложной молекуле не просто много электронов, они ещё обобщены. В металле та же история. Кроме того, в реальности у нас не один-два атома, а порядка 10 23 .

Моделирование систем с множеством квантовых частиц превращается в неподъёмную задачу. У нас нет подходящей модели и математики. Ищем их около 100 лет и фундаментально сдвинуться не можем. Эта задача нужна в том числе для прорыва в квантовой электродинамике для проектирования микросхем субнанометрового уровня.

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

Сам долго отказывался рассматривать квантовые компьютеры как компьютеры — для меня это физический прибор вроде ЯМР-спектрометра. Но всё-таки это программируемая машина, а значит — компьютер. Мне кажется, что их потенциал огромен, как у массового внедрения электричества или первой интегральной микросхемы.

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

Вывод

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

Высокие зарплаты в IT, приятные образованные коллеги, внимание всего мира — это не бесконечный Клондайк. Так получилось, что мы сейчас находимся около точки максимальной скорости «компьютерного взрыва». Топливо этого взрыва работало с середины прошлого века и с довольно высокой вероятностью закончилось в 2010 году. Плюс-минус ещё 30–60 лет IT-сфера будет расти и развиваться, потом выйдет на плато и станет обычной инженерной отраслью.

У тех, кто учится на айтишника, есть время состояться в профессии. Но уже не стоит бегать от математики — её в индустрии будет становиться всё больше и больше. В любом случае рядом есть ещё более удивительные и мощные инженерные задачи и отрасли. Когда проснутся эти спящие вулканы? Неизвестно.

закон мура
искусственный интеллект
it-компании
программисты
разработчики
будущее
квантовый компьютер
биотехнологии
космос
термоядерный синтез

Блог компании Нетология
Визуализация данных
Исследования и прогнозы в IT
Производство и разработка электроники
Искусственный интеллект

§ 46. Что такое ООП?

Как вы знаете, работа первых компьютеров сводилась к вычислениям по заданным формулам различной сложности. Число переменных и массивов в программе было невелико, так что программист мог легко удерживать в памяти все взаимосвязи между ними и детали алгоритма.

С каждым годом производительность компьютеров росла, и человек «поручал» им всё более и более трудоёмкие задачи. Компьютеры следующих поколений стали использоваться для создания сложных информационных систем (например, банковских) и моделирования процессов, происходящих в реальном мире. Новые задачи требовали более сложных алгоритмов, объём программ вырос до сотен тысяч и даже миллионов строк, число переменных и массивов измерялось в тысячах.

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

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

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

В конце 60-х годов XX века появилась новая идея — применить в разработке программ тот подход, который использует человек в повседневной жизни. Люди воспринимают мир как множество объектов — предметов, животных, людей — это отмечал ещё в XVII веке французский математик и философ Рене Декарт. Все объекты имеют внутреннее устройство и состояние, свойства (внешние характеристики) и поведение. Чтобы справиться со сложностью окружающего мира, люди часто не вникают в детали внутреннего устройства и игнорируют многие свойства объектов, ограничиваясь лишь теми, которые необходимы для решения их практических задач. Такой приём называется абстракцией.
Абстракция — это выделение существенных характеристик объекта, отличающих его от других объектов.

Для разных задач существенные свойства одного и того же объекта могут быть совершенно разными. Например, услышав слово «кошка», многие подумают о пушистом усатом животном, которое мурлыкает, когда его гладят. В то же время ветеринарный врач представляет скелет, ткани и внутренние органы кошки, которую ему нужно лечить. В каждом из этих случаев применение абстракции даёт свою модель одного и того же объекта, поскольку различны цели моделирования.

Как применить принцип абстракции в программировании? Поскольку формулировка задач, решаемых на компьютерах, всё более приближается к формулировкам реальных жизненных задач, возникла такая идея: представить программу в виде множества объектов (моделей), каждый из которых обладает своими свойствами и поведением, но его внутреннее устройство скрыто от других объектов. Тогда решение задачи сводится к моделированию взаимодействия этих объектов. Построенная таким образом модель задачи называется объектной. Здесь тоже идёт проектирование «сверху вниз», только не по алгоритмам (как в процедурном программировании), а по объектам. Если нарисовать схему такой декомпозиции, она будет представлять собой граф, так как каждый объект может обмениваться данными со всеми другими (рис. 7.2).

Здесь А, Б, В и Г — объекты «верхнего уровня»; Бг, Б2 и Б3 — под объекты объекта Б и т. д.

Для решения задачи «на верхнем уровне» достаточно определить, что делает тот или иной объект, не заботясь о том, как именно он это делает. Таким образом, для преодоления сложности мы используем абстракцию, т. е. сознательно отбрасываем второстепенные детали.

Если построена объектная модель задачи (выделены объекты и определены правила обмена данными между ними), можно поручить разработку каждого из объектов отдельному программисту (или группе), которые должны написать соответствующую часть программы, т. е. определить, как именно объект выполняет свои функции. При этом конкретному разработчику не обязательно держать в голове полную информацию обо всех объектах, нужно лишь строго соблюдать соглашения о способе обмена данными (интерфейсе) «своего» объекта с другими.

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

1. Почему со временем неизбежно изменяются методы программирования?

2. Что такое декомпозиция, зачем она применяется?

3. Что такое процедурное программирование? Какой вид декомпозиции в нём используется?

4. Какие проблемы в программировании привели к появлению ООП?

5. Как выполняется декомпозиция алгоритмов в процедурных языках программирования?

6. Что такое абстракция? Зачем она используется в обычной жизни?

7. Объясните, как связана абстракция с моделированием.

8. Какие преимущества даёт объектный подход в программировании?

9. Какой вид декомпозиции используется в ООП?

10. Что такое интерфейс? Приведите примеры объектов, у которых одинаковый интерфейс и разное устройство.

а) «Проблемы процедурного программирования»

б) «Глобальные переменные: за и против»

в) «ООП: достоинства и недостатки»

Почему со временем неизбежно изменяются методы программирования