Проектный инжиниринг

Автоматизация технологических процессов, системы управления, АСУ ТП, АСКУЭ, программирование ПЛК, человеко-машинный интерфейс, сетевое оборудование, протоколы
Аватара пользователя
CHANt
Профессионал
Сообщения: 565
Зарегистрирован: 13 окт 2012, 15:24

Re: Проектный инжиниринг

Сообщение CHANt »

Степа писал(а):А программную часть мы описываем по ГОСТ 19. ГОСТ 2 не обязывает поставлять доки к программной части, ГОСТ 19 никак не рассматривает железо. Но других, лучше - нет.
Уже по теме указывали, железо - ГОСТ 21.408-93, который четко, недвусмысленно дает формулировку:
"Настоящий стандарт устанавливает состав и правила оформления рабочей документации систем автоматизации технологических процессов и инженерных систем (далее - систем автоматизации) проектируемых объектов строительства различного назначения.
Требования настоящего стандарта распространяются на рабочую документацию технического обеспечения АСУ ТП, разрабатываемую по ГОСТ 34.201."

Конструкторская документация, это актуально в сфере Михайло, т.е. где системы разрабатывает КБ или какой нибудь собственный проектный отдел (вполне возможно что и у Вас также, я не знаю где Вы работаете). Если тот же вариант, тогда наш спор бессмысленен, так как действительно внутри организации можно придерживаться хоть собственных стандартов (СТП), ибо ФЗ "О техническом регулировании" это разрешает. Но, когда Вы сторонний разработчик, за забором, Вам все равно придется делать как указано в ТЗ. Вот у меня указано - выполнить проектным путем. Даже, если я в состоянии собрать систему из узлов имеющих в своем составе автоматику с ЭД по ГОСТ 2.601, мне все равно придется выполнить хотя бы раздел ТО по ГОСТ 21.408-93. Т.е. привязать все по месту. Исключением можно назвать поставляемое оборудование оснащенное системой автоматики. Например технологическую линию, станок, модульную котельную. Вот в таком случае кроме комплекта ЭД на автоматику ничего не требуется.

Степа
Любитель
Сообщения: 98
Зарегистрирован: 21 окт 2012, 10:09

Re: Проектный инжиниринг

Сообщение Степа »

CHANt писал(а):Уже по теме указывали, железо - ГОСТ 21.408-93, который четко, недвусмысленно дает формулировку:
"Настоящий стандарт устанавливает состав и правила оформления рабочей документации систем автоматизации технологических процессов и инженерных систем (далее - систем автоматизации) проектируемых объектов строительства различного назначения.
Требования настоящего стандарта распространяются на рабочую документацию технического обеспечения АСУ ТП, разрабатываемую по ГОСТ 34.201."
Рабочая документация - достаточно двусмысленное название. Есть же по ГОСТ 2 - "Эксплуатационная".
Но пока наших заказчиков устраивает такое положение дел: или комплект по связке ГОСТ 2+ГОСТ 19 и там можно разобраться или груда макулатуры по ГОСТ 34 или чистый самопал, разве что кругом прописано "с учетом требований ГОСТ". Один только заказчик требовал работать по этому ГОСТ, но там были свои заморочки /бардак в области управления проектом сыграл не самую последнюю роль/ и в итоге ничего толком не получилось.
CHANt писал(а):Конструкторская документация, это актуально в сфере Михайло, т.е. где системы разрабатывает КБ или какой нибудь собственный проектный отдел (вполне возможно что и у Вас также, я не знаю где Вы работаете).
Мы в одной организации работаем, в разных структурных подразделениях. С той лишь разницей, что для нас разработка - не совсем прямая обязанность /сказано за то как-то скользко, как хочешь, так и понимай/. Поэтому наши документы в любом случае проходят границу предприятия, хоть и используются внутри. Иногда, бывает, на сторону работаем /но это нечасто/. И у нас хороших своих проектантов нет, потому и часто бывает так, что программную часть проекта делаем мы /большей частью я - остальные пока еще молодые и не уяснили себе всю ценность хорошей документации, а заставить делать - во-первых, у меня прав таких нет, а во-вторых - хорошую документацию из-под палки не получить/, а электрическую и механическую - кто-то со стороны. Несколько раз уже было, так, что подразделение, где трудится уважаемый Михайло, делало механику и электрику, а программная часть - наше /вот совсем недавно закончен как раз такой проектик, на горизонте виден еще один/. Как мне видится, было бы гораздо больше пользы объединить наши структуры: когда их создавали, мы занимались разными делами, сейчас же занимаемся фактически одним и тем же /в планах развития нашей структуры уже попытались заложить проектные группы по механике, электрике и т.п./. Но большому начальству виднее...
И именно потому, что часто приходится по написанной самим же документации спустя годы разбираться в проблемах собственного произведения /на настоящий момент самой старой действующей моей разработке уже лет 15-16 и какого-либо обновления пока не запланировано/, мне не нравится структура получающихся документов по ГОСТ 34. По ним совершенно неудобно работать /если, конечно, строго следовать требованиям РД, в котором прописаны требования к содержанию документов/. Поэтому спустя некоторое время на обороте появляются записи от руки, а спустя лет пять документация либо уже пролюблена /обслуживающие работают по своим записям, записи у каждого свои и мало кто их передает коллегам либо за обслуживание вспоминают, когда чего-то сдохло/ либо сложена так, что становится понятно - люди читают те записи, а не то, что напечатано.

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

Аватара пользователя
san
Специалист
Сообщения: 117
Зарегистрирован: 13 окт 2012, 17:17
Откуда: Киев
Контактная информация:

Re: Проектный инжиниринг

Сообщение san »

Я что-то не пойму. ГОСТ 34, ГОСТ 2 и ГОСТ 19 не перечат один другому (п крайней мере в основе своей), так как 34-й всего-лишь координирующий, большинство документов со ссылкой на ЕСКД и ЕСПД. ГОСТ 34 и ГОСТ 21 где-то конфиликтуют, но там четко прописано, что ГОСТ 21 в своей части выигрует.
ГОСТ 2 и ГОСТ 19 никак не связаны между собой. То есть ГОСТ 34 получаются какими-то метастандартами, так как АС (в том числе и АСТУП) очень многогранны, и включают в себя работы по:
1) электрической части;
2) программной части;
3) строительной части;
4) пневматической/гидравлической части;
5) других...
Одно дело разработать щит вместе с ПЛК, панелью/СКАДА и продать его как изделие. Другое дело, приехать на объект, сделать внешний монтаж (шефмонтаж) и запустить тех.процесс. Да ГОСТ 21 и ГОСТ 34 дают какую-то стадийность, а в ГОСТ 2 и ГОСТ 19 я этого не видел.

Степа
Любитель
Сообщения: 98
Зарегистрирован: 21 окт 2012, 10:09

Re: Проектный инжиниринг

Сообщение Степа »

san писал(а):Я что-то не пойму. ГОСТ 34, ГОСТ 2 и ГОСТ 19 не перечат один другому (п крайней мере в основе своей), так как 34-й всего-лишь координирующий, большинство документов со ссылкой на ЕСКД и ЕСПД. ГОСТ 34 и ГОСТ 21 где-то конфиликтуют, но там четко прописано, что ГОСТ 21 в своей части выигрует.
Есть РД 50-34.698-90, в котором изложены требования к содержанию документов, которые требуется составлять по ГОСТ 34. В 19-й группе требования к содержанию документов изложено в отдельных стандартах, группой 2 я мало пользуюсь /требования к текстовым документам да система обозначений на схемах/.
Состав документации в строгом соответствии этому РД - набор мин. Одну из них я уже обозначил.
Ну и чисто практически работать с таким комплектом нормально невозможно. Есть у нас парочка комплектов документации, составленных со строгим соблюдением требований /особый человек за тем бдил/. Где теперь те комплекты - не знает никто. Ибо тем, кому надо составили себе выписки /каждый - себе/ и откинули этот хлам в сторону, а кому не надо, те потеряли. Сейчас пришло много нового народу, приходится за ручку водить и пальцем показывать.
san писал(а):ГОСТ 2 и ГОСТ 19 никак не связаны между собой.
Никак.
san писал(а):То есть ГОСТ 34 получаются какими-то метастандартами, так как АС (в том числе и АСТУП) очень многогранны, и включают в себя работы по:
1) электрической части;
2) программной части;
3) строительной части;
4) пневматической/гидравлической части;
5) других...
Одно дело разработать щит вместе с ПЛК, панелью/СКАДА и продать его как изделие. Другое дело, приехать на объект, сделать внешний монтаж (шефмонтаж) и запустить тех.процесс.
Пункты 1, 4 - ГОСТ 2, пункт 2 - ГОСТ 19, строительной части не знаю, у нас всегда была или модернизация или доработка существующего оборудования /в первом случае существенная переработка электрической части, программная - вновь разрабатывается, иногда и механика прихватывается; во втором - незначительное доведение существующей системы до более высоких требований, как правило, без особых изменений конструкции/. В любом случае оборудование уже установлено на своем месте.
san писал(а):Да ГОСТ 21 и ГОСТ 34 дают какую-то стадийность, а в ГОСТ 2 и ГОСТ 19 я этого не видел.
ГОСТ 2.119-73 Эскизный проект
ГОСТ 2.120-73 Технический проект
ГОСТ 2.601-95 Эксплуатационные документы
ГОСТ 19.102-77 Стадии разработки
Это так, сходу вспомнилось...

Аватара пользователя
san
Специалист
Сообщения: 117
Зарегистрирован: 13 окт 2012, 17:17
Откуда: Киев
Контактная информация:

Re: Проектный инжиниринг

Сообщение san »

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

Аватара пользователя
CHANt
Профессионал
Сообщения: 565
Зарегистрирован: 13 окт 2012, 15:24

Re: Проектный инжиниринг

Сообщение CHANt »

Степа, а что есть хорошая документация?
Мне так временами кажется, что кроме инструкции пользователя, нужны разве что только схемы подключения, так как приборный парк и механизмы менять чаще приходится. Ну подстроить может новый датчик. А вот изменить технологию, на то Ваши структурные подразделения и существуют. Документировать весь код - кисло. Вы и так его в LD делаете.
Лично, я вообще поглядываю на описания сименса в части стандартных и системных функций http://old.automation-drives.ru/as/prod ... %CE&l3=doc
Давать альбом графов, давать описание входов/выходов, но зато документировать хорошо взаимосвязь между блоками. типа CFC

Степа
Любитель
Сообщения: 98
Зарегистрирован: 21 окт 2012, 10:09

Re: Проектный инжиниринг

Сообщение Степа »

san писал(а):То есть я так понимаю Степа, что центровые - это ГОСТ 19 (ГОСТ 2 пользуетесь только для приниципиальных схем)?
Центровой - ГОСТ 19 как самый более-менее соответствующие реальности в программной области. Принципиалки - это не ко мне, я больше по программной части. Но какие-то структуры приходится прорисовывать, потому и пользуюсь системой обозначений ГОСТ 2, чтобы потом у нас с железячниками не было расхождений и полное взаимопонимание на всех этапах.
san писал(а):Схему автоматизации - в топку?
В принципе, можем нарисовать. Но чаще всего она нужна для облегчения взаимопонимания, если разработчики обычно не могут поговорить глядя друг на друга /был у нас такой опыт, малоприятный, но в целом относительно успешный/. А в остальных случаях из других схем достаточно понятно становится.
san писал(а):Структурные схемы какие-то делаете? Не один раз приходилось пускать чужие системы. Очень не хватало структурных схем. Это конечно больше к эксплуатационной документации.
Обычно по электрической части:
Структура связей: показаны все контроллеры, панели, свичи /если есть/, типы связей /Ethernet, RS-485 и т.п./.
Структура контроллера: последовательность блоков, аппаратные настройки /если есть/.
Системы чаще всего несложные, поэтому часто монтажники разбираются со структурой исключительно по принципиалке.

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

Чаще всего в ПНР мы же и участвуем. Но монтажники, если сторонники, обычно заранее со всем пакетом документов ознакамливаются и, если есть вопросы, задают. Мы отвечаем исправляя схемы и описаловку - так проще потом готовить окончательный пакет со всеми изменениями. Да и, по сути, это первые нормальные читатели после авторов, такие, которые не просто читают не пойми что, а документ, по которому работать.
san писал(а):У нас (в пищевке) вобще мало кто требует соблюдения стандартов. Но среди перечня документов (как эксплуатационных) просят как правило схему автоматизации и принципиалки. И всё. Понятное дело, что спецификаци или ведомости к ним должны быть.
У нас в машиностроении соблюдение требуют, но, как правило, те, кто требует, сами стандартов не читали, в лучшем случае список имеют /за исключением нормоконтроля - но эти больше блюдут букву стандарта в оформлении/. Так что бывает иногда даже интересно...
CHANt писал(а):Степа, а что есть хорошая документация?
На мой взгляд такая, чтобы с ней было удобно работать новому человеку. В принципе, у Сименс в целом хорошая документация /особенно та часть, что касается S7-200: у меня это была пара файлов: что-то типа первых шагов - тут расписано с картинками, как включать, как монтировать, как изготовить первую программу и залить ее, и добротное полное описание функционала/. Отдельно набор примеров.
В этом отношении пакет документации для S7-300 заметно проигрывает: слишком запутанно все. Понятно, что сейчас, когда я уже более-менее освоил контроллер, сам сделал несколько проектов, посмотрел, как люди делают, стало многое понятно. Но вот первые шаги - это было нечто.
CHANt писал(а):Мне так временами кажется, что кроме инструкции пользователя, нужны разве что только схемы подключения, так как приборный парк и механизмы менять чаще приходится. Ну подстроить может новый датчик. А вот изменить технологию, на то Ваши структурные подразделения и существуют. Документировать весь код - кисло. Вы и так его в LD делаете.
Инструкция пользователя /у нас это именуется Руководство по эксплуатации - РЭ/ должна содержать все основные структурные, принципиальные и монтажные схемы: чтобы пользователь при ознакомлении не шнырял по пачке книжек /или того хуже - разыскивал в одной книжке нужный документ/, необходимые настройки.
Да и программисту не грех головой подумать: некоторые блоки и датчики все равно по тому же интерфейсу настраиваются, что и обмен данными идет, почему бы и не ввести в собственную программу функцию автоматической настройки сетевых параметров?
Весь код и не надо документировать, код должен быть относительно читабельным /комментарии должны помогать читать код, но не взамен читабельности кода/. Достаточно нескольких рисунков /вон, только что выше написал/, плюс небольшое словесное описание алгоритмов основных функций. И документация на код не должна входить в РЭ - ей там делать нечего. Отдельной книжицей...

Аватара пользователя
san
Специалист
Сообщения: 117
Зарегистрирован: 13 окт 2012, 17:17
Откуда: Киев
Контактная информация:

Re: Проектный инжиниринг

Сообщение san »

Степа писал(а):По программной части:
Схема потоков данных: это уже больше к программной части, показано какие данные откуда берутся, куда попадают.
Я такое тоже придумал, вот гапример тут (рис.16):
ссылка на методичку в русском варианте
или тут (рис.5-9):
ссылка на методичку по такого типа схемам на укр. языке

Аватара пользователя
CHANt
Профессионал
Сообщения: 565
Зарегистрирован: 13 окт 2012, 15:24

Re: Проектный инжиниринг

Сообщение CHANt »

Степа писал(а):Например, блоков данных "Аналоговые величины" нет, у меня в одной DB сгруппировано структурами по механизмам или по функционалу: например, аварии или состояние механизма 1 /тут все целиком: аварии механизма, состояние, все параметры/. Эти структуры заполняются при обработке входов.
Ага, грамотный подход! Есть смысл в СКАДе создавать фейсплеты с привязкой структурного типа переменных, чтобы сразу графический модуль механизма, датчика содержал в себе разбор структуры. С экономится время на разработку мнемосхем с разводкой разнородной информации одного элемента. Я как-то, по старинке остался. Когда то у нас были не слишком пропускные каналы связи и мы оптимизировали объемы данных в непрерывно заполненные блоки данных одного типа. Типа только дискреты, зато вычитывали словами, либо двойными словами, а затем в скаде уже разводили побитно. Сейчас как бы вопрос с низкой пропускной способностью связи отпал, можно смело переходить на подобный обмен данными. Собственно он и рекомендуется у многих производителей.
Я еще пробовал работать с системой аварийных сообщений - которые забиваешь в степ7, а потом автоматом закидываешь во флекс и винсс вместе с текстами. Неплохо, время экономится в скаде, но, ресурсоемкое это дело до безобразия. Мне для этого надо переходить на 400 линейку, и это с системы в 50-60 внешних сигналов, что просто экономически нецелесообразно.

Аватара пользователя
CHANt
Профессионал
Сообщения: 565
Зарегистрирован: 13 окт 2012, 15:24

Re: Проектный инжиниринг

Сообщение CHANt »

Степа писал(а):
san писал(а):Схему автоматизации - в топку?
В принципе, можем нарисовать. Но чаще всего она нужна для облегчения взаимопонимания, если разработчики обычно не могут поговорить глядя друг на друга /был у нас такой опыт, малоприятный, но в целом относительно успешный/. А в остальных случаях из других схем достаточно понятно становится.
Может в Вашем дискретном производстве схема автоматизации не нужна, не могу сказать, но в моем непрерывном производстве, только по ФСА можно легко определить какой датчик к какому контуру (функции) относится и вообще что к чему. Для меня ТЗ и схема автоматизации это все что надо для написания программы. ТЗ это собственно требования СНиПов и всяких ПТЭ и ПБ переписанные :D
Степа писал(а):
san писал(а):Структурные схемы какие-то делаете? Не один раз приходилось пускать чужие системы. Очень не хватало структурных схем. Это конечно больше к эксплуатационной документации.
Обычно по электрической части:
Структура связей: показаны все контроллеры, панели, свичи /если есть/, типы связей /Ethernet, RS-485 и т.п./.
Структура контроллера: последовательность блоков, аппаратные настройки /если есть/.
Системы чаще всего несложные, поэтому часто монтажники разбираются со структурой исключительно по принципиалке..
А мне наоборот нечего на структурной схеме показывать - обычно один контроллер. одна панель, ну несколько частотников - потом модуль связи и два сервера "наверху". Схема глупая получается, мне заказчик говорит не нужно и так понятно.
А вот принципиалка шкафа с контроллером в ходу прежде всего у эксплуатации. у киповцев, у нас она своеобразная
2012-07-23 Раздел АТМ Победы 120 23_07_2012 испр 1 (1).rar
вставил текущий объект, только закончил.
Степа писал(а):Инструкция пользователя /у нас это именуется Руководство по эксплуатации - РЭ/ должна содержать все основные структурные, принципиальные и монтажные схемы: чтобы пользователь при ознакомлении не шнырял по пачке книжек /или того хуже - разыскивал в одной книжке нужный документ/, необходимые настройки.
Ну у нас на объекте старушки сидят (операторы), которые 30 лет котлы разжигали с помощью изношенных мужских трусов смоченных соляркой и намотанных на палку. А мы им горелку с розжигом и контролером да тач-панелью, а их еще и сократят потом...Самое прикольноое. лет пять назад они с таким страхом в тач-панель пальцем тыкали, а вот в прошлом году старушенция на тач-панели ТР-177В пыталась пролистать экраны как на айфоне...я в шоке был :D
так что РЭ некому давать, только инструкцию как пальчиком водить
У вас нет необходимых прав для просмотра вложений в этом сообщении.

Аватара пользователя
san
Специалист
Сообщения: 117
Зарегистрирован: 13 окт 2012, 17:17
Откуда: Киев
Контактная информация:

Re: Проектный инжиниринг

Сообщение san »

От хорошо :) Уже собираю коллекцию чужих проектов. Может кто ещё подкинет. :)

Степа
Любитель
Сообщения: 98
Зарегистрирован: 21 окт 2012, 10:09

Re: Проектный инжиниринг

Сообщение Степа »

CHANt писал(а):Когда то у нас были не слишком пропускные каналы связи и мы оптимизировали объемы данных в непрерывно заполненные блоки данных одного типа. Типа только дискреты, зато вычитывали словами, либо двойными словами, а затем в скаде уже разводили побитно. Сейчас как бы вопрос с низкой пропускной способностью связи отпал, можно смело переходить на подобный обмен данными. Собственно он и рекомендуется у многих производителей.
А данный подход примерно оттуда и пришел. Только до этого у меня чаще всего разбивка по регистрам шла, потому и первая группировка по функционалу: аварии, положения и т.п. Потому как аварий обычно много диагностируется и вычитывая 16-ти или 32-х битный регистр получаешь сразу много флажочков. Да и не все данные одинаково полезны: скажем, аварии надо читать как можно чаще, а, к примеру, текущую температуру - можно и пореже, все равно она резко не изменится. Теперь, когда пошли более-менее скоростные каналы связи, проще делать группировку по механизмам.
CHANt писал(а):Я еще пробовал работать с системой аварийных сообщений - которые забиваешь в степ7, а потом автоматом закидываешь во флекс и винсс вместе с текстами. Неплохо, время экономится в скаде, но, ресурсоемкое это дело до безобразия. Мне для этого надо переходить на 400 линейку, и это с системы в 50-60 внешних сигналов, что просто экономически нецелесообразно.
Ага, значит можно эту тему и не копать...
CHANt писал(а):Может в Вашем дискретном производстве схема автоматизации не нужна, не могу сказать, но в моем непрерывном производстве, только по ФСА можно легко определить какой датчик к какому контуру (функции) относится и вообще что к чему. Для меня ТЗ и схема автоматизации это все что надо для написания программы. ТЗ это собственно требования СНиПов и всяких ПТЭ и ПБ переписанные :D
Может быть, может быть... Может, просто не распробовал...
А так: приличное ТЗ и есть собрание описания технологии, требований по метрологии и всякой нормативки.
CHANt писал(а):А мне наоборот нечего на структурной схеме показывать - обычно один контроллер. одна панель, ну несколько частотников - потом модуль связи и два сервера "наверху". Схема глупая получается, мне заказчик говорит не нужно и так понятно.
Просто однажды у нас эта схема перекочевала на один из экранов диагностики, где были графически показаны нарушенные связи. Народ был в бешенном восторге: на главном экране загорелось красное табло "СВЯЗЬ", нажали на него - экран со схемой связей, сетевыми настройками каждого узла и крестами показаны нарушенные связи.
CHANt писал(а):Самое прикольноое. лет пять назад они с таким страхом в тач-панель пальцем тыкали, а вот в прошлом году старушенция на тач-панели ТР-177В пыталась пролистать экраны как на айфоне...я в шоке был :D
так что РЭ некому давать, только инструкцию как пальчиком водить
Я помню, как лет десять назад бился за тач-панель... Главный аргумент как раз в том и заключался "ой, как сложно; а может люди не справятся?" и т.п. Все равно на компромисс пришлось идти: тач-панель и обычный пульт. Тот пульт мхом зарос практически сразу, а в экран тычут пальчиком. А вот проектанты почему-то опыт не признали и до недавнего времени так и строили пульты на кнопках.

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

Михайло
Администратор
Сообщения: 4094
Зарегистрирован: 19 сен 2012, 19:16

Re: Проектный инжиниринг

Сообщение Михайло »

Степа писал(а):А вот по ГОСТ 34 очень опасно документы делать.
Когда читаете это, учитывайте, что Степа работает на крупном государственном предприятии, где документация нужна для прикрытия задницы, а не для успешного выполнения проекта. :)

Аватара пользователя
CHANt
Профессионал
Сообщения: 565
Зарегистрирован: 13 окт 2012, 15:24

Re: Проектный инжиниринг

Сообщение CHANt »

Степа писал(а):
CHANt писал(а):Я еще пробовал работать с системой аварийных сообщений - которые забиваешь в степ7, а потом автоматом закидываешь во флекс и винсс вместе с текстами. Неплохо, время экономится в скаде, но, ресурсоемкое это дело до безобразия. Мне для этого надо переходить на 400 линейку, и это с системы в 50-60 внешних сигналов, что просто экономически нецелесообразно.
Ага, значит можно эту тему и не копать...
Кстати, если есть свободной RAM сотня полторы килобайт, то вполне можно с полсотни сообщений забить. Все таки не только тексты, но и метка времени присутствует, именно контроллера. У меня иногда бывает, переразмерят CPU, и еще и купят его.

Ответить