С точки зрения поставщика ПО все, как будто, неплохо – полностью решается проблема нелегального распространения ПО, пользователи автоматически получают последнюю версию системы и ее сервисные обновления, не требуется служба сопровождения, непрерывно воюющая с проблемами инсталляции на разношерстном оборудовании.
Все это так, но есть несколько подводных камней, которые не могут не настораживать.
Во-первых, возникает проблема с тем, где хранятся данные. По идеологии «облачных» решений данные размещаются там же – в облаке, т.е. на серверах провайдера. В общем ничего особенного в этом нет – мы уже привыкли, что, например, наша почта хранится на серверах google, обеспечивающего сервис gmail. Однако данные САПР – несколько иная ипостась. Достаточно много предприятий просто не могут хранить данные где-либо, кроме как в своих локальных хранилищах по соображениям информационной безопасности, да и просто по требованиям режима секретности. Более того, в их практике – использование локальных сетей, полностью изолированных от внешнего мира и интернета, каким же образом из такой сети получить доступ к ПО, предлагаемому лишь как глобальный сервис?
Во-вторых, существуют данные, которые просто необходимо сохранять и использовать локально. Ради примера: программы ЧПУ, которые необходимо загружать в станки, геометрические данные, подготовленные для печати на 3D принтере, да даже просто чертежи, печатаемые на обычном принтере-плоттере.
В-третьих, не так все ясно с анонсируемой поклонниками «облачной» технологии высокой производительностью всей системы. Безусловно, распараллеливание вычислений на несколько мощных машин приводит к ускорению выполнения одного конкретного цикла расчетов. Но – одного, теперь вспомним, что только у SolidWorks официально поставлено более миллиона лицензий. Предположим, что единовременно их используют, скажем, 10% всех клиентов. Таким образом, чтобы обеспечить им ту же производительность, что они имеют прямо сейчас, необходимо создать кластер из десятков, возможно даже сотен тысяч компьютеров – задача сама по себе пока что нетривиальная.
В-четвертых, современный САПР среднего, а тем более высокого уровня – не однокомпонентная система, в нее входят десятки приложений, зачастую разработанных не основным разработчиком, а его партнерами или просто независимыми поставщиками. Таким образом, чтобы сохранить рабочую обстановку и конфигурацию, которую инженеры используют сейчас, придется синхронизовать в облаке десятки продуктов в тысячах конфигураций – задачи у пользователей совершенно разные.
Все это наводит меня на мысль, что «облачные» технологии если и случатся с нашей отраслью, то, скорее всего, совсем не в том виде, в каком их описывают нынче энтузиасты. Определенно, какая-то часть пользователей предпочтет получать доступ к ПО как к сервису, особенно в части вычислительных приложений, таких как системы инженерного анализа. Но будет и другая часть, для которой по-прежнему будут актуальны системы, установленные либо в изолированной собственной локальной сети и даже на десктопах.
У Николенко есть ссылка на Аирбас, где есть ограничения на уровень технологии при проектировании.
Реализация MBSE-подхода при проектировании сложной продукции в PLM-решении АСКОН
Действительно, в большинстве публикаций по СИ отсутствует учет особенностей производства. Много внимания управлению требованиями. И производство должно их сформулировать, но часто этого нет. Не...
Реализация MBSE-подхода при проектировании сложной продукции в PLM-решении АСКОН
Разрешите поинтересоваться, при чем тут учет особенностей производства? При правильном определении требований нюансы производства должны фиксироваться как ограничения и попадать в спецификацию...
Реализация MBSE-подхода при проектировании сложной продукции в PLM-решении АСКОН