Информатизация в тепловых сетях

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

Рубрика Программирование, компьютеры и кибернетика
Вид статья
Язык русский
Дата добавления 26.02.2017
Размер файла 49,8 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Информатизация в тепловых сетях: советы непостороннего

А. Р. Ексаев, М.Г. Шумяцкий, И ВЦ «Поток»

Если проанализировать динамику рыночных тенденций, инвестиционной активности предприятий отрасли, содержания публикаций в специализированной и отраслевой прессе (ЖКХ, водоснабжение и водоотведение, теплоснабжение, геоинформатика, информационные технологии) за последние 5-7 лет, то становится очевидно, что в настоящее время большинство предприятий, эксплуатирующих муниципальные инженерные сети, уже окончательно «созрели» для осмысленного внедрения комплексных информационных систем. Причин тому много, и вряд ли здесь стоит останавливаться на них отдельно. Факт состоит в том, что отрасль стоит на пороге массового «информационного взрыва». Уже сейчас потребности предприятий инженерных коммуникаций и, в частности, тепловых сетей, в квалифицированных информационных услугах и специализированном программном обеспечении стали превышать объем реальных предложений со стороны серьезных компаний-поставщиков. Такая ситуация неизбежно должна привести к массовому появлению на рынке продуктов и услуг, направленных на быстрое удовлетворение растущего «информационного голода». Этот процесс уже происходит, что, безусловно, очень хорошо с точки зрения развития технологий и их удешевления. Однако есть два фактора, существенно усложняющих для предприятий задачу выбора адекватных решений из всего многообразия предложений.

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

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

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

Топооснова и борьба за координатную точность

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

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

В случае, если никакой электронной топоосновы нет, ее, в качестве начального приближения, надо создавать самостоятельно, чтобы не откладывать в долгий ящик внедрение содержательных информационных задач. Это сделать гораздо проще, чем может показаться. Великолепной исходной основой послужат наверняка имеющиеся в службах бумажные копии планшетов масштаба 1:2000. Для начала этого более чем достаточно. Есть простые и надежные технологии, позволяющие перевести их в электронный вид, вполне пригодный для начала работы по паспортизации. В дальнейшем всю графическую информацию можно уточнять по поступающей исполнительной документации (масштабной, с привязкой по «крестам»), постепенно доведя ее до желаемой точности. Оцифровывать с самого начала планшеты М1:500, даже если они есть, - если не бессмысленно, то уж во всяком случае, нерационально, поскольку трудозатраты (и, соответственно, сроки) на эту работу в несколько раз выше, а информационная ценность с точки зрения эксплуатационных задач в теплосетях - близка к нулю, особенно в условиях отсутствия отлаженного процесса «дежурства» карты городом. «Пятисотка» хороша, когда на ней есть и «чужие» коммуникации, но первоочередная задача -паспортизация собственных сетей теплоснабжения и ГВС, а прорисовку «чужих» сетей лучше предоставить их владельцам. Конечно, точная «пятисотка», используемая во всех организациях, эксплуатирующих инженерные коммуникации, - лучший путь к решению в дальнейшем задачи согласования раскопок на компьютере. Но состояние дел практически в любом городском хозяйстве на сегодня таково, что согласование раскопок все равно в ближайшем обозримом будущем будет производиться представителями на местности, и связывать по времени решение насущных эксплуатационных задач в теплосетях с возможностью решения задачи согласования раскопок - значит перенести начало решения крайне актуальных уже сегодня проблем в неблизкое будущее.

Рано или поздно точная электронная топооснова все равно появится, и перепривязка к ней графического подмножества базы данных по сети сводится к достаточно простым операциям, не сравнимым по трудозатратам с паспортизацией сети и созданием ее информационной модели. Для справки: «графическая» составляющая информационного описания трубопроводной сети не превышает 10-12% от общего объема информации, который приходится вводить, а главное - добывать.

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

Право собственности на информацию

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

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

Мы можем порекомендовать два способа решения этой проблемы.

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

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

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

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

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

Распределенный доступ к информации

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

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

Информационная модель трубопроводной сети

информационный трубопроводный сеть система

Это, пожалуй, наиболее важный вопрос, недооценка которого сказывается далеко не сразу, но, тем не менее, приводит к печальным последствиям, в том числе и материальным. К сожалению, в силу информационной и математической специфики, суть данной проблемы не видна на первый взгляд и потому в большинстве случаев игнорируется либо откладывается «на потом». А «потом» оказывается поздно…

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

гидравлических расчетов, моделирования и анализа режимов;

анализа отключений и выдачи отчетов о включенных/отключенных абонентах и нагрузках;

выработки рекомендаций по локализации аварийных ситуаций;

расчета тепловых потерь и распределения температур по сети;

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

… (список можно продолжить, предлагаем поупражняться самостоятельно).

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

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

«И опыт, сын ошибок трудных…»

Опытные покупатели знают самый главный секрет - как свести к минимуму риск отрицательного результата. Собственно, это секрет Полишинеля: первый вопрос, который задает видавший виды руководитель потенциальному поставщику: «А где это УЖЕ РАБОТАЕТ?». И начинает загибать пальцы, выслушивая ответ. Если он здоров, а пальцев на одной руке все равно не хватает - можно приступать к следующему шагу. А именно - уточнить контактные координаты хотя бы трех-пяти объектов из числа перечисленных, и обязательно с ними связаться. С несколькими. Очень желательно съездить лично, посмотреть-потрогать-поговорить. Ну, в крайнем случае, вступить в переписку с коллегами. Не бойтесь, вам никогда не откажут в консультации и отзыве об опыте работы с конкретным поставщиком. Если результаты положительные. И в особенности, если результаты отрицательные. Вы в любом случае не останетесь без информации. Это, конечно, еще не гарантия верного решения, но серьезная пища для размышлений. Добавив сюда личные впечатления от общения с потенциальным поставщиком (как он владеет терминологией, как реагирует на поставленные перед ним простенькие, либо, наоборот, заведомо нереализуемые задачи, что и как он готов вам продемонстрировать, в конце концов, насколько он вам симпатичен как человек), то у вас неплохие шансы принять верное решение.

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

Кому поручить «черную работу»

Довольно распространенным явлением стало предложение (обычно дорогое) поставки информационной системы, так сказать, «под ключ», т.е. -вместе с данными. Очень соблазнительное решение, особенно если деньги у вас есть, а с «человеческим ресурсом» - беда. На такие поставки можно соглашаться только в самых крайних случаях, да и то - если ваш контрагент многократно «проверен» на практике, и вы абсолютно доверяете его технологической квалификации. Никто на свете не опишет ваши сети лучше и правильнее, чем вы сами -тот персонал, который эти сети эксплуатирует. Для любого человека со стороны это «чужая» информация, и отвечать за ее корректность сторонний подрядчик не будет. Достоверность и качество информации очень сложно проконтролировать. Хоть какой-то гарантией, если не качества, то стремления к нему может служить лишь осознание, что работу делаешь «для себя» (проверьте это утверждение на личных примерах из частной бытовой жизни). Не в том дело, что вас захотят обмануть, отнюдь. Просто цели и подходы к вопросу различны… Это вам не все равно - диаметр той трубы 50 или 500 мм. Для человека «постороннего» это не более чем опечатка (запятую не там поставил), а для вас - причина совершенно абсурдного результата, например, при моделировании гидравлики… Вывод: используйте все возможности для того, чтобы организовать сбор, подготовку и ввод данных собственными силами. В крайнем случае - посадите отвечающего за этот процесс подрядчика у себя в ПТО или в диспетчерской, рядом со своими специалистами, которые будут участвовать в процессе и не дадут возможности схалтурить или ошибиться. Если все же рискнете поручить эту работу сторонней организации - будьте готовы к тому, что на ваш персонал может впоследствии лечь большая работа по контролю и корректировке данных, либо информационная система окажется нежизнеспособной и постепенно «умрет», а вы так и не поймете, отчего это произошло.

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

Когда начинать

Если честно - вчера. Как показывает практика, наличие, достоверность и качество информации о сетях сегодня в большинстве предприятий не выдерживает никакой критики. Сколько-нибудь стабильно и надежно управлять «черным ящиком», да еще в условиях острой недостаточности ресурсов и крайней степени физического износа - практически невозможно. Надо как минимум «узнать всю правду» про объект эксплуатации, а полученную информацию упорядочить, структурировать и проанализировать. На это нужно время, много времени. Быстрых решений (опять же - опыт) не получается. Паспортизация магистральных и разводящих теплосетей среднего российского города (100-200 тыс. жителей) даже при очень интенсивной организации этих работ занимает не менее полутора-двух лет. Скорее всего - от трех до пяти лет. Соображения типа «столько лет без компьютеров жили, и еще проживем» - уже не проходят, потому что запас надежности сетей практически исчерпан. Малейшая ошибка в оперативном управлении, планировании режимов, составлении графиков ППР и т.п. - может привести к социальному взрыву со всеми вытекающими последствиями. Поэтому начинайте сейчас, срочно. Оцените свои ресурсы и примите максимально эффективное решение по информатизации, доступное с этими ресурсами. Посоветуйтесь с коллегами по отрасли, найдите экспертов, которым можно доверять, поищите информацию в Интернете, в прессе, на совещаниях и семинарах, попробуйте привлечь хоть какие-то инвестиции… Но не откладывайте принятие решения - альтернативы все равно не существует. А чем раньше начнете, тем легче будет справиться.

Размещено на Allbest.ru

...

Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.