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

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

Потенциальный исполнитель не прав или я чего-то не понимаю?

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

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

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



"Нельзя автоматизировать беспорядок"

to park_er
Разработчики АСУ ТП АБСОЛЮТНО ПРАВЫ !!! Выбор датчиков (точность, диапазон, место расположение) ОДНОЗНАЧНО определяются техпроцессом.
Разработчикам АСУ это ГЛУБОКО до фонаря, ибо их задача - автоматизировать процесс согласно ТЕХНОЛОГИЧЕСКОЙ карте (в АВОК - это Пояснительная записка), отобразить на экранах список ПАРАМЕТРОВ, согласованных с Заказчиком и предоставить возможность ИЗМЕНЯТЬ так же СОГЛАСОВАННЫЙ список. Вопросом СОГЛАСОВАНИЯ может быть тип выходного сигнала датчиков, расположение трасс кабелей (во избежание наводок и обеспечения нагрузочных характеристик входов/выходов контроллеров).
"Кулибинский подход" к автоматизации (это когда разработчики АСУ ТП лезут в техпроцесс) чреват непредсказуемыми последствиями как при сдаче, так и при эксплуатации ("крайнего" не найдешь ). Конечно, неплохо было бы, чтобы разработчики АСУ имели хотя бы поверхностное представление о техпроцессе перед началом работы, но это совсем необязательно, т.к. при разработке и пуско-наладке они его и так приобретут.
За все проколы в ТЕХНОЛОГИИ должны отвечать ТЕХНОЛОГИ, а не те, кто автоматизировал их детище.

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

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

to den.mgn
Если Вы НАСТРАИВАЕТЕ регуляторы,да еще и "с учетом технологии" то ВЫ, простите за откровенность, ДИЛЕТАНТ в автоматизации
Я много работал в сфере АСУ ТП, автоматизировал МНОЖЕСТВО техпроцессов в разных областях промышленности (в АВОК пришел 5 лет назад), но "настраивал" регуляторы только на заре своей деятельности, т.к. они на то и регуляторы, чтобы быть САМОНАСТРАИВЫМИ. Лично мне ГЛУБОКО наплевать, ЧТО я автоматизирую - меня интересует лишь ПОСЛЕДОВАТЕЛЬНОСТЬ действий и границы допустимых значений параметров.
Если мне говорят, что температура приточного воздуха д.б. в таком-то диапазоне, то я смотрю на ПАСПОРТ датчика температуры (должны предоставить ) и паспорт ИСПОЛНИТЕЛЬНОГО механизма (привода клапана). Моих знаний в физике и математике вполне хватает, чтобы прикинуть тип физпроцесса и выбрать подходящий регулятор из ОБШИРНОГО набора, имеющегося у меня, как у ПРОФЕССИОНАЛА. И все...
Далее - это мои "ноу-хау", технология мне БЕЗРАЗЛИЧНА. Если задача не может быть выполнена, я готов обосновать свою НЕПРИЧАСТНОСТЬ.
Опять же, ПОВЕРХНОСТНОЕ знание технологии не помешает, но именно с прикладной точки зрения.

Очень глубокомысленное замечание…

Именно так, если автоматизация - это ПРОФЕССИЯ, которая кормит. Если я КАЖДЫЙ раз буду задумываться о техпроцессе и искать там "философское начало", буду приставать с вечными детскими "почему" к занятым людям, ни в какие сроки не уложусь и останусь без денежки...

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

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

Мое мнеине такое: если они делают АСУ, то исходя из оборудования описанного в ТЗ они должны дать ТИП датчиков (pt, NTC и т.д.), а их исполнение, точность и месторасположение определяют уже непосредственно те, кто проектирует конкретные узлы автоматики (отопление, вентиляция, и пр.). АСУШНИКИ правы по-моему - им сигналы нужны, а откуда они пойдут и каким датчиком по исполнению передаются - пофиг.
Примерно так.

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

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

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

Такой подход был распространен в 80-е годы прошлого века, когда АСУ внедрялось директивами партии и правительства..
(Отделы АСУ на всех предприятиях, все крутые - только вот к производству их боялись подпускать, что бы потом косяки не расхлебывать)
Мне например запомнился пример который нам приводили в институте -
Когда в Московском метро разрабатывалась система автоведения, то задачу поручили институту кибернетики АН СССР, только результата конкретного не получили. Тогда решили взять спецов-железнодорожников, обучить их основам автоматизации и программирования, и ребята справились, несмотря но то что уступали глубиной знаний академикам. Но они владели всей спецификой задачи. Не всякий технолог может грамотно составить ТЗ, потому что много вопросов кажуться для него настолько очевидными, что вряд ли он заострит на них внимание

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

Вот именно АВТОМАТИЗАЦИИ!!!
А сейчас опять полезло везде АСУТП (я лично к этому термину отвращение испытываю с советских времен), причем многие в это понятие вкладывает только свое (поменьше сделать, побольше получить и ни за что не отвечать).
Пусть регуляторы технологи настраивают - не царское дело. Датчики с кабелями - за кого вы нас принимаете. Мы ведь креатив создаем.

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

Простой пример - выбор датчиков температуры приточного воздуха. В какой точке воздуховода измерять температуру, диапазон ВОЗМОЖНЫХ значений измеряемой величины, точность измерения в определенных диапазонах, требования по герметичности ввода в воздуховод, методики поверки и опыт работы Заказчика с определенными марками, наличие ЗИП и т.д. Разве это забота тех, кто будет делать АСУ ? Конечно - НЕТ!!!
Паспорт на датчик и что делать с измеренной величиной - вот и все, что требуется. Если датчик не позволяет что-то сделать - причем тут АСУшники? Что он КОНКРЕТНО меряет - температуру в центре потока, на краю или еще к какой-то точке - какое дело до этого АСУшникам?
to Pzotov
Кого Вы насмотрелись - не знаю, а вот про метро - это типичная "байка". Автоматика - это НАУКА, нельзя машиниста метрополитена обучить основам машиностроения (хотя даже корни похожи) и он построит электровоз, т.к. именно он знаком с ньюансами его эксплуатации в метро.
Инженерам по автоматизации зданий не обязательно быть технологами, т.е. уметь рассчитывать воздуховоды, теплообменников, знать "назубок" СНиПы и прочие тонкости жизнеобеспечения зданий! Мне пофиг метода выбора трехходового клапана, привода к нему, выбора его местоположения. Мне надо только знать, в какую сторону его крутить, чтобы увеличилась температура приточного воздуха.
А разработчику обвязки калорифера по-фигу, как я буду реализовывать алгоритм поддержания температуры приточного воздуха.
Каждый должен заниматься своим делом ! Технолог ДОЛЖЕН сотрудничать с АВТОМАТЧИКАМИ, это- факт !. Но для АСУшника ТЕХНОЛОГИЯ - это КОНСТАНТА, это АКСИОМА!

ggg__ggg респект Вам и уважение как программисту. Я просто почитал Ваши предыдущие сообщения. Я готов признать, что многое из того что Вы знаете мне не хватает как автоматчику.
Автоматизация давно переросла свои рамки и сейчас кроме аппаратной части контроллеров захватывает 90% КИП и 30% программирования. Хорошо когда специалист знает автоматизацию с верху донизу но, к сожалению, не многие могут этим похвастаться.

Ваш скепсис на счет места установки датчика считаю неуместным: именно расстояние от калорифера и тип датчика влияет на время транспортного запаздывания, способ установки – на точность измерения. В принципе, это все есть в «теории управления» и «технологических измерениях». Ведь автоматизация не заканчивается на ИТП, приточных установках и умном доме, существуют еще и каскадное регулирование и мат. моделирование. Возможно, Вы даже правите откомпилированную программу на TAC-Xenta, за что Вам мои поздравления. Но делать автоматизацию не понимая зачем меня, честно говоря, не устраивает. Я на этом форуме для того, чтобы изучать опыт других, а не ссорится. Поэтому давайте останемся при своих мнениях об автоматизации.

Да я ни с кем и не спорю и тем более, НЕ ССОРЮСЬ, именно поэтому часто добавляю аббревиатуру ИМХО . Тема топика весьма актуальна и автору, наверно, было бы интересно узнать РАЗНЫЕ мнения. Вот я и высказываю СВОЕ мнение.

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

Не пугайте нас, такого не бывает.

to Михаил_PLC
Присоединяясь к мнению г. vladun, хочу добавить: Не только не бывает, а просто НЕВОЗМОЖНО! Есть специальность, должность - "технолог ..... производства", но "технолог, инженер-программист, инженер-электроник, монтажник, инженер КИПиА .... производства" - это как-то сложно себе представить. "Поверхностное знакомство с предметом" - это когда человек ПРЕДСТАВЛЯЕТ, о чем идет речь, а "раэбираться в тонкостях" - значит, владеть чем-то ПРОФЕССИОНАЛЬНО. Это-ж сколько надо учиться и сколько надо платить такому специалисту?
Я, например, считаю, что "пироги должен печь пирожник, а сапоги тачать сапожник". АСУ - это совместное детище автоматчиков, проектировщиков или технологов, КИПовцев (если оные имеются). И каждый должен быть профессионалом в своем деле !!!

Хочу привести пример. Котельная закупила в дании 2 водяных котла по 7.5 MW, работающие на торфе или опилках и автоматическую систему подачи топлива к ним. Всю работу выполнили под ключ сами датчане. Год был 1995, всёй системой управляло 4 контроллера Allen-Bradley SLC5/03 + SCADA.
Так вот программу для управления котлами писал "настоящий" программист. Все пере плевались, и потом почти все алгоритмы пришлось переписывать. Я понимаю, что ему дали задание, как это должно работать, и он это всё тупо повторил в программе не вдаваясь в нюансы, было видно, что человек не был знаком с работой котельной. Апофеозом его работы было то, что котёл мог работать только на ручном режиме, реле звонка аварий зачастую было вытащено, и ровно через 2 года потекли оба котла, в каждом заменили по 1000 труб в экономайзере котла и всё только потому, что у программиста было неправильно реализовано управление уходящих газов.
Что я хотел сказать, так это то, что программисту нужно знать нюансы работы процесса оборудования, а если он программирует только по тех. заданию получается полная ерунда.

Согласен с qqq_qqq!

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

Что касается ситуации park_er, то ему нужно найти людей, которые проектировали железо. АСУшников и тех проектировщиков нужно сплотить в единую команду, т.е. АСУшник должен сказать, какой сигнал ему нужен, а проектировщики внесут изменения в чертежи... За нормальными контактами между двумя группами специалистов нужно регулярно следить...

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

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

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

Далее, с развитием техники, появились контроллеры, конфигурируемые контроллеры,
простые среды программирования, простые Скады....
И ими начались пользоваться технологи, которые знают процесс (узкая область - ОВК), но не "программисты".
Теперь они сами подбирают датчики и сами пишут управляющие программы.
И того, что они могут делать для ОВК более чем достаточно,
однако, с точки зрения "тру программистов" это кустарщина.

Автору:
ИМХО, найдите лучше контору, которая занимается автоматизацией и диспетчеризацией ОВК -
остальные системы они тоже смогут прикрутить. Вопросов меньше будет.
ИМХО, для общения с АСУТПшниками нужно выделять спец. человека - технолога,
который будет им "разжевывать".

P.S. При моем уважении к ggg__ggg,
общение с местными "АСУТПшниками" оставило у меня только неприятные воспоминания,
видимо специфику из работы я не понял.
Так что многие вещи субъективны и зависят от конкретных человеческих представителей
той или другой сторон.

Р.P.S. Кстати, те и другие являются конкурентами, считающими, что противники
вторгаются в "их вотчину", поэтому и спорят

Да не спорю я, наоборот, я ИСКРЕННЕ рад (как это не кощунственно звучит), что программированием контроллеров занимаются люди, прочитавшие HELP и пару мануалов, т.к. именно это и позволяет мне "жить не на одну зарплату". Да, люди УЧАТСЯ, совершают смешные (с моей точки зрения) и фатальные (с точки зрения хозяев предприятия) ошибки, тем самым обеспечивая меня и моих коллег УСТОЙЧИВЫМ заработком, причем деньги платят не торгуясь (как правило), т.к. линия должна давать продукцию, а не служить лабораторным стендом для пытливых самоучек (или недоучек).
Что касается АВОК, то эта сфера - отдельная песня, где "поют" все кому не лень. И тоже кормит, и неплохо, когда Заки и Службы эксплуатации узнают, что, оказывается, есть и другие возможности. Платят, конечно, более неохотно - но ПЛАТЯТ !!! Так что дело не возрасте, амбициях и самооценке - дело в КВАЛИФИКАЦИИ исполнителя. Согласитесь, что постоянно практикующие специалисты лучше пусть умного, образованного, но не имеющего практического опыта НЕСПЕЦИАЛИСТА, пусть и гордо заявляющего "Что нам стоит дом построить...".
Мне, например, в голову не придет критиковать проектировщика ИТП за выбор типа теплообменника - ему виднее, он - СПЕЦИАЛИСТ, но я искренне могу посмеятся над предложенным им алгоритмом контроля привода клапана на этом теплообменнике, и именно потому, что в данной области я - СПЕЦИАЛИСТ.

Я не проектировщик в большом смысле этого слова, но СМЕТЧИК. И на 100% могу согласиться со словами этого СПЕЦИАЛИСТА. Я чувствую, что на его проектах у меня как у сметчика вопросов бы не было.

ЕПТ, вот "много -ку" Вы и договорились...
поздравляю,
разделяю мнение оратора выше

to vladun
Не много q, а много g, т.к
1) это средняя клавиша на стандартной "клаве"
2)ggg_ggg -"жужжу как пчела", а "qqq_qqq" - "это куковать как кукушка, а кукушка своих гнезд не вьет". Так что, где-то несправедливо

еще и Просвятитель, однако...

Ща покраснею

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

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

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

однако вернемся к началу (с) мое

коллеги, мы малость отклонились от изначальной темы беседы - что делать в данном конкретном случае?
немного не усвоил роль топик стартера, допустим он представляет заказчика в самом широком смысле те представляет и технологов и автоматчиков...
далее по тексту - "исполнитель"... пусть меня поправят, но мне кажется что это та самая организация что ваяет проект в части АТХ
мое мнение если люди ваяют проект автоматизации - проблема найти того кто разберется как установлен датчик - это их проблема. как они ее решат так же их зубная боль в заднице. если они не хотят решать эту проблему то либо они некомпетентны (ищем внятного проектировщика) либо стоит назвать их задачу - диспетчеризация (изрядно урезав бабло) либо таки дать им внятное тз которое закроет все их вопросы.
теперь по пунктам:
>1. мы не знаем в каких условиях работают датчики;
в тз про это ничего нет?
тогда скажите им в каких условиях работают те самые треклятые железяки.сказали возникли еще вопросы в стиле "до чего бы докопаться" стоит подумать на фик нам такой проектант. в конце концов пусть еду т на объект и смотрят все конкретности что их интресуют проектировать сидя в кресле в офисе не выезжая на объект или не разговаривая с смежниками - технологи ли энергетики, конечно можно но... как бы это сказать - опрометчиво. опять таки исключение - интерфейс оператора... и то стоит показать хоть макеты экранов заказчику для согласования.
>2. это ответственность;
метко сказано - именно за это и платятся денажки
>3. установка (расположение и способ) датчиков это дело проектантов соответствующих сервисных систем;
не согласен. если мы говорим про систему автоматизации то это как раз та самая епархия. единственное что нужно согласовать места отбора для датчиковой аппаратуры... а что такое сервисная система? *почесал в голове*
>4. чтобы измерить нужный параметр возможно будет необходимо либо мерить косвенные параметры либо устанавливать несколько разнотипных датчиков.
и чо? это должно волновать заказчика? ему нужен работающий процес и если проектировщис автоматики обоснует установку хоть сотни датчиков то по флаг ему в руки все будет согласовано.
ну надо так надо (с)
тз не аксиома или догма - там в общем оговорено то что должно быть и на чем это должно быть реаливано. а конкретика она в проекте - те в той ччасти которую и должен разработать некто под названием "исполнитель"

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

в бытность мою учебы в пермском ГТУ преподаватели кафетры АТ рассказывали притчу о их участии в автоматизации хим. предприятия.
вкратце: сначала алгоритмы решили разработать сами "типа ух мы какие программисты и умные при том" где то в самом начале процесса поняли что лажанулись... начиналось все с элементарного знания всех химических формул.
тогда решили поручить разработку алгоритмов технологам... абзац.. они кончено понаписали такого на их свобственном языке что ...
решили объединить 2 группы - чисто химики + чисто программеры...
короче все было тухло ровно до тех пор пока разработчики проекта не получили элементарных знаний по тех процессу и только тогда при поддержке технологов дело пошло..

Инженер по автоматизации в закладных конструкциях точно не разбирается (по крайней мере мне такие не попадались ). Правильно подобрать место установки отборов и проконтролировать правильность монтажа он тоже не сможет. Вы ему еще запорную арматуру на отборах поручите. О киповцах : "алаверды". Проектанты -то же.
И не надо бросаться камнями я говорил о "чистых" специалистах.
Есть люди, которые в силу обстоятельств, занимаются смежными "вещами", но их мало. Скажем 20%. Поэтому доводы: я все знаю и умею- не катят.
А кому проект поручать курировать, так это к хорошему организатору (ИМХО). Часто проект курируют те у кого самая большая затратная часть.
"Автоматика - это НАУКА, нельзя машиниста метрополитена обучить основам машиностроения (хотя даже корни похожи) и он построит электровоз, т.к. именно он знаком с ньюансами его эксплуатации в метро."
Да ладно- этот расистская теория такая. Или слово "нельзя" лишнее.
Знаю несколько человек. У них второе образование по автоматизации (системщики). Завтра спрошу - где они дипломы покупали -поскольку умом эту науку постичь нельзя.

инженер по автоматизации != инженер кип?
тогда чем он занимается?

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

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


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

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

Если это нормальный инженер-тепломеханник, то скорее всего смеятся будет он (Вам например регулировочная характеристика клапана ведь по барабану..)

Полное название специальности - КИПиА (расшифровоать думаю не надо?)


Например что-бы установить расходомер, нужно выдержать определенные условия постоянных Ду, растояние до перехда диаметров, пространственное расположение, удобство подводки кабеля и много еще чего - это и есть то что должен контролировать инженер по автоматизации.
Естественно выбор типов датчиков, их место установки (механики работаюь по его указке). А то ведь отборник можно так врезать, что никакие алгоритмы не помогут понять что датчик показывает. А инерционность датчиков при выборе кто должен оценивать - технолог?

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

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

чем занимается инженер по асупт?
повторюсь я лишь в теории знаком с предприятием (в рамках нашей компании) где эти 2 должности разделены.
граница ответственности где?
если говорим о АСУ шнике кторый творит автоматизацию, то черт возьми - а кто будет думать как, где, и какие именно измерительные и системы правления разместить то? кто если не разработчик АСУПТ если уж он таким назвался
готов бросить вам перчатку (с виниловым напылением!!) в лицо но сдается мне вы как то уж больно узко и низко отзываетесь о инженерах кипиа... реалии таковы что люди этой славной по жизни професии зачастую знают и то какой "карман" под термометр лучше, и как выгоднее его врезать, и между делом приходится конфигурировать орс сервера, базы данных проектов. разносторонние такие люди.
про программиста не спорю.. если единственное что умеет чел это реализовать функцию с n входами и выходом в виде real переменной с четко обозванной задачей типа а+в=с то не спорю... знание того в какой отрасли или установке будет крутиться кусочек софта с написанным им кодом - это излишне... так.. его можно назвать рядовоым программистом.. возможно хорошим но... но назвать это тело автоматчиком - увольте
приведенный мной пример автоматизации хим производства тому пример.. можно привести и еще несколько стольже убедительных примеров

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

А разве это задача не метролога?

Только на крупных предприятиях еще осталась эта служба. Да и задачи у них несколько другие

Поддерживаю на 100%
Абсолютно не согласен с ggg_ggg в данном вопросе, разбираться в технологиях HVAC автоматчик (тех же HVAC систем) просто обязан.

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

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

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