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

Разработка концепции АСУ ТП

Обсуждение вопросов, не относящихся ни к одному из других подразделов

Автор темы
Evgeny
здесь недавно
здесь недавно
Сообщения: 44
Зарегистрирован: 22 фев 2010, 19:25
Ф.И.О.: Черкасский Евгений Валерьевич

Разработка концепции АСУ ТП

Сообщение Evgeny » 22 фев 2010, 19:33

Доброго времени суток!
Поделитесь, пожалуйста, опытом оформления документации по данной стадии проектирования АСУ ТП. По ГОСТу 34.601 она предшествует стадии "Техническое задание". Я знаю, что в реальной жизни этот концептуальный этап часто опускается, вполне достаточно предоставить ТЭО и Техническое задание, но в моем случае идет речь об учебном дипломном проекте, где должны быть представлены так или иначе все стадии создания АСУ ТП.

Собственно вопросы:
1. Как обычно выбирают базовый вариант АСУ ТП для сравнения с предлагаемой?
2. Какие схемы, диаграммы принято показывать для того, чтобы более четко подчеркнуть преимущества предлагаемого перед базовым вариантом?

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

Аватара пользователя

TEB
специалист по DEIF
специалист по DEIF
Сообщения: 7909
Зарегистрирован: 17 июн 2008, 15:01
Ф.И.О.: Евгений свет Брониславович
Благодарил (а): 38 раз
Поблагодарили: 66 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение TEB » 22 фев 2010, 20:04

А Вы не путаетесь в терминологии? Не занаучиваете?

Как правило, альтернативы и рассмотрение прочих вариантов и выбор лучшего - оформлять и куда-то представлять на практике не требуется. Нужно просто описать предлагаемое и объяснить как работает, и всё. Такие сравнения естественно проводятся, но обычно они не оформляются потому что никуда не представляются - за ненадобностью. Так что ГОСТы можете не копать на этот счёт.

В Дипломе я делал сравнение и оформлял его (только в Дипломе это и понадобилось). Берёте Ваш вариант, придумываете ещё один-два варианта, поочевиднее (не надо занаучивать - чтобы принципиальная разница была на ладони), обсчитываете по критериям:
  • капиталловложения при строительстве (стоимость оборудования, и примерно прикиньте будут ли отличаться строительные работы по сложности, если не будут - на них забываем);
  • эксплуатаионные расходы (сколько надо запчастей заменить или докупить за год эксплуатации);
  • трудоёмкость разработки (сколько времени скольки инженеров на это уйдёт, в человекочасах)
  • трудоёмкость монтажа и наладки (то же самое, например в варианте 1 надо 5 гаек закрутить, в варианте 2 ни одной);
  • трудоёмкость эксплуатации (то же самое, из расчета на 1 год эксплуатации, сколько чего подтянуть, поднастроить, поверить за год).
  • какова будет чистая прибыль и окупаемость установки в итоге (доход от эксплуатации минус затраты по перечисленным выше пунктам, и за какой срок внедрение Вашей системы во всех вариантах окупится)
И у Вас должно получиться что Ваш вариант по этим критериям наименее затратный и наиболее выгодный, а Вам необходимо описать, почему именно.
По вопросам работы Форума можно обратиться ко мне, или по этим контактам.


Автор темы
Evgeny
здесь недавно
здесь недавно
Сообщения: 44
Зарегистрирован: 22 фев 2010, 19:25
Ф.И.О.: Черкасский Евгений Валерьевич

Re: Разработка концепции АСУ ТП

Сообщение Evgeny » 22 фев 2010, 20:12

Ну примерно то же самое предлагается сделать и в небезысвестном справочнике Федорова.
Все выгоды и оценки по экономической эффективности будут рассчитаны в организационно-экономической части на основе технорабочего проекта (когда будет известна уже точная структура КТС, программного комплекса, персонала).
Выходит, что с этой концепцией всё задом-наперёд: "Сам придумал-сам накопал кучу недостатков" в каком-то гипотетическом базовом варианте, которого отродясь в природе не было (объект новый).
Вопрос просто заключается, как графически представить свои изыскания: то ли через диаграммы UML (например, use case), что вот дескать, тут диспетчер сам снимал показания приборов и архивировал их в амбарную книгу, а тут сервер истории появился с БД и подсистемой ведения архивов и формирования отчетов, то ли через функциональную диаграмму IDEF0...
В том-то вся и проблема, что обычно это никто не делает на практике. Тем более у меня стоит задача проектирования только ПО верхнего уровня (SCADA-проект)... Может имеет смысл сравнить между собой какие-то СКАДЫ разных производителей - по критериям, которые приводятся в разных журналах по АСУ ТП :ges_hmm:

Аватара пользователя

TEB
специалист по DEIF
специалист по DEIF
Сообщения: 7909
Зарегистрирован: 17 июн 2008, 15:01
Ф.И.О.: Евгений свет Брониславович
Благодарил (а): 38 раз
Поблагодарили: 66 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение TEB » 22 фев 2010, 22:07

Evgeny писал(а):Выходит, что с этой концепцией всё задом-наперёд: "Сам придумал-сам накопал кучу недостатков" в каком-то гипотетическом базовом варианте, которого отродясь в природе не было (объект новый).

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

Evgeny писал(а):В том-то вся и проблема, что обычно это никто не делает на практике. Тем более у меня стоит задача проектирования только ПО верхнего уровня (SCADA-проект)... Может имеет смысл сравнить между собой какие-то СКАДЫ разных производителей - по критериям, которые приводятся в разных журналах по АСУ ТП :ges_hmm:

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

Просто взять две разные СКАДА - бессмысленно. Если у Вас 1500 точек в/в, и вы выбираете две скады, одна из которых максимум на 2000 точек а вторая на 20000 - ясен пень что обе они будут работать одинаково, но по второй затраты выше. Сама структура сравниваемых систем должна быть разной.

В моем дипломе было несколько проще, т.к. критерии были другие. Разработал автоматизированную электростанцию из трёх агрегатов. Экономически доказывал по двум критериям:
  1. выбор именно трёх агрегатов, сравнил с вариантом на два агрегата и на четыре - три агрегата получились оптимальны по размещению (4 уже не вписывались по месту и по объему ЗИП - были ограничения), кап.затраты естественно больше чем станция из 2 агрегатов, но зато эксплуатационные расходы получились чуть меньше, а суммарная надёжность станции из 3-х агрегатов выше чем из двух за счет резервирования.
  2. для автоматизации применил устройства "всё-в-одном", т.е. по одному контроллеру на каждый агрегат, и сравнил с вариантом использования набора однофункциональных простых устройств (комплект устройств на каждый агрегат). Получил что кап.затраты в случае с "всё-в-одном" чуть больше за счет необходимости программирования, зато массогабариты меньше, гибкость при модернизации намного выше (во втором варианте придется провода крутить, а тут софт в контроллере править), ЗИПа меньше. Надежность получилась одинаковой. Ремонтопригодность у "всё-в-одном" естественно хуже (программист на вахте не сидит), но на ура прошел критерий "в наш век передовых микропроцессорных технологий..." :)
Объект - судовая электростанция, есть своя специфика (ограниченность места, лимит массы, требования надежности). И кстати такой анализ с тех пор ещё мне дал понимание того, что в некоторых случаях нефиг ставить контроллеры, навороченные интерфейсы и красивые АРМы, бывают случаи (и их немало) где требуется в первую очередь дубовая надежность и чтоб любой матрос смог разобраться и - самое главное - устранить неисправность на месте.

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

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

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


Автор темы
Evgeny
здесь недавно
здесь недавно
Сообщения: 44
Зарегистрирован: 22 фев 2010, 19:25
Ф.И.О.: Черкасский Евгений Валерьевич

Re: Разработка концепции АСУ ТП

Сообщение Evgeny » 22 фев 2010, 22:19

Очень интересный, и самое главное, конкретный подход у Вас в проекте был :good:
Просто мечтаю сделать подобное логичное обоснование.
На настоящий момент остановился на следующем:
-первый вариант - автономная АСУ ТП с локальной станцией оператора котельной (блочно-модульной - собственно мой объект автоматизации);
-второй вариант (который в общем-то требуется в ТЗ Заказчика) - АСУ ТП с удаленным диспетчированием.
Априори первый вариант проигрывает просто потому что не удовлетворяет всем требованиям Заказчика - а именно удаленному сбору сигналов и контролю работы агрегатов. Тем не менее похоже, что капитальные затраты на 1 консоль оператора будут ниже гораздо, чем на удаленные АРМы операторов+коммуникационное оборудование (с резервированием линий связи).
Остаётся найти способ "опустить" первый вариант по эксплуатационным затратам (по необходимости присутствия персонала в котельной или еще по чему), чтоб уж по стандартному критерию конкурентоспособности типа "цена/качество" мой дипломный вариант вышел окончательным победителем. :roll:

Аватара пользователя

TEB
специалист по DEIF
специалист по DEIF
Сообщения: 7909
Зарегистрирован: 17 июн 2008, 15:01
Ф.И.О.: Евгений свет Брониславович
Благодарил (а): 38 раз
Поблагодарили: 66 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение TEB » 22 фев 2010, 22:41

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

Я Вам подкину ещё третий вариант: распределённая АСУ, когда автоматика каждого агрегата работает автономно, но будучи состыкованы вместе (по интерфейсу) агрегаты обеспечивают общий алгоритм управления, при этом программно и аппаратно друг от друга по прежнему независимо. То есть единой СЛТ нет. Не знаю как исключительно в котельных, а в микроэнергетике это нормальное решение, хотя появилось относительно недавно. Думаю что и в модульной теплоэнергетике это возможно. Далее, ставим локальный сервер сбора данных. Далее - одно-два локальных операторских АРМа плюс удалённый АРМ, который отличается от локального только линией связи. Функционал удалённых АРМов иногда уменьшен (по сравнению с локальными) в силу ограничения пропускной способности линии связи. Управление (посыл команд локальным АСУ агрегатов) - только с локальных АРМов. С удалённых АРМов - только мониторинг и сбор статистических данных для экономических отчетов. На практике же, часто ставят физически один ПК, который есть одновременно и сервер и операторский АРМ, а удалённый АРМ уже к нему стучится.

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

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

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


Автор темы
Evgeny
здесь недавно
здесь недавно
Сообщения: 44
Зарегистрирован: 22 фев 2010, 19:25
Ф.И.О.: Черкасский Евгений Валерьевич

Re: Разработка концепции АСУ ТП

Сообщение Evgeny » 22 фев 2010, 23:20

На самом деле всё так и есть, как Вы описали: сами котлоагрегаты управляются своей локальной автоматикой. Т.е. есть общекотельный щит, координирующий работу обоих агрегатов и щиты автоматики каждого котлоагрегата в отдельности. Ни одна жизненно важная функция управления не доверена программе, крутящейся на удаленном сервере - только в локальных контроллерах.
Речь идет именно об удаленном диспетчировании, что включает в себя передачу аварийной сигнализации (алармов), значений контролируемых параметров, для которых назначены уставки (и которые может менять удаленно оператор), ну и некоторые функции телеуправления. В ТЗ еще по этому поводу красуется требование "работа котельной в автоматическом режиме без постоянного присутствия персонала с выводом сигнала о неисправности в диспетчерскую".
Когда я разговаривал непосредственно с изготовителями этих котельных (через которых собственно и получил ТЗ на верхний уровень), то по поводу локальных АРМов они сказали, что установка рабочих станций (ПК) в самом производственном помещении котельной вообще-то запрещена (сослались на правила безопасности, если честно, точню не помню какие именно). Хотя получается противоречие, потому что по ТЗ идет ссылка на популярный документ Транснефти РД 153-39.4-087-01 АВТОМАТИЗАЦИЯ И ТЕЛЕМЕХАНИЗАЦИЯ МАГИСТРАЛЬНЫХ НЕФТЕПРОВОДОВ. ОСНОВНЫЕ ПОЛОЖЕНИЯ (поскольку сама котельная предназначена для отопления месторождения), согласно которому нужны и локальные, и удаленные станции. Отсюда собственно и родилась идея о двух концепциях: локальной и распределенной.
А с какой стороны ставить сервер сбора сигналов (просто промышленный ПК без панели управления), если не предусмотрен (или как мне сказали не допустим) локальный АРМ, принципиального значения, наверное, не имеет (ну если только с точки зрения потери линии связи, которая в проекте резервируется по GSM-каналу).

Аватара пользователя

TEB
специалист по DEIF
специалист по DEIF
Сообщения: 7909
Зарегистрирован: 17 июн 2008, 15:01
Ф.И.О.: Евгений свет Брониславович
Благодарил (а): 38 раз
Поблагодарили: 66 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение TEB » 23 фев 2010, 10:47

А... Теперь я Вас понял.

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

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

Кстати, в качестве GSM-канала что применяете?
По вопросам работы Форума можно обратиться ко мне, или по этим контактам.


Автор темы
Evgeny
здесь недавно
здесь недавно
Сообщения: 44
Зарегистрирован: 22 фев 2010, 19:25
Ф.И.О.: Черкасский Евгений Валерьевич

Re: Разработка концепции АСУ ТП

Сообщение Evgeny » 23 фев 2010, 11:56

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

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

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

GSM/GPRS-канал построен на двух IP-шлюзах OnCell G3110 фирмы MOXA (аппаратная версия 2, к которой можно подцеплять не только удаленные RS-232, но и сегменты Ethernet). Хабы и другое коммуникационное оборудование (кроме VDSL-модемов) также используется этой фирмы. Выбор обусловлен соответствием опросному листу Заказчика и тем, что я хорошо знаком с этим оборудованием, тк работаю в их тех.поддержке :)

Аватара пользователя

Никита
почётный участник форума
почётный участник форума
Сообщения: 2500
Зарегистрирован: 20 янв 2010, 22:23
Ф.И.О.: Никита
Откуда: Мурманск
Благодарил (а): 3 раза
Поблагодарили: 13 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение Никита » 23 фев 2010, 12:32

Внесу свои пять копеек в дискуссию. Что касается оформления - делал подобные вещи много раз, документ назывался обычно "технико-коммерческое предложение". Рассматривается два-пять варианта построения системы (зависит от того, что делаем, на крупных объектах частенько при автоматизации электроприводов рассматривался вариант модернизации главных цепей агрегатов, это уже не Ваша тематика). Приводятся структурные схемы по каждому варианту, причем часто не по ГОСТам а веселые картинки из Visio или Worda. Далее кратко на пару листов описание каждого варианта - что делаем, что получают, плюсы и минусы, можно прикидки по окупаемости. Далее таблицы ориентировочной стоимости по каждому этапу для каждого варианта (ПИР, оборудование, СМР, ПНР, опытная) и итоговая таблица - столько-то денег для каждого варианта.
В Вашем случае можно кроме структуры, немного поиграть с самой SCADA типа "дорогая система разработки-дешевые модули рантайма-неограниченная взможность расширения" и наоборот. Кстати, не забывате про перспективы расширения и модернизации)
Дадите данные по источникам тепла - можно будет говорить о структуре построения системы.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "


Автор темы
Evgeny
здесь недавно
здесь недавно
Сообщения: 44
Зарегистрирован: 22 фев 2010, 19:25
Ф.И.О.: Черкасский Евгений Валерьевич

Re: Разработка концепции АСУ ТП

Сообщение Evgeny » 23 фев 2010, 13:00

Приводятся структурные схемы по каждому варианту, причем часто не по ГОСТам а веселые картинки из Visio или Worda.

Ну я чтобы хотя бы иметь право ссылаться на какую-то нотацию делал структурную схему КТС в UML -как диаграмму развертывания (обычные прямоугольники, точнее параллелепипеды, только что называется всё это deployment diagram).
Далее кратко на пару листов описание каждого варианта - что делаем, что получают, плюсы и минусы, можно прикидки по окупаемости. Далее таблицы ориентировочной стоимости по каждому этапу для каждого варианта (ПИР, оборудование, СМР, ПНР, опытная) и итоговая таблица - столько-то денег для каждого варианта.

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

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

Аватара пользователя

TEB
специалист по DEIF
специалист по DEIF
Сообщения: 7909
Зарегистрирован: 17 июн 2008, 15:01
Ф.И.О.: Евгений свет Брониславович
Благодарил (а): 38 раз
Поблагодарили: 66 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение TEB » 23 фев 2010, 13:38

Evgeny писал(а):
Кстати, в качестве GSM-канала что применяете?

GSM/GPRS-канал построен на двух IP-шлюзах OnCell G3110 фирмы MOXA (аппаратная версия 2, к которой можно подцеплять не только удаленные RS-232, но и сегменты Ethernet). Хабы и другое коммуникационное оборудование (кроме VDSL-модемов) также используется этой фирмы. Выбор обусловлен соответствием опросному листу Заказчика и тем, что я хорошо знаком с этим оборудованием, тк работаю в их тех.поддержке :)

Понятно. А мы используем NetBitter. Кстати, вот Вам тогда наша идея построения сети и ВУ: Ставим NetBitter (в отличие от OnCell G3110 он имеет еще порты RS-485-ModBUS и выполняет роль промежуточного OPC). Все модули станции охвачены линией RS-485 ModBUS, один модуль - один адрес. Мастером является NetBitter. Дальше к Netbitter по Ethernet подключен сервер (он же локальный АРМ). Удалённый АРМ подключается к серверу также по Ethernet. Резервный канал связи - GSM напрямую с NetBitter, то есть резервный канал не зависит от сервера. Если вылетит ещё и сервер, то удалённый АРМ лишится статистических данных, которые лежат на сервере, но данные о текущей работе объекта будут по прежнему доступны. За счёт такой организации в каждом модуле не требуется установка контроллеров с поддержкой Ethernet, а ModBUS есть в любом контроллере, следовательно удешевляется нижний уровень. Но увеличивается время опроса модулей (хотя нашем случае это вовсе не критично).
По вопросам работы Форума можно обратиться ко мне, или по этим контактам.

Аватара пользователя

Никита
почётный участник форума
почётный участник форума
Сообщения: 2500
Зарегистрирован: 20 янв 2010, 22:23
Ф.И.О.: Никита
Откуда: Мурманск
Благодарил (а): 3 раза
Поблагодарили: 13 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение Никита » 23 фев 2010, 15:14

Ну я чтобы хотя бы иметь право ссылаться на какую-то нотацию делал структурную схему КТС в UML -как диаграмму развертывания (обычные прямоугольники, точнее параллелепипеды, только что называется всё это deployment diagram).

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

Затраты на проект, оборудование, монтаж и ПНР можно прикинуть по Госстроевским ценникам. Кстати, в мою бытность студентом нам о их существовании даже не упоминали, а, как потом выяснилось, очень зря. Эксплуатационные расходы самой SCADA-системы - это ЗИП, аренда каналов связи, затраты на содержание обслуживающего инженера, расходы на его поездки по объектам - тут и вылезет связь со структурой - что дешевле - выезжать на объект или искать в тайге обрыв линии.
Вообще, речь идет о том, чтобы разными способами достичь одного и того же результата, поэтому предлагаю ограничиться капзатратами на ввод разных вариантов системы в эксплуатацию. Превратив же их в амортизацию - можем считать эксплуатационные, это как больше нравится, суть одна - свести все в таблицу с затратами и ей ограничиться, не зная тепломеханики выгоды от АСУ Вы не посчитаете, а от диспетчеризации в чистом виде - тем более.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "

Аватара пользователя

Никита
почётный участник форума
почётный участник форума
Сообщения: 2500
Зарегистрирован: 20 янв 2010, 22:23
Ф.И.О.: Никита
Откуда: Мурманск
Благодарил (а): 3 раза
Поблагодарили: 13 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение Никита » 27 фев 2010, 23:55

Речь и идет о концепции, при этом о концепции оторванной от жизни скады для дипломного проекта. Рассматривать существующие на рынке SCADA-системы и делать их оценку? Немного неверный подход, как мне кажется. В конце концов выяснится что лучше всего панель оператора без всякой связи с внешним миром. Никто ж не задается вопросами стыковки с оборудованием, увязки с другими системами и пр. Вообще по соотношению цена-качество лучше всего халявное пиво, но речь не об этом. Задача сама по себе поставлена некорректно, не зная ничего о АСУТП разработать, точнее сделать вид что разработана, концепцию веселых картинок. А так как подобная задача по определению имеет множество решений - вот и приходится просто красиво лить воду, причем каждый по своему.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "

Аватара пользователя

Никита
почётный участник форума
почётный участник форума
Сообщения: 2500
Зарегистрирован: 20 янв 2010, 22:23
Ф.И.О.: Никита
Откуда: Мурманск
Благодарил (а): 3 раза
Поблагодарили: 13 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение Никита » 28 фев 2010, 00:11

Думаю грустнее если первое. Вряд-ли человек по собственной инициативе будет писать такие вещи просто так... А вот если больше писать не о чем и нужна просто макулатура для диплома - тогда действительно грустно. А задание преподавателя скорей всего звучало как создание АСУТП, только сил у дипломника на полноценную систему не хватит, вот и размазывают реальный объем по ГОСТу чтоб солидно было.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "


Автор темы
Evgeny
здесь недавно
здесь недавно
Сообщения: 44
Зарегистрирован: 22 фев 2010, 19:25
Ф.И.О.: Черкасский Евгений Валерьевич

Re: Разработка концепции АСУ ТП

Сообщение Evgeny » 07 мар 2010, 20:39

Доброго времени суток и спасибо всем отозвавшимся за внимание к моему вопросу и дискуссии :-)
"В споре рождается истина". Вот и у нас в разговоре с преподом по тому, что я сделал во многом благодаря идеям genelectric , родилось какое-то ясное представление о том, как будет выглядеть концепция в моём случае. На данный день в моей работе сравниваются между собой варианты, имеющие абсолютно равные права на жизнь: с локальной и удаленной диспетчеризацией. Уверенность в правильности такого подхода подкрепила статья на сайте Московского Завода Тепловой Автоматики (статья). Я сделал прикидочную оценку по капитальным затратам. Препод в свою очередь выдал "обнаученную" (специально для профессорско-преподавательской аудитории) методику комплексного сравнения SCADA-систем: что-то типа матрицы, в итоге расчета получаются относительные оценки каждой системы, учитывающие как экономические, так и технические группы факторов (после защиты диплома обязательно поделюсь ею). :) Вдруг кому-то еще понадобится в академических целях... Что поделать, если так уж у нас повелось сравнивать между собой SCADA-системы, пусть даже в основном и в чисто рекламных целях.

Дмитрий Милосердов писал(а):Хм..интересно - это собственные инициативы или задание преподавателя? Если последнее- то весьма грустно...

Никита писал(а):Думаю грустнее если первое.

К слову о дипломе: ТЗ для него взято из реальной жизни, ничего не высосано из пальца (во-первых, Бауманка бы такого не потерпела, во-вторых, я сам мечтал делать диплом по конкретному ТЗ на АСУ ТП, а не автоматизации "вообще"). Проект привязан к реальному объекту, хотя в настоящее время работа приостановлена, т.к. Заказчик пока не профинансировал следующий этап. Поэтому речь о том, станет ли мой проект макулаторой или нет, вести рано - да и кстати я ведь и не просил беспокоиться за это, уважаемые форумчане и коллеги . Так что нечего грустить - выше нос! :ext_dont_ment:

Дмитрий Милосердов писал(а):Только вот в профиле Ниеншанц прописано. А вот это действительно грустна

Да, там действительно прописано именно это. И мне вот наоборот очень приятно. Ниеншанц-Автоматика - стабильная и солидная фирма со своими плюсами и минусами (для меня лично на данный момент больше плюсов). И пусть она и не является системным интегратором и поставщиком решений "под ключ", тем не менее действует далеко не только по принципу "купи-продай". Только я, предвидя возможное развитие дискуссии по этой теме, очень прошу - не надо фанатизма. У всех свои причины для симпатий и антипатий. 8-)
Последний раз редактировалось Evgeny 07 мар 2010, 22:31, всего редактировалось 1 раз.

Аватара пользователя

Никита
почётный участник форума
почётный участник форума
Сообщения: 2500
Зарегистрирован: 20 янв 2010, 22:23
Ф.И.О.: Никита
Откуда: Мурманск
Благодарил (а): 3 раза
Поблагодарили: 13 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение Никита » 07 мар 2010, 21:35

К слову о дипломе: ТЗ для него взято из реальной жизни, ничего не высосано из пальца (во-первых, Бауманка бы такого не потерпела, во-вторых, я сам мечтал делать диплом по конкретному ТЗ на АСУ ТП, а не автоматизации "вообще"). Проект привязан к реальному объекту, хотя в настоящее время работа приостановлена, т.к. Заказчик пока не профинансировал следующий этап. Поэтому речь о том, станет ли мой проект мукулаторой или нет, вести рано - да и кстати я ведь и не просил беспокоиться за это, уважаемые форумчане и коллеги . Так что нечего грустить - выше нос!


Дело-то не в макулатуре, дело в том что получим в результате. Evgeny, прошу прощения, но мы ударились в обсуждение качества работы ВУЗов по подготовке специалистов, рассматривая дипломников(и Вас в том числе) как продукцию. Ниеншанц тут вообще ни при чем, речь о том, что студент с опытом, пусть и в продажах, вместо нормальной работы по автоматизации занимается написанием реферата по SCADA-системам, практически не имея представления об объекте. Лично для меня, как работодателя, программист, умеющий лишь нарисовать мнемосхемы, особой ценности не представляет, главное в управлении -алгоритмы, а визуализация - дело десятое.
Автоматика, оторванная от технологии, сама по себе не имеет смысла, а в Вашем случае от нее еще оторвано поле и ПЛК, тем самым задача превращена в чисто теоретическую. А стране нужны созидатели)
Это так, мысли вслух с высоты. С другой стороны как вспомню какую ... сами писали в дипломных работах - так за десять лет ничего не изменилось.
Так что дерзайте, будут вопросы - пишите, а если есть желание в дальнейшем что-то делать а не продавать незнамо что - надо просто интересоваться тем что делаешь.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "


Автор темы
Evgeny
здесь недавно
здесь недавно
Сообщения: 44
Зарегистрирован: 22 фев 2010, 19:25
Ф.И.О.: Черкасский Евгений Валерьевич

Re: Разработка концепции АСУ ТП

Сообщение Evgeny » 07 мар 2010, 22:08

Никита писал(а):Дело-то не в макулатуре, дело в том что получим в результате. Evgeny, прошу прощения, но мы ударились в обсуждение качества работы ВУЗов по подготовке специалистов, рассматривая дипломников(и Вас в том числе) как продукцию. Ниеншанц тут вообще ни при чем, речь о том, что студент с опытом, пусть и в продажах, вместо нормальной работы по автоматизации занимается написанием реферата по SCADA-системам, практически не имея представления об объекте. Лично для меня, как работодателя, программист, умеющий лишь нарисовать мнемосхемы, особой ценности не представляет, главное в управлении -алгоритмы, а визуализация - дело десятое.

Во-первых, я работаю в отделе технической поддержки и не имею никакого отношения к продажам, разве что после подбора оборудования направляю заявку манагерам. Во-вторых, всё-таки за годы пребывания в университете у нас было несколько курсов, посвященных именно АСУ ТП, хоть может быть и не в том объеме, в каком хотелось бы. Но во всяком случае я слышал такую фразу, что "настоящего инженера растят около 10 лет" - это без учёта лет, проведенных в стенах ВУЗа... Так что буду расти благодаря работе, взаимодействию с Заказчиками ну и подобным форумам :) Ну а насчет того, что получится в результате диплома - хорошо, если это будет хотя бы какой-то навык, обобщение изученных ГОСТов, курсов, и т.п. - по-моему этого было бы вполне достаточно.


T_Vlad
освоился
освоился
Сообщения: 247
Зарегистрирован: 05 мар 2010, 15:01
Ф.И.О.: Тихомиров Владимир Владимирович
Поблагодарили: 1 раз

Re: Разработка концепции АСУ ТП

Сообщение T_Vlad » 11 мар 2010, 11:20

Никита писал(а):
Дело-то не в макулатуре, дело в том что получим в результате.


Как раз сейчас у мены дипломник (выпуск в июне). Тему ему дал абсолютно реальную и имеющую перспективы развития. "Оптимизация структуры диспетчерского контроля и управления цеха". Поставил ему компьютер с полным программным пакетом системы, с инженерными программами. На компе реальный пользовательский интерфейс и база данных цеха. Поставил стенд (он у меня давно собран, отрабатываю на нём реальные проблемы), с резервированным контроллером и модулями ввода/вывода аналоговыми и дискретными. То есть реальная живая схема. Рядом инженерная станция, постоянно в системе (точнее на ней 3 виртуальных машины и 3 отдельные системы).
Далее - основные понятия и определения, классификация - книги, госты, СНиПы.
- структура цеха (технология и задачи) - технологические схемы и инструкции технологического персонала.
- постановка задачи (автоматизация процесса и цеха, в целом. Оптимизация структуры КПТС) - Исходное предложение по автоматизации, технические задания, пояснительные записки проектов.
- структура АСУ цеха на КПТС TOSDIC - Тошибовские мануалы и предложенные структуры. Реально созданная многоуровневая схема, с коммуникаторами и виланами.
- собственно оптимизация (права доступа, интерфейс, изменение интерфейса под структуру, структуризация баз данных)
Здесь уже работа с реальной базой. Инжиниринг контроллера, инжиниринг операторского интерфейса, графический редактор. В дипломе реальные скрины интерфейса, редакторов, программ - в сравнении.
- и последняя тема (основного раздела) построение системы с учётом перспективного плана автоматизации. Есть общая концепция завода, есть общий план, есть ограничения на любой КПТС.

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

Раздел БЖД и экологии пусть пишет сам, хоть я и проверю.

Аватара пользователя

Никита
почётный участник форума
почётный участник форума
Сообщения: 2500
Зарегистрирован: 20 янв 2010, 22:23
Ф.И.О.: Никита
Откуда: Мурманск
Благодарил (а): 3 раза
Поблагодарили: 13 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение Никита » 11 мар 2010, 11:45

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

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


T_Vlad
освоился
освоился
Сообщения: 247
Зарегистрирован: 05 мар 2010, 15:01
Ф.И.О.: Тихомиров Владимир Владимирович
Поблагодарили: 1 раз

Re: Разработка концепции АСУ ТП

Сообщение T_Vlad » 11 мар 2010, 13:17

Дмитрий Милосердов писал(а):Владимир, вопрос не в тему- а у вас в Киришах только диспетчеризация реализована или другой функционал уже создали? ( если мне память не изменяет- у вас зачатки MES на базе PI были?). Если есть реализация- то каких функций? (по терминам ИСА S-95 лучше, чтобы не путаться).

Не так однозначно.
Во первых у нас 2 отдела (общее только сети) АСУП и АСУТП.
У АСУПа все офисные компы, в единой общезаводской сети. Управленческую часть я не знаю.
Есть там и отдельная система учёта и отчетности по пром цехам. Проект фирма "Наука" с их программным пакетом. Там собирается вся товарная информация и наработка оборудования. Я, для этого, в "своей" системе организую счётчики и программы НКО.
В этой же системе есть отдельные подсистемы учёта оборудования (программные АРМы), лично я пишу туда все обслуживания, перемещение ЗИП, записываю (по номерам до элемента) вновь поступающее оборудование, все текущие ремонты, необходимые заявки. Это программный пакет СПИК СЗМА.
В эту же структуру (через своё оборудование и ком сервера) заведена система вибромониторинга всего завода. Система фирмы АЛТ.
Руководство (и КИПовцы) имеют на своих компах полную (в реальном времени) картинку (реальные видеокадры) подконтрольных объектов. Этим занимается наш сектор IT. У них огромная сеть COM серверов с единым SQL сервером, аппаратными фаерволами. Информация вытаскивается из технологической сети, пакуется и передаётся интачем в обще заводскую сеть, а там уже кому что нужно. В "моей" системе, для связи с интачем стоит программа OPC.DA.

Более конкретно по MES:
- контроль состояния и распределения ресурсов - уже написал
- оперативное распределение - как сказал, у руководства есть реальная картинка, в реальном времени. У операторов и диспетчеров есть информация (на видеокадрах) своя и по смежникам.
- диспетчеризация - диспетчерские АРМы находятся непосредственно в системе (в управляющей сети). Видят все видеокадры системы, только им закрыто управление оборудованием.
- контроль за документами - в общей системе завода общий документооборот, с различными правами доступа, вплоть до электронных подписей. (один из примеров - выше, то, что от СПИК СЗМА и система товарного учёта "Науки")
- сбор и хранение данных. У меня, в каждой системе (их пока 3), по 10-20 операторских станций (объекты разбросаны на площади 25км.кв) и по 20-30 контроллеров. Естественно стоят выделенные сервера. Кроме того есть сервер SQL (о котором уже писал), там вообще собирается инфа по всему заводу (технологическая инфа). Что на серверах АСУП, сказать не могу.
- управление персоналом и качеством - это к АСУПу
- управление, история, анализ - на разных уровнях своё.

Есть ещё момент применения моделей. На отдельных установках внедрены адаптирующие программные модели. То есть технологическая система самообучается и адаптируется. (что то типа "терминатора")

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


T_Vlad
освоился
освоился
Сообщения: 247
Зарегистрирован: 05 мар 2010, 15:01
Ф.И.О.: Тихомиров Владимир Владимирович
Поблагодарили: 1 раз

Re: Разработка концепции АСУ ТП

Сообщение T_Vlad » 11 мар 2010, 13:26

Никита писал(а):Книг в институтах много, только вот большинство студентов уже и не подозревают о существовании библиотек,

Увы и ах. Книг много, но толку мало.
Пытались меня привлечь учить студентов (филиал института) по теме АСУ, в этом полугодии (с намёком, что соглашусь и в будущем). 8 часов в неделю, по вечерам, по 200р. за час. Честно говоря оно мне нафиг (за такие деньги) было не нужно, но уж очень просили, к тому же через наш отдел подготовки кадров. Сначала согласился (предварительное согласие) потом посмотрел программу и отказался. У них предмет АСУ с точки зрения технологии (там технологов учат). По моей работе ни чего нет.
К чему это, а к тому, что поискал в инете литературу. Ни одного хорошего нового учебника. Всё 80-90х годов. Сейчас техника принципиально другая.

Ещё момент - через чур большие объёмы информации. У меня мануалов (на TOSDIC) более 10000 страниц, на английском (переведено с японского). Постоянно идут изменения, доработки, особенно по программным пакетам. Если ещё учесть мануалы (опять же на английском) на внешнее оборудование - вообще!!!
Нет сейчас универсальных профи. Настоящие профи только в своей теме.
Последний раз редактировалось T_Vlad 11 мар 2010, 13:33, всего редактировалось 1 раз.

Аватара пользователя

Никита
почётный участник форума
почётный участник форума
Сообщения: 2500
Зарегистрирован: 20 янв 2010, 22:23
Ф.И.О.: Никита
Откуда: Мурманск
Благодарил (а): 3 раза
Поблагодарили: 13 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение Никита » 11 мар 2010, 17:19

Нет сейчас универсальных профи. Настоящие профи только в своей теме.

Это как раз не проблема, это естественно. Много лет занимаясь темой становишься в ней профи.
Проблема в том, что очень большой разрыв между академическими знаниями и способностью самостоятельно работать. Уже после первого сданного объекта и освоенной техники остальное идет намного легче, техники-то хоть и множество на рынке, но она вся похожа. Есть у каждой своя специфика и подводные камни, но молодой специалист часто не может работать вообще ни с чем.
Главная беда - не умеют пользоваться знаниями, даже если они есть. Больше половины из тех, с кем беседовал, не могут, зная напор и расход, прикинуть мощность насоса, хотя эта задача из школьного курса физики для, по-моему, восьмого класса. Про то, чтобы взглянув на объект составить хотя бы представление о передаточной, я вообще молчу.
А техника - дело десятое, толковый инженер со временем с любой разберется.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "


T_Vlad
освоился
освоился
Сообщения: 247
Зарегистрирован: 05 мар 2010, 15:01
Ф.И.О.: Тихомиров Владимир Владимирович
Поблагодарили: 1 раз

Re: Разработка концепции АСУ ТП

Сообщение T_Vlad » 11 мар 2010, 18:36

Никита писал(а):Главная беда - не умеют пользоваться знаниями, даже если они есть.


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

Аватара пользователя

Никита
почётный участник форума
почётный участник форума
Сообщения: 2500
Зарегистрирован: 20 янв 2010, 22:23
Ф.И.О.: Никита
Откуда: Мурманск
Благодарил (а): 3 раза
Поблагодарили: 13 раз
Контактная информация:

Re: Разработка концепции АСУ ТП

Сообщение Никита » 11 мар 2010, 19:01

Во первых знаний нет, даже базовых.

Я не зря взял пример с насосами, эти знания есть - те с кем общался еще сдавали вступительный по физике, а не ЕГЭ. И раз сдали - значит есть. Можно не помнить формулы, для этого есть справочники, но то что такие законы в физике есть - знают точно.
Другой вопрос - преподаватели - объясняя на лекции какую-то формулу хороший лектор всегда найдет жизненный и понятный пример и приведет еще три-четыре подобных. А плохой - заставит выучить наизусть.
Те,кто не отличает диод от транзистора - это рас...и, которым плевать на все чему учат, просто нет интереса, нужен только диплом. Ну они до меня просто не доходили.
Мне на всю жизнь вдолблено - "Инженер должен уметь пользоваться технической документацией"

Мой преподаватель по сопромату (науке самой по себе гнусной) по этому поводу говорил так - "хороший инженер - это не тот кто много знает, а тот кто за двадцать минут найдет необходимую информацию". При этом разрешал при сдаче пользоваться всем, но задачки подкидывал такие что действительно приходилось разбираться сначала с самой конструкцией, зато потом после ее раскладки на элементы, все в пару эпюр и десяток формул решалось на раз.
А насчет техники - не так давно общался с зам. зав. выпустившей меня кафедры, в т.ч. и на предмет "чему людей учите?" Очень неприятно был удивлен - за последние восемь лет в плане оборудования ничего не изменилось. Пожаловался на то что ГОД лежит подаренный спонсорами S7-200 и никто до сих пор не может разобраться как им пользоваться. При том что уж по сименсу-то русскоязычной документации прорва, даже книги есть. Даже желания помочь не возникло.
Людей не то что не учат учиться, даже просто думать - и то не умеют.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "


Вернуться в «Общие вопросы»



Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость