Инженеры по всему миру ведут разработку в среде MATLAB, это их любимый инструмент. А может ли российская IT-индустрия предложить достойную альтернативу дорогому американскому софту?

С этим вопросом я пришла к Вячеславу Петухову, основателю компании 3В Сервис, которая производит отечественную среду моделирования и разработки SimInTech. После попытки продать свою разработку в Америке он вернулся в Россию и делает конкурента MATLAB здесь.

Поговорили о трудностях внедрения сложного IT-продукта на российский рынок, маркетинге на грани, принципах работы SimInTech и её преимуществах перед MATLAB.

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

Фаря:
На чём написана среда SimInTech?

Вячеслав Петухов:
Изначально и сейчас она написана на Паскале.

Серьёзно? Кто-то на нем еще пишет?

Да. Он спокойно себе развивается, Скайп был написан на Delphi. Когда мы начинали разработку это была чуть ли не первая среда, в которой можно было быстро набрать код, не заморачиваясь, и заняться сутью.

Если сравнивать с MATLAB, то какие библиотеки SimInTech, по твоему мнению, самые сильные сейчас, какие еще недоработанные, какие планируется доработать?

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

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

А что на счетавтоматической генерации кода? MATLAB этим очень кичится.

Это смешно. Матлабовская кодогенерация это просто смех. Если говорить про наш продукт, то теперь операторы АЭС открывают ноутбук на станции, открывают схему в SimIntech, подключают к стойке, которая управляет реактором, и правят эту схему. Программиста нет.

***

Мне кажется, это очень интересная история, что вы делаете свой сложный российский продукт, но почему у вас такой жесткий маркетинг? Почему в каждую дырку (отверстие) нужно обязательно вставлять MATLAB?

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

Вот одна из твоих цитат из ВКонтакте:

И при этом ты говоришь, что по отношению к SimInTech понятие импортозамещение употреблять не стоит. Хотя тут сам на это и намекаешь.

Здесь написано, что ВУЗ заплатил 25000000 . За что? Зачем ВУЗу на 25000000 покупать MATLAB?

А зачем ему SimInTech покупать?

SimInTech не надо покупать. Качай и учи. Передаточные функции, фазочастотный анализ, устойчивость. Это всё можно делать бесплатно. У нас можно качать демоверсию и в ней всё это делать.

И сколько эта демоверсия доступна?

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

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

Это понятно. Но моя задача тебе продать. Как еще я тебе продам, если ты пользуешься MATLAB? Ты позовёшь своих инженеров и скажешь им: Вот пришли ребята, хотят нам предложить аналог MATLAB. А у инженера в матлабе наработана библиотека и куча всего. Он откроет SimInTech и скажет: Ой, да у вас интерфейс не такой, да у вас линии неправильные рисуются и т.д.

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

Наш заказчик к нам придёт, потому что у него проблема с MATLAB. А те, у кого нет проблем с MATLAB, кого всё устраивает, в принципе, не наши заказчики. Они не придут. Мне нужно, чтобы все знали, что SimInTech это то же самое, что MATLAB, но лучше.

То есть ты за счёт MATLAB пиаришься?

Ну да.

***

А зачем ты приходил к конкурентам в Софтлайн (дистрибьюторы MATLAB)?

Я предлагал им гениальную бизнес-идею. Я знаю, что у них где-то порядка 50% прибыли уезжает в Америку. Давайте оставим эти 50% здесь и на эти деньги мы разработаем всё, что угодно.

Чем закончилась ваша встреча?

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

Очень амбициозно

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

Нужно ли России делать свою особую операционку и другое ПО?
Не спешите с выводами.

Изображение с сайтаcorchaosis.ru

В мире программного обеспечения важны:

• Понятность, знакомость интерфейса пользователю. Если пользователю требуется три часа на то чтобы освоить ваш продукт, а у пользователя зарплата в месяц 100 000 рублей, то это эквивалентно тому что пользователь заплатил за ваш продукт больше на 1785.71 рублей.

  Как посчитал: (100 000 (зарплата) / 21 (рабочих дней))*(3 (часа)/8 (часов в рабочем дне)) = 1785.71 рублей. Это если вы раздаёте бесплатно свой продукт. Если за плату, то плюс его цена.

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

• Кто разработчик и какова цена?

  - Плохо: Разработчик зарубежный, программа платная и дорогая. Примеры: Windows, MS Office, Photoshop, Oracle.

  - Лучше: Разработчик отечественный, программа дешёвая.

  - Хорошо: Проект опенсорсный (т.е. с публичным исходным кодом), программа бесплатная.

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

Что требуется сделать, чтобы в России было своё высококачественное ПО:

Берёте опенсорсные продукты (ОС, OpenOffice, PostgreSQL) и начинаете их улучшать силами программистов в России. [ Как требуется развивать PostgreSQL ] Максимально входим в каждый проект, подключаем самых квалифицированных профессионалов, цель - чтобы максимальную часть системы писали наши программисты, без права выезда из России. Если нас не пускают к ядру системы - анализируем, можем ли мы в своём отдельном продукте сделать лучше чем у них. Если да - создаём свою отдельную ветку продукта, если нет - создаём задачи для решения которых нужно знать ядро системы и сажаем программистов делать эти задачи, даже если они не особо актуальны.

Максимизируем совместимость. Я не понимаю почему Линукс не работает на Win32API. Свою третью систему команд - не линукс и не виндовс - точно делать не следует. Это же касается и процессоров Эльбрус - система команд должна быть общепринятой а не своей отдельной.

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

И никому не захочется переучиваться под не привычный экранный интерфейс. А это значит, российское законодательство надо модифицировать, явным образом прописав что копирование экранных интерфейсов компьютерных программ (кроме графики игр и мульмедийных систем) не запрещено. А затем на этой основе создавать специальные сборки OpenOffice с интерфейсом, идентичным программам от майкрософт. Создать операционку, которая будет выглядеть как MS Windows и иметь нативную, без wine, систему команд Win32API, можно наряду с линкувыми. Создать офисный пакет, который будет выглядеть и работать как MS Word, Excel, PowerPoint. Создать графический редактор, который будет выглядеть и работать как Adobe Photoshop. Желательно силами государства и в режиме опенсорс, максимально совместимо с примочками и драйверами других систем.

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

Всем привет! На связи Антон Баширов, разработчик из ИТ-кластера Ростелекома. Импортозамещение набирает обороты, а российский софт всё глубже проникает в нашу повседневную ИТ-шную сущность бытия. Процессоры Эльбрус и Байкал становятся более востребованными, комьюнити расширяется, но мысли о необходимости портировать весь наш любимый технологический стек на неизведанную архитектуру E2K звучат страшнее рассказов про горящий в пламени production-кластер.

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

Итак, гость в студии база данных Reindexer, разработка нашего ИТ-кластера.

Стоит сказать, почему выбор пал именно на Reindexer, а не другую БД. Во-первых, всеми любимый и известный Postgres уже есть в составе пакетов ОС Эльбрус. Переносить его нет необходимости. Во-вторых, наш гость уже прошел испытания на ARM, следовательно, пришло время ему покорить Эльбрус.

Стоит упомянуть, что Reindexer появился на свет как продуктвыбора между Elastic и Tarantool. Это определенно хочется попробовать завести на отечественном процессоре.

День 0. Знакомство с гостем

Несколько слов про нашего гостя:

Имя:NoSQL in-memory database Reindexer с функционалом полнотекстового поиска
Возраст:на момент испытаний версия БД была 3.1.2
Происхождение:Россия
Место рождения:пытливый ум разработчика Олега Герасимова@olegator99
Место жительства:https://github.com/Restream/reindexer
Место работы:Ростелеком
Строение:основная составляющая C++, имеются примеси из языка Ассемблера и немного CMake
Особенности:- Ассемблерные вставки;
- Много С++11 и C++14;
- Используются корутины.

Деятельность:- Хранение данных в памяти и на диске;
- Выполнение SQL запросов со скоростью 500K queries/sec для PK запросов;
- Выполнение запросов типа full-text search (почти как Elastic, только не тормозит);
- Работа в режиме server и embedded;
- Общение с крутыми парнями: Go, Java, Rust, .NET, Python, C/C++ и (да простит меня Хабр) PHP.

Заскучали? На этом нудная часть закончилась. В эфире рубрика Ээээксперименты!

День 1. А ты думал, в сказку попал?

Для начала попробуем нашего друга собрать из того, что есть.Идем на тестовый сервер Эльбрус 8C с ОС Эльбрус 6.0.1, клонируем туда репозиторий и запускаем CMake.

Хорошие новости, мы нашли компилятор! Новость действительно хорошая, ведь у Эльбруса свой компилятор LCC.

К счастью, создатели Эльбрус сделали LCC полностью совместимым с GCC и наши любимые нативные программки и сборщики смогут чувствовать себя хорошо без особых манипуляций. LCC уже сделал за вас нужные линки:gcc -> /opt/mcst/bin/lcc*.

Но вернемся к нашему гостю и тому, что не понравилось CMake.

В скриптах сборки, в CMakeLists.txt выполняется определение операционной системы и архитектуры процессора, на которой собирается Reindexer. Нужно это для того, чтобы подключать правильные исходники ассемблера, ведь как говорится Write once, run anywhere.

Разумеется, на момент написания скриптов никто не знал про процессоры Эльбрус, поэтому наш скрипт и упал. Исправляем.

Программисты люди ленивые, поэтому:

Попытка 2:

А что так можно было? На самом деле да для того, чтобы завелся CMake, этого было достаточно. Теперь ударим в бубен и запустимmake -j8:

Для тех, кто уже успел поработать с кроссплатформенным софтом, не новость, что С/С++ код с помощью макросов разделяют на платформозависимые секции.

Поэтому, в некоторые места кода Reindexer понадобилось добавить парочку новых условий для__E2K__и__LCC__:

После колдовства с макросами нас ждал монстр пострашнее:

Вот что бывает, когда игнорируешь messages у CMake.

Из-за того, что CMake не нашел подходящих исходников, компилятор не смог найти реализации двух функций:jump_fcontextиmake_fcontext. Про назначение этих функций я расскажу чуть позже, а пока что давайте успокоим нашего гостя и подсунем ему пару пустышек:

Этих операций оказалось достаточно, чтобы Reindexer собрался.

Поздравляю, у вас двойня!

Вот они, наши два долгожданных файла:

# file reindexer_serverreindexer_server: ELF 64-bit LSB executable, MCST Elbrus, version 1 (GNU/Linux

# file reindexer_toolreindexer_tool: ELF 64-bit LSB executable, MCST Elbrus, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux.so.2, for GNU/Linux 2.6.33, with debug_info, not stripped

Это можно считать успехом. Мы смогли собрать наш первый Эльбрус-бинарник. Даже два бинарника: reindexer_server и reindexer_tool.

Подведем итоги. Чтобы собрать Reindexer, мы:

• Поправили CMake-скрипты;

• Добавили несколько условий в макросы препроцессора;

• Заглушили ASM функции.

День 3. Наш Гость, попав на Эльбрус, начал подавать признаки жизни

Первый запуск прошел успешно - сервер поднялся, и даже открылся web-ui.

Я привык не останавливаться на достигнутом и решил немного поработать над Reindexer.

Результат меня порадовал - Гость устал и прилег отдохнуть:

Такое поведение наблюдалось только на Эльбрус. На i5 все работало штатно.

Давайте разбираться. Вооружившись отладчиком (gdb кстати под E2K работает прекрасно) и CLion, мне удалось докопаться до истины.

Пару запросов к Reindexer смогли воспроизвести ошибку:

Падает в деструкторе. Интересный момент - упало на free (в данном случае free реализуется через jemalloc). Видимо, здесь идет высвобождение памяти по некорректному указателю. Ошибку эту я исправлял в два этапа:

1. work around - дело в том, что QueryEntry лежит в объекте ExpressionTree, в самом классе примечательного я не нашел, поэтому копнул в сторону родителя. Оказалось, что до вызова деструктора был вызван вот такой копирующий конструктор, в котором есть интересный MakeDeepCopy(), реализованный с помощью библиотечкиmpark-variant.

   Подробнее про expression tree рассказываюттут.

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

   

   Итог - оно заработало.

2. TODO: Исправление тоже есть, но рассказ про него уже выходит за рамки данной статьи. Небольшой спойлер (код из mpark-variant с патчем под e2k):

inline constexpr DECLTYPE_AUTO visit(Visitor &&visitor, Vs &&... vs)#ifdef E2K //Fix for Elbrus    -> decltype(detail::visitation::variant::visit_value(lib::forward<Visitor>(visitor),                                                 lib::forward<Vs>(vs)...))    {     return detail::visitation::variant::visit_value(lib::forward<Visitor>(visitor),                                                 lib::forward<Vs>(vs)...);    }#else    DECLTYPE_AUTO_RETURN(        (detail::all(             lib::array<bool, sizeof...(Vs)>{{!vs.valueless_by_exception()...}})             ? (void)0             : throw_bad_variant_access()),        detail::visitation::variant::visit_value(lib::forward<Visitor>(visitor),                                                 lib::forward<Vs>(vs)...))#endif

День 5. Он ожил! Ну почти

Сервер у нас, действительно, работает, даже удалось получить первые результаты бенчмарков.

Но все это время я упорно игнорировал один компонент.

Помните, как мы убрали завязку на ASM и функцииmake_fcontext и jump_fcontext?

Так вот, ASM исходники в Reindexer нужны для реализации C++ корутин, а эти функции - ключевые для корутин из библиотеки boost/context.

Корутина это функция, которая может быть приостановлена и возобновлена в любой момент. Для реализации достаточно трех основных компонентов:
- функция
- механизм для ее паузы (suspend)
- механизм для возобновления ее с той точки, в которой была сделана пауза (resume).

Реализацию корутин можно увидеть в таких языках и библиотеках, как:

• Libcoro(корутины на C/С++)

• Koishi(тоже корутины, тоже на С/С++)

• Boost(и это тоже корутины, тоже на С/С++, корутин много не бывает!)

• Node-fibers(корутины для NodeJS на базе libcoro)

• Tarantool(fibers на базе libcoro)

• Kotlin(свои корутины, не на C++)

• C++20

• Goroutine

Для наглядности вот скрин теста корутин из Koishi:

Последовательность следующая:

1. Создали корутину, выделили стек, задали функцию;

2. Возобновили корутину - в этот момент вызвалась наша функция;

3. Приостановили корутину с помощьюkoishi_yield здесь мы вернули управление в test1 сразу после строчкиkoishi_resume;

4. Если мы еще раз сделаемkoishi_resumeна нашей корутине мы вернемся на строчку функции cofunc1 сразу после первого вызоваkoishi_yield.

Без корутин не будет работать reindexer_tool, но не можем же мы оставить Reindexer без такой важной конечности. Будем исправлять.

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

Есть несколько вариантов реализовать корутины:

• Вариант 1:написать ASM реализацию. Самый очевидный, но при этом самый сложный вариант. У нас есть в планах попробовать именно этот вариант, так как ASM корутины - самые быстрые.

• Вариант 2: забить. Нет, это не наш путь.

• Вариант 3: использовать библиотеку.

По счастливой случайности Koishi оказалось той самой библиотекой, поддерживающей реализацию корутин с помощью встроенных E2K функций:makecontext_e2k()иfreecontext_e2k().

Там, где стандартная медицина бессильна, в дело вступает генная инженерия.

Для начала внедрим Koishi в организм Reindexer:

Заменим больной орган на здоровый:

Стараемся не повредить то, что уже работает:

Одним из backend-ов Koishi для корутин выступает fcontext (те же самые boost исходники, что в Reindexer). Последуем древней мудрости работает не трогай! и оставим как есть в случае, если у нас не E2K архитектура. Для Эльбруса мы будем использоватьucontext_e2k.c

И вот он, наш мутант с корутинами полностью здоров и функционален (и на amd64, и на E2K):

День 11. Проводим финальные испытания

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

Всего в Reindexer около 300 функциональных тестов, и мне не терпится запустить их все.

Тесты бежали, бежали и не добежали. Один из тестов вызвал Segmentation Fault.

Всему виной оказались вот эти строчки:

struct ConnectOpts {  /* тут тоже код, но он не такой интересный */  uint16_t options = 0;  int expectedClusterID = -1;};

Обычный код, что тут такого? скажете вы. Но не все так просто. Запоминаем, что здесь два поля, которые инициализируются при объявлении.

Попробуем воспроизвести на изолированном более простом примере.

ASM, настало твое время

Внимание на скриншот:

Ошибка проявляется именно в том случае, когда отсутствуют не проинициализированные поля. Другими словами, если все ваши поля инициализируются при объявлении вы счастливчик, поймавший Segmentation Fault.

Баг заключается в том, что скомпилированное создание структуры выглядит как странныйaddd. Именно эта строчка и вызывает segfault. Кстати, если вместоbool anyField = falseнаписать простоbool anyField, то код совершенно другой и ошибки нет.

Семь бед, один ответ обновитесь!

Разгадка тайны оказалась проста. На момент работы с Reindexer последней версией компилятора LCC была v.1.25.16, однако в состав пакетов ОС Эльбрус по умолчанию входит 1.25.14, на котором я и запускал тесты. Добрые люди из сообщества подсказали нам, что уже в 15 версии данный баг был исправлен. Я решил обновиться на 16-ую и посмотреть, что будет.

Вот что нам принес новый компилятор LCC v.1.25.16:

C++ код такой же, однако ASM совсем другой, и что самое главное он работает! Последовательно (заранее прошу прощения за мой ломаный asm-русский переводчик):

1. gestp - выделяем стек и кладем его в %dr3

2. setwd - задаем текущее окно в регистровом файле

3. setbn - задаем подвижную базу регистров в текущем окне регистрового файла

4. addd - кладем "дно" стека (стек размером 0x20) в %dr2

5. addd - выделяем на стеке нашу структуру

6. ldb - достаем из констант наш false и кладем его в %r5

7. stb - кладем наш false из регистра %r5 в наше поле anyField1

8. addd - подготовили локальный указатель на структуру для вызова метода

9. addd - передаем указатель в базовый регистр для передачи при вызове anyMethod (в anyMethod мы достаем указатель из регистра %dr0)

10. disp - подготавливаем регистр перехода на anyMethod

11. call - вызываем anyMethod

Дальше все просто пересобрать, перезапустить, обрадоваться.

Тесты прошли успешно, и теперь у нас есть полностью рабочий и протестированный Reindexer на Эльбрусе.

На этом все ?

На самом деле нет. Сейчас мы смогли:

• собрать Reindexer Server

• запустить Reindexer Server

• собрать Reindexer Tool

• запустить Reindexer Tool

• переписать кусочек Reindexer Tool

• уронить Reindexer и поднять его

• добиться 100% проходимости Reindexer тестов

Мы научились:

• собирать C++ софт на Эльбрус

• переписывать C++ софт под особенности и отличия Эльбрусов

• разбираться в ASM E2K

• превозмогать трудности

• разбираться в C++ корутинах даже на Эльбрусе

Что в планах:

• корутины на ASM E2K (может быть даже сравнить fcontext ASM на i5 и ucontext/ASM на E2K)

• оптимизировать Reindexer под архитектуру Эльбрус

• перенести еще несколько интересных приложений на Эльбрус

• дополнить базу библиотек и пакетов Эльбрус

• организовать E2K инфраструктуру и песочницу

Что же можно сказать про Эльбрус со стороны простого разработчика?

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

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

Применяемая, в настоящее время, для проектирования СБИС, методология с использованием языков описания аппаратуры, обладает общепризнанными недостатками, а именно:

• Разработка сложных СБИС требует сотни квалифицированных инженеров, несколько лет работы и затрат в миллиарды долларов.

• До половины времени разработки, уходит на поиск и устранение ошибок в программной модели проектируемого микропроцессора.

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

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

Программы DARPA

В рамках программы Electronics Resurgence Initiative, объявленной DARPA, поставлена задача преодолеть проблемы применяемой методологии проектирования микропроцессорных систем. С этой целью реализуется следующие подпрограммы:

• CRAFT предполагает создание средств высокоуровневого синтеза СБИС;

• IDEA направлена на создание автоматического генератора компоновки SoC, многокристальных микросхем, печатных плат;

• POSH нацелена на создание жизнеспособной экосистемы проектирования аппаратуры и верификации, с открытым исходным кодом, которая позволит экономически эффективно проектировать ультра-сложные SoC.

В случае успешного выполнения указанных программ полученные результаты должны быть объединены в перспективных САПР. Предполагается достичь 10 кратного роста в скорости разработки над ручным созданием RTL кода. Кроме того, ставится цель принципиально изменить практику разработки микропроцессорных устройств. Итоговая цель преобразования инженерной практики описана так:

• Разработка СБИС становится частью инструментария разработчика программного обеспечения.

• Каждая компания разработчик ПО, получает возможность разрабатывать СБИС.

Описывая ситуацию в отрасли разработки микропроцессорных систем, DARPA говорит о следующих проблемах (на основе Electronics Resurgence Initiative Page 3 Investments Design Thrust). Интеллектуальные системы следующего поколения, в областях искусственного интеллекта, автономных транспортных средств, связи, радиоэлектронной борьбы и радиолокации, потребуют на порядок большей эффективности обработки, чем та, которую предлагает современная коммерческая электроника. Достижение требуемых уровней производительности, потребует разработки очень сложных платформ SoC, использующих самые передовые технологии интегральных схем. В последние годы сложность микросхем быстро росла, произошел взрыв затрат и времени, необходимых для разработки усовершенствованных SoC, печатных плат и многокристальных сборок (SiP). Предлагаемая инициатива создаст новые парадигмы для интеллектуального физического проектирования и уменьшит барьеры для проектирования высокопроизводительных, высокоэффективных специализированных интегральных схем.

Исследовательский подход в программе CRAFT (из доклада Khailany Brucek CRAFT Final на ERI Summit 2019):

1. Поднять уровень абстракции при разработке аппаратуры:

   a. Использовать языки более высокого уровня, например, C ++ вместо Verilog;

   b. Использовать инструменты высокоуровневого синтеза;

   c. Использовать библиотеки и генераторы, например, MatchLib.

2. Применение методологии AGILE в разработке СБИС:

   a. Небольшие команды, совместно работая над архитектурой, реализацией, VLSI (Very Large Scale Integration);

   b. Непрерывная интеграция и средства автоматической верификации;

   c. AGILE методы управления проектами;

   d. Круглосуточная генерация из С++ в схему.

Предложен высоко продуктивный подход к разработке цифровых СБИС для создания сложных SoC. Маршрут проектирования включает средства высокоуровневого синтеза, объектно-ориентированные библиотеки синтезируемых компонентов на языках SystemC и С++. И модульный подход к физическому проектированию СБИС основанный на мелкозернистом глобально асинхронном и локально синхронном (GALS) тактировании. Методология проектирования была продемонстрирована на 16-нм тестовом чипе FinFET, предназначенном для машинного обучения и компьютерного зрения. (A Modular Digital VLSI Flow for High-Productivity SoC Design, Khailany et al., DAC 2018)

Рисунок 1. Вариант маршрута проектирования предложенный для программы CRAFT [1].

Программа IDEA состоит из двух этапов. На первом этапе будет создан генератор макетов, для создания автоматизированной платформы проектирования печатных плат, SoC и SiP. На втором этапе должна быть создана программная система, которая на основе функционального описание высокого уровня и заданных ограничений, будет создавать печатные платы и микросхемы правильной конструкции на основе обширной библиотеки коммерческих компонентов (COTS). Примеры компонентов COTS включают в себя коммерчески доступные микросхемы для печатных плат, кристаллы для SiP и IP-модули для SoC. Созданный список цепей, будет поступать на вход генератора макетов, разработанного в первой части программы. Таким образом будет создана сквозная автоматизированная платформа проектирования для печатных плат, SoC и SiP.

Рисунок 2. Схема применение искусственного интеллекта для решения задачи проектирования СБИС, по замыслу программы IDEA [5].

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

Рисунок 3. Концепция маршрута проектирования программы IDEA [5].

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

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

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

Рисунок 4. Экосистема с открытым исходным кодом для разработки SoC по замыслу программы POSH [4].

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

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

Промежуточные результаты программ, представленные на ERI Summit 2019, подтверждают возможность достижения заявленной цели.

В частности, в рамках программы CRAFT показаны следующие результаты:

• Снижение трудоёмкости в 8-11 раз для аналоговых и цифровых интегральных схем.

• Сокращение трудоёмкости в 4.3-5.3 раза при переносе на технологию 16-нм GF, продемонстрированное на цифровых и цифро-аналоговых ASIC.

Однако существует ряд проблем:

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

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

• Сама постановка задач для указанных программ, нацеливает создаваемые средства проектирования на разработку специализированных интегральных схем (ASIC), то есть не универсальных СБИС, эффективно исполняющих ограниченный набор алгоритмов. Промежуточные результаты также демонстрируются на опытной разработке специализированных СБИС. То есть, в настоящее время не доказано, что полученные показатели роста производительности проектирования, будут подтверждены в реальной инженерной практике, при разработке перспективных ультра-сложных СБИС широкого спектра применений.

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

Обратим внимание на методы повышения производительности проектирования, используемые в программах DARPA:

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

• Минимизировать участие человека в решении задачи проектирования, за счёт применения средств искусственного интеллекта.

• Создать условия для повторного использования качественных строительных блоков аппаратного обеспечения.

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

Описанные программы опираются на базу существующих решений, готовые к использованию компоненты COTS, IP блоки, программные средства с открытым исходным кодом. Однако, опираясь только на готовые компоненты невозможно достичь высшей производительности или минимального энергопотребления. Разработка новых архитектур, максимально сложных SoC и SiP с использованием новых технологий производства, для этих задач остаётся всё та же методология проектирования, которая критикуется в программах DARPA.

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

В декабре 2019 года компания NVIDIA представила перспективную платформу для самоуправляемых автомашин и роботов [6]. Анонсированный процессор NVIDIA Orin появится не ранее 2022 год. Для обеспечения пятого уровня автономности самоуправляемого автомобиля, потребуется сочетать пару процессоров Orin и два не названных, перспективных, дискретных графических процессора NVIDIA [32]. Уровень быстродействия в этом случае составит до 2000 триллионов операций в секунду, при энергопотреблении до 750 Вт.

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

Другим примером могут служить современные программы создания суперкомпьютеров максимальной производительности, которые реализуют Евросоюз, США, Китай, Япония и другие страны. Эти программы, в частности, реализуемые DARPA и DOE, фокусируются на решении следующих задач [25]:

• Существенный рост производительности при умеренном энергопотреблении;

• Повышение надежности аппаратуры и программ;

• Рост продуктивности программирования.

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

Например, суперкомпьютер Neocortex, создаётся для задач классов DCIGN и RNN это более точное прогнозирование погоды, анализ геномов, поиск новых материалов и разработка новых лекарств. Предположительно, будет введено в эксплуатацию до конца 2020 года [37]. Он объединяет серверы Cerebras CS-1 и HPE SuperDome Flex в единую систему с общей памятью. Сервер Cerebras CS-1 основан на уникальном процессоре Cerebras. На изготовление одного процессора уходит целая 300-мм пластина [2].

Основой для роста сложности микропроцессорных систем, в ближайшем будущем, станет развитие технологии 3D TSV. Например, концепция, предложенная IBM [16], к настоящему моменту, изготовление микроканалов продемонстрировано в кремнии [22].

Рисунок 5. Концепция построения перспективных микропроцессорных систем предложенная IBM [16].

Краткая характеристика современной методологии, ключевые проблемы

К настоящему времени в проектировании сложных микропроцессорных систем сложилась практика, представленная на рисунке 6, в изложении Brucek Khailany (Director of research, ASIC & VLSI NVIDIA Corporation).

Рисунок 6. Использование языков программирования в проектировании СБИС [1].

В процессе проектирования используются различные языки программирования, как специализированные, в частности языки описания аппаратуры (HDL), так и языки высокого уровня общего назначения.

Создаваемое изделие описывается в виде программы на языке описания аппаратуры (HDL). Созданная программа, обычно, представляет собой модель уровня регистровых передач (RTL), которая должна быть преобразована в логическую схему посредством автоматического синтеза (Logic Synthesis). Далее созданную схему необходимо превратить в описание физического изделия. Для чего выполняется последовательность этапов проектирования, которую принято называть физическое проектирование (physical design).

Упрощённая схема маршрута проектирования СБИС, с выделением этапов физического проектирования, представлена на рис. 7.

Рисунок 7. Типовой маршрут проектирования с выделением этапов физического проектирования СБИС [23].

Здесь важно отметить, что инженерная задача разработки вычислительной системы (SiP) разделена на две задачи с разным понятийным аппаратом. Для логического проектирования - математический понятийный аппарат, а для физического проектирования - понятийный аппарат описывающий физические процессы.

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

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

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

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

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

Трудоёмкость проектирования, например, для NVIDIA Xavier оценивается в 8000 человеко-лет [1].

По слова Jensen Huang, на создание NVIDIA V100 потребовалось несколько тысяч инженеров, ушло несколько лет, при примерной стоимости разработки в 3 миллиарда долларов [7].

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

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

Рисунок 9. Стоимость разработки СБИС в зависимости от их сложности [7].

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

Мышление человека в инженерной практике

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

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

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

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

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

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

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

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

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

Происходит это в силу особенности работы человеческой психики в процессе решения инженерных задач.

Мозг (память и мышление) оперирует комплексами, объединяющими все известные субъекту знания о некотором объекте и его ассоциативные связи с другими объектами [20]. То есть визуальное и вербальное представление понятий взаимосвязаны. Но восприятие вербальных и визуальных объектов имеют разные физиологические механизмы и объединяются только на уровне высших психических процессов.

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

Изучение человека в процессе трудовой деятельности привело к выделению в психологии отраслей инженерной психологии и психологии труда. Также, с развитием вычислительной техники, сформировалась область психология программирования [34].

В частности, в рамках психологии программирования, установлено, что профессиональные программисты обладают, отличными от представителей других профессий, особенностями мышления. В том числе, развитыми вербальными способностями. То есть быстрее и с меньшей умственной нагрузкой осваивают новые языки, в том числе искусственные, и работают с текстами [17, 27].

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

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

Любая работа ума создаёт умственную нагрузку, которая постепенно утомляет нервную систему, что снижает концентрацию и повышает вероятность ошибки. Умственная нагрузка, при решении одной и той же задачи, может различаться в зависимости от условий в которых человек должен эту задачу решать. Например, слепая игра в шахматы (не глядя на доску) или решение ханойской головоломки в уме (без физического перемещения дисков) создают большую умственную нагрузку, чем те же задачи находящиеся в поле зрения [10, 12].

Мышление в процессе решения задачи проектирования представляет собой последовательность интеллектуальных действий.

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

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

Восприятие информации предполагает установление соответствия между формами представления информации (установлены методологией) и известным человеку понятийным аппаратом отрасли. Тогда возникает понимание условий задачи и выполняется поиск решения.

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

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

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

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

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

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

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

Связь между формой представления понятий и скоростью восприятия понятий (условий задачи), установлена экспериментально. Следствием этого стало введение терминов образный интерфейс, когнитивная графика, экологический интерфейс. Создание таких интерфейсов внедрено в инженерной практике, прежде всего в операторской работе по управлению сложными промышленными объектами [29].

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

В качестве примера можно привести отрасль авиастроения. Для примера рассмотрим, выполненный не профессионалом, проект тяжёлого конвертоплана созданный в САПР T-FLEX CAD 16 (см. рис. 10). Проект состоящий из более чем 60000 тел был создан одним инженером, исключительно на основе информации из открытых источников и собственного опыта проектирования. На исследование предметной области ушло около 2-х месяцев и ещё примерно 6 месяцев периодической работы на реальное проектирование [31].

Рисунок 10. Проект летательного аппарата в САПР T-FLEX CAD 16.

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

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

Рисунок 11. Визуализация обтекания модели самолёта в виртуальной аэродинамической трубе.

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

В проектировании СБИС точным решением является описание физической структуры изделия, которая будет создана в процессе изготовления СБИС.

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

Источники проблем методологии проектирования

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

Конфликт формы представления понятий

Используемая методология проектирования требует от разработчика представить физическое изделие в форме программы. На всех этапах разработки создаваемое изделие описывается средствами языков программирования, то есть алгоритмическими понятиями, в форме программ (см. рис. 6).

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

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

Такая ситуация создаёт конфликт формы представления понятий, а значит и дополнительную умственную нагрузку.

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

Разрыв целостности маршрута и понятийного аппарата

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

Применительно к существующей технологии производства СБИС выделяют следующие проблемы логического синтеза [23]:

• Задержка на межсоединениях становится доминирующей, что требует совмещения этапов sizing/physical/logic synthesis. Логический синтез без учета реализации схемы в кремнии неэффективен.

• Изготовление транзисторов усложняется, что делает критическим методы проверки, рассеиваемая мощность становится определяющим фактором.

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

Для решения этой проблемы, в программе IDEA, предлагается использовать, на этапе логического синтеза и физического проектирования СБИС, обученные модели искусственного интеллекта (см. рис. 2). При этом результаты должны контролироваться человеком (см. рис. 3).

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

Ранее основным средством решения задачи на этапе схемотехнического проектирования являлось схемное проектирование. Не только как способ описания решения, но как метод мышления в понятиях этапа схемотехнического проектирования.

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

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

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

Требования к личным навыкам

В силу применения языков программирования для описания создаваемого устройства, основная форма представления информации, с которой работает человек тексты на искусственных языках (см. рис. 12).

Рисунок 12. Описание двухвходового мультиплексора на языке SystemVerilog [13].

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

Работа с текстом с минимальной умственной нагрузкой требует развитых вербальных навыков, которые формируются далеко не у всех взрослых людей [33].

Для формирования развитых вербальных навыков (навыков работы с текстами), необходимо соответствующее обучение. Установлено, что такие навыки формируются у профессиональных программистов [17, 27]. Но далеко не у всех людей, прошедших профессиональное обучение по специальностям программная инженерия (software engineer) или прикладная математика.

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

Вывод

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

Проблема и предлагаемое решение

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

Известно лишь два подхода к построению методологии проектирования инструментальный и человеко-ориентированный (антропоцентрический).

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

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

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

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

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

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

Автор предлагаемого проекта, наблюдал на практике эффективность схемного проектирования при разработке микроархитектуры микропроцессора. В рамках проекта суперкомпьютера Ангара, под руководством Эйсымонта Л.К., автор участвовал в разработке микропроцессора с массовым параллелизмом, где применялся метод схемного проектирования. Разработка микроархитектуры выполнялась одним человеком, обладавшим большим опытом схемотехнического проектирования. Применение схемного проектирования показало существенно меньшее количество ошибок, допускаемых человеком, при разработке микроархитектуры и схемотехнической реализации функций блоков. При этом, описание уже готовых схем, на языке Verilog, приводило к появлению ошибок, отсутствовавших в схемном описании. Для сравнения, работая в INTEL Corp., автор участвовал в разработке микропроцессора Kevet (проект закрыт). В проектировании RTL модели микроархитектуры, относительно простого микропроцессора, участвовало 6 инженеров. Для верификации RTL кода, только на микроархитектурном уровне, было задействовано 20 человек.

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

Ранее упомянутый пример, проект тяжёлого конвертоплана выполненный в САПР T-FLEX CAD 16, интересен тем, что проектирование ведётся в визуальной среде, дающей явную связь между понятиями, в которых мыслит инженер, и объектами, составляющими проектируемую систему.

Другой пример из области ракетостроения. При создании космической системы Энергия-Буран, для повышения производительности программирования, были созданы проблемно-ориентированные языки, основанные на терминах, понятиях и форме представления алгоритмов управления и испытаний, используемых разработчиками корабля. Такой подход позволил повысить производительность программирования и надёжность программного обеспечения. В дальнейшем, на основе когнитивно-эргономического подхода, был создан графический язык ДРАКОН. Применение его для создание различных ракетно-космических систем доказало эффективность идей, положенных в его основу [14, 28, 39].

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

Литература

1. A modular digital VLSI flow for high-productivity SOC design. Brucek Khailany director of research, ASIC & VLSI NVIDIA CORPORATION. ERI Summit 2018.

2. Cerebras процессор для ИИ невероятных размеров и возможностей. Геннадий Детинич. 20.08.2019. https://3dnews.ru/992698 (дата обращения: 11.11.2020)

3. DARPA мечтает радикально упростить проектирование чипов. 04.07.2018 https://3dnews.ru/972103 (дата обращения 07.05.2019)

4. IDEA & POSH program updates. Andreas Olofsson. DARPA MTO program manager. ERI Summit 2019.

5. Intelligent Design of Electronic Assets (IDEA) & Posh Open Source Hardware (POSH) // Andreas Olofsson Program Manager, DARPA/MTO. Proposers Day Mountain View, CA. 9/22/17.

6. NVIDIA Introduces DRIVE AGX Orin Advanced, Software-Defined Platform for Autonomous Machines. Tuesday, December 17, 2019. https://nvidianews.nvidia.com/news/nvidia-introduces-drive-agx-orin-advanced-software-defined-platform-for-autonomous-machines (дата обращения: 11.11.2020)

7. Silicon Compilers - Version 2.0 // Andreas Olofsson Program Manager, DARPA/MTO. International Symposium on Physical Design. March 25-28, Monterey, CA. 2019.

8. Будылина С.М., Смирнов В.М. Физиология сенсорных систем и высшая нервная деятельность: Учеб. пособие для студ. высш. учеб, заведений. М. 2003.

9. Бухтев А. Методы и средства проектирования систем на кристалле. // Chip News 2003. -4.

10. Гигиена труда : учебник / под ред. Н. Ф. Измерова, В. Ф. Кириллова. -2-е изд., перераб. и доп. -М. : ГЭОТАР-Медиа, 2016.

11. Горбунов В., Елизаров Г., Эйсымонт Л. Экзафлопсные суперкомпьютеры: достижения и перспективы. Открытые системы. СУБД 2013. -07 http://www.osp.ru/os/2013/07/13037342/ (дата обращения 05.11.2013)

12. ГОСТ Р ИСО 10075-2011 Эргономические принципы обеспечения адекватности умственной нагрузки. Основные термины и определения.

13. Дональд Томас. Логическое проектирование и верификация систем на SystemVerilog / пер. с анг. А. А. Слинкина, А. С. Камкина, М. М. Чупилко; науч. ред. А. С. Камкин, М. М. Чупилко. М.: ДМК Пресс, 2019.

14. ДРАКОН [электронный ресурс]: Википедия. Свободная энциклопедия. https://ru.wikipedia.org/wiki/ДРАКОН (дата обращения: 11.11.2020)

15. Ильин Е. П. Дифференциальная психология профессиональной деятельности. СПб.: Питер, 2008. 16. Инновационные суперкомпьютерные технологии и проблемы создания отечественной перспективной элементной базы. / Л.К.Эйсымонт, В.С.Горбунов. Доклад на 5-м Московском суперкомпьютерном форуме. 21 октября 2014 года.

17. Исследование способности к усвоению искусственных языков у программистов. Орел Е. А. ОРГАНИЗАЦИОННАЯ ПСИХОЛОГИЯ. Т. 2. 2. 2012.

18. Как устроена универсальная разумная система? Анохин К.В. Наука о поведении: четыре главных вопроса Школа молодых ученых, 7-13 октября 2015. https://scorcher.ru/articles/images/3678/anokhin.pdf (дата обращения 08.09.2019)

19. Канышев В., Шагурин И. Применение языка SystemC и средств разработки на его основе для проектирования Систем на кристалле. // Chip News 2006. -9.

20. Когнитом: разум как физическая и математическая структура. К.В. Анохин. Семинар Социофизика. 27 сентября, 2016.

21. Космический ДРАКОН. Как заброшенный проект "Роскосмоса" подарил язык литовской медицине. Николай Воронин. BBC NEWS Русская служба. 5 августа 2019. https://www.bbc.com/russian/features-48583773 (дата обращения: 11.11.2020)

22. Кремниевый радиатор с микроканалами с жидкостью в 100 раз лучше металлического. 01.03.2019 https://3dnews.ru/983605 (дата обращения: 05.05.2019)

23. Ложкин С.А., Марченко А.М. Математические вопросы синтеза интегральных схем. [электронный ресурс] http://mk.cs.msu.ru/index.php/Математические_модели_и_методы_синтеза_СБИС (дата обращения: 15.10.2013)

24. Марков И. Проектирование интегральных схем: от разбиения графов до временной оптимизации систем. Лекции на факультете ВМК МГУ. 2013.

25. На пути к экзафлопсному суперкомпьютеру: результаты, направления, тенденции. / Горбунов В.С., Эйсымонт Л.К. Доклад на третьем Московском суперкомпьютерном форуме 01.11.2012

26. Общая психология : учебник для вузов / В. В. Нуркова, Н. Б. Березанская. 3-е изд., перераб. и доп. М. : Издательство Юрайт, 2017.

27. Особенности интеллекта профессиональных программистов. Орел Е. А. BECTH. MOCK. УН-ТА. СЕР. 14. ПСИХОЛОГИЯ. 2007. 2.

28. Параджанов В. Д. Как улучшить работу ума: Алгоритмы без программистов это очень просто! М.: Дело, 2001.

29. Представление информации для поддержки когнитивной деятельности человека-оператора. Анохин А. Н. // Актуальные проблемы психологии труда, инженерной психологии и эргономики. Выпуск 6 / Под ред. А. А. Обознова, А. Л. Журавлева. М.: Издательство Институт психологии РАН, 2014.

30. Применение концепций инженерной психологии к профессиям, традиционно не считающимся операторскими. С.А. Дружилов // Электронный журнал Психологическая наука и образование 1 2011.

31. Проект тяжёлого конвертоплана в T-FLEX CAD 16 (более 60000 тел). T-FLEX CAD. 25.11.2019. https://3dtoday.ru/blogs/topsystems/proekt-tyazhelogo-konvertoplana-v-t-flex-cad-16-bolee-60000-tel (дата обращения: 11.11.2020)

32. Процессор NVIDIA Orin шагнёт за пределы 12-нм технологии с помощью Samsung. Алексей Разин. 19.12.2019. https://3dnews.ru/1000054 (дата обращения: 11.11.2020)

33. Психология мышления. Гурова Л.Л. М.: ПЕР СЭ, 2005.

34. Психология программирования: цели, проблемы, перспективы. Рожников В. А. ОБЩЕСТВО: СОЦИОЛОГИЯ, ПСИХОЛОГИЯ, ПЕДАГОГИКА 3 2014.

35. Стасевич К. Человеческий мозг похудел на 14 миллиардов нейронов. 01.03.2012 года. http://compulenta.computerra.ru/archive/neuroscience/664455/ (дата обращения: 15.10.20013)

36. Стрелков Ю.К. Инженерная и профессиональная психология. 2-е изд. - М.: Издательский центр Академия, 2005.

37. Суперкомпьютер Neocortex: 800 тыс. ядер Cerebras для ИИ. Юрий Поздеев. 09.06.2020. https://servernews.ru/1013005 (дата обращения: 11.11.2020)

38. Финский суперкомпьютер получит 200 тысяч ядер благодаря 7-нм CPU AMD EPYC Rome. 15.12.2018 https://servernews.ru/979696 (дата обращения: 07.06.2019)

39. Энергия Буран [электронный ресурс]: Википедия. Свободная энциклопедия. https://ru.wikipedia.org/wiki/Энергия__Буран (дата обращения: 11.11.2020)

ПРОЛОГ. В корпорации идёт обыск. У парадного входа с колоннами стоит вереница тёмно-синих, c глухой тонировкой микроавтобусов Volkswagen transporter. Рядом с ними курят пара человек в штатском, большинство внутри здания. ИТ-директор предприятия ходит из угла в угол своего кабинета, откуда его вежливо, но очень сухо попросили никуда не выходить, Вас обязательно вызовут резануло его слух и с тех пор не выходило из головы. Ожидание страшнее казни, вспомнился Федор Михайлович. В его голове крутился один вопрос найдут или не найдут. Конечно, основное телеком-оборудование он давно поменял на отечественное, но во втором ЦОД-е и в парочке удаленных серверных оставалось еще несколько цисок и пара блейдов хьюлета всё еще использовались в качестве файловых помоек

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

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

• Было внесено изменение в постановление 145, о правилах использования каталога товаров, работ, услуг для обеспечения государственных и муниципальных нужд.

• Для закупок по 44 ФЗ приняты постановления 878, 961, 2013 (Третий лишний, Предел для Единственного поставщика, О минимальной доле закупок товаров российского происхождения)

• Для закупок по 223 ФЗ - постановления 925, 878, 2014 (Приоритет товаров российского происхождения, Третий лишний, О минимальной обязательной доле закупок российских товаров).

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

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

  Перечислим основные реестры российского:

  Для ПО используется реестр МинЦифры: https://reestr.digital.gov.ru/.

  Для промышленной продукции реестр МинПромТорга: https://gisp.gov.ru/pp719v2/pub/prod/.

  Для радиоэлектронной продукции ещё один реестр, Единый реестр российской радиоэлектронной продукции: https://gisp.gov.ru/documents/10546664/. Заметим, что с погрешностью в десять дней, указанная в нём продукция будет являться частью реестра МинПромТорга.

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

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

Как поступают заказчики в этих реалиях?

1. Используют КТРУ максимально прямо. Есть случаи, когда заказчик получает то, на что он рассчитывал, но это в большинстве случаев получается наоборот.

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

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

4. Производят различные действия с составом спецификации закупки (объединяют, наоборот разбивают, используют альтернативные варианты продуктов с другими кодами КТРУ) и т.д.

5. Применяя КТРУ, обосновывают указание дополнительной информации (при этом морально готовы отстаивать свое обоснование в ФАС). Ниже пример такого обоснования:

Еще один пример - невозможность закупать по 44-ФЗ автоматизированное рабочее место и ПО. Наиболее безопасный для заказчика вариант - закупать компьютерное оборудование (АРМ) и программное обеспечение (в т.ч. операционные системы) порознь. В тех случаях, когда это технически невозможно (например, если планируемые к закупке компьютеры в принципе не продаются без операционных систем), заказчику нужно быть готовым доказать правомерность формирования "объединенного" лота.

При этом, закупки ПАК проходят без вопросов со стороны ФАС, например - поставка программно-аппаратного комплекса ВКС Минздрава России для обеспечения выполнения задач ситуационного центра.

Указан состав ПАК (сервер, мониторы, беспроводная система презентаций и др.). Ряд из этих товаров есть в КТРУ (Сервер 26.20.14.000-00000189 и др.) На поступившую жалобу - не описаны компоненты по КТРУ - ФАС ответила, что заказчик прав, так как предмет закупки ПАК в КТРУ отсутствует.

Давайте изучим саму процедуру закупки.

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

Посмотрим, какие этапы проходит бюджетное учреждение при закупке радиоэлектронного оборудования по 44-ФЗ:

Как можно заметить, чисто технических блоков (зелёные), которые напрямую зависят от технического специалиста всего несколько. И есть пара блоков (красные), которые, наоборот, оказывают значительное влияние на техническую составляющую закупок (а не зависят от технического специалиста, скорее он от них). Блоков, в которых может потребоваться его участие как технического специалиста (желтые), уже побольше. Остальные блоки (белые) скорее организационные: они не особо пересекаются с технической составляющей закупок, но их необходимо исполнять/соблюдать для корректного осуществления закупок по 44-ФЗ (или по 223-ФЗ для второй схемы).

Ключевая техническая составляющая закупки это ТЗ. От предварительного до финального. Здесь для инженера важно, чтобы объект закупки действительно решал поставленную задачу, интегрировался в существующий ландшафт, позволял попадать в различные требуемые RPO/RTO и т.д. А ещё хочется, чтобы он был удобен в эксплуатации, администрировании, обслуживании. Сюда же отнесём не совсем технический вопрос: целевое расходование средств; т.е. задача, должна быть выполнена, но нет смысла в звездолёте, там, где достаточно обычной машинки.

Строгий закон 44-ФЗ, по которому обязаны проводить закупки государственные и муниципальные заказчики, порождает весьма ограниченный выбор закупаемого оборудования.

В отличие от него, работа по 223-ФЗ предполагает:

• что заказчикисамостоятельно разрабатывают правила проведения закупочных процедур, которые прописывают вПоложении о закупке;

• что лицом, которому поручены закупки, может бытьлюбой специалист организации(профильного образования не требуется);

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

Закупка радиоэлектронного оборудования по 223-ФЗ:

Но, и в случае закупки по 223 заказчику надо учитывать несколько неприятных моментов:

1. При проведении аукционов, либо других закупок с пошаговым снижением, победитель с радиоэлектронной продукцией из иностранного государства должен будет снизить свою ценуна 30%. Т.е. эти 30% надо закладывать в стоимость лота. (ПП 925)

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

Таким образом, если понадобится купить нормальный ноутбук (1 шт.), заказчику придется купить к нему ещё один. И не просто отечественной отвёрточной сборки, но и зарегистрированный в реестре Минпромторга. (ПП 2013)

Однако, постановление 2013 пока не предусматривает обязанность заказчика составлять какой-либо отчет о достижении им минимальной доли и размещать сведения о достижении доли в ЕИС.

На день подготовки настоящего материала, законодательство Российской Федерации также не предусматривает мер ответственности для заказчика за недостижении им установленной минимальной доли.

Мы предполагаем, что требования об исполнении минимальных долей могут быть предъявлены директивами Правительства к хозяйственным обществам, доля участия в которых Российской Федерации превышает 50%. Возможно, что такие директивы также затронут деятельность госкорпораций.

Перед теми, кто закупает по 44 и 223 ФЗ сейчас стоит выбор:

Вариант 1: стоять на своём, закупать то, что нравится, что проверено, наиболее знакомо, наименее непривычно и/или неудобно. Каким бы ни был курс доллара.

Вариант 2: прогнуться и купить что-то и положить это что-то на полку. Есть устойчивое мнение, что лоббисты российских недоделок, переклеивателей шильдиков, жигули с логотипом мерседеса российского ИТ-рынка, спят и видят, как бы навязать их всем российским компаниям, используя административный ресурс. И это еще один кошмар ИТ-директора.

Вариант 3: знакомиться с отечественными решениями и закупать подходящее. В это верится с трудом, но есть работающие отечественные разработки, сопоставимые по цене или дешевле импортных. Особенно это касается ПО, т.к. импортное ПО с этого года стало облагаться НДС 20%, а российское осталось безНДС-ным. Таким образом комбинируя закупки отечественного и импортного и волки сыты и овцы целы.

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

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

- политика партии руководства предприятия да, многое зависит от установок директора (от злостного игнорирования всех постановлений, до прямо противоположной паранойи)

- задачи, решаемые ИТ-департаментом (технический аспект) привязка к сформировавшемуся ландшафту и т.д.

- бюджет ну куда ж без него

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

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

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