Конечно, надо. Просто - с моей точки зрения - проблему бы легко снимал один маленький переключатель под крышкой на винте под пломбой. Но такие технологии, кажется, утеряны :-)
На этапе первичной настройки системы - это вполне приемлимо. После ввода в эксплуатацию подобные вещи делаем в согласованное технологическое окно. И, естественно, для этого выделяется отдельная релизная ветка в git. Обычный конвейер просто собирает версию, автотесты и всё такое.
Кейс я могу наверное даже придумать, но нет ли за такие придумки тоже какой-нибудь административки? :-)
Я могу лучше вспомнить, как покупал какой-то сыр, и на упаковке была реклама в стиле "отсканируй код и выиграй приз". И код был - datamatrix. Сканер кассы самообслуживания его считал и выпал в осадок - некорректный продукт, красная лампочка, все дела. Ну, минут пять я ждал "к вам спешащего специалиста". Дизайнер перемудрил с дизайном, что скажешь
О, большое спасибо, мы посмотрим. Времени как обычно было не очень много - одна из проблем подобных проектов в том, что оборудование сразу едет к заказчику, и на то, чтобы собрать стенд и всё досконально протестировать, есть буквально несколько дней....
Так как мы UI делали на базе уже имеющейся системы, то это правда было быстрее, чем отдельно всю эту историю с ТСД реализовывать. А для того, чтобы была проблема "глухие зоны WiFi" необходимо, чтобы WiFi как минимум присутствовал. А есть предприятия, где WiFi пока вот не развёрнут. И ради одного ТСД его точно делать никто не будет.
Про начальника смены понятно, а вот интересно - в супермаркетах на кассах аналогичное оборудование? Это же прямо вектор атаки...
ТСД мы используем, когда людям надо ходить по территории. А тут - стационарное рабочее место, и заказчик хотел именно АРМ. И сканер - привязан проводом к моноблоку, никто не утащит случайно и не забудет.
При наличии задолженности устройство будет автоматически ограничивать подачу элэлектроэнергиии
В цитатах из закона этого нет, и получается, что счётчик не только передаёт данные, но и принимает их, и ещё и лицевой счёт оперативно отслеживает. Интересно, какой механизм на самом деле прописан в законе.
Игра - огонь! Причём даже семилетняя дочь заинтересовалась, несмотря на символьное оформление.
У меня возник вопрос, если, конечно, это не коммерческая тайна - каким образом формируются лабиринты для тех уровней, где надо жуков взрывать тротилом? Ведь (если ставить условие возможности прохождения автоматически сгенерированного уровня обязательным) надо обеспечить наличие пустой от ловушек зоны 3*3 (возможно, больше?) на пути жука, иначе его нельзя будет никогда взорвать.
И еще - неочевидно, как кидаются гранаты. Я, по привычке, считал, что они полетят по касательной к своей круговой траектории в момент запуска, но тут алгоритм оказался сильно проще :-)
Значок ставили по той же причине, что и Corp. в названии. Большие так делают, значит и мы тоже так будем. При этом что это юридически значит, никто тогда не задумывался. Я сам делал точно так же со своими утилитками :-)
По инерции прочитал "хабровский военный оркестр", а потом задумался - может быть, пора и такой сделать? Кстати, есть ли у хабра гимн, а если нет, то как его придумать, не нарушая копирайт? :-)
Классно, спасибо за статью. Nexus для моего случая правда немного перебор, а с Node.js приходится решать ровно ту же самую задачу, которую Вы уже решили.
Для начала пожелание автору — пишите, пишите ещё, а не читайте комментарии. Этот тоже можете не читать :-) А для остальных немного размышлений
Конечно, и про «Страж-птицу», и про «Непобедимого» Лема я вспомнил, пока читал. Мне понравилось, хотя, конечно, если начинать копаться в технике, можно многое накопать. Но если рассматривать это как художественное произведение (каковым оно и является), то все эти возражения можно легко снять. В Страж-птице никого ведь не смущает, что она месяцами летает на не совсем понятном источнике энергии? Нет к Шекли претензий, что недостаточно подробно описаны аккумуляторы и способы удержания заряда? А главного героя «Непобедимого» у Лема спасала почти что шапочка из фольги (ну конечно, не совсем шапочка, а скорее даже сеточка), но тоже никто почему-то к алгоритмам самоорганизации некросети тут не высказывал вопросов.
Проблема любого боевика, детектива и так далее в том, что сначала надо создать непробиваемое препятствие (ну тот же сейф в банке за 77-ю запорами или лабораторию с вирусом). А потом надо придумать, как преступник (или главный герой) всё-таки туда проникает, да ещё так, чтобы это не выглядело совсем забавно (и всё равно зачастую остаётся ощущение, что были перекрыты все выходы, а он вошёл через вход). В данном конкретном случае задача решена вполне достойно и логично — в той логике, которая представлена в самом произведении, а не в руководстве по конструированию истребителей пятого поколения. Называть это графоманией я бы не стал. Интересно, сколько времени ушло на написание этого текста. 18 тысяч знаков с пробелами :-) почти журнальный разворот.
P.S. Кстати, вопрос авторского права — даже если картинка к рассказу взята из открытых источников, я думаю, было бы нелишним указать её автора.
Коллеги, вы абсолютно верно описываете один из возможных вариантов реализации данной задачи. У каждого варианта есть свои плюсы и минусы, в том числе и финансовые.
В нашей ситуации были внешние условия и предпосылки, ввиду которых мы реализовали систему именно так. Давайте я их приведу и, думаю, все встанет на свои места:
— Объекты территориально распределены по всей стране;
— Большое количество оборудования;
— Нельзя вмешиваться в локальные и объектовые системы управления, либо вмешательство должно быть минимальным. Соответственно, вмешательство в PLC и «головы» станков – табу;
— Платформа выбрана с учетом того, что в перспективе на нее пойдут и другие данные от распределенных объектовых систем и будут решаться дополнительные задачи уровня MES, а не только расчет наработки.
Поэтому, как видите, задача — не только посчитать наработку с учетом всех внешних условий и финансов, но и заложить базу для дальнейшего развития. Отсюда и отсутствие Siemens, Schneider, Allen-Bradley и General Electric, которые очень хороши как объектовые SCADA, но могут не подойти как MES-платформа. Хотя, есть чудесный продукт Siemens WinCC OA, но это уже совсем другая история… Про Wonderware, вы заблуждаетесь, это довольно мощная и гибкая платформа.
По поводу, квалификации и опыта сильно распаляться не буду, скажу лишь, что у нас есть сотрудники, которые прекрасно знают КИП, PLC, DCS-системы, SCADA-системы ведущих мировых производителей и соответствующие промышленные протоколы, свободно программирующие как на языках группы МЭК 61131-3, так и на общих языках программирования и скриптовых языках. Естественно, сотрудники, которые программируют на C#, не лезут в контроллеры (хотя есть парни, которые и то и то умеют), а те, кто программирует PLC, не занимаются разработкой собственных верхнеуровневых приложений.
Так что к заказчику приходят именно те парни, которые нужны и делают именно то, что нужно с учетом всех внешних условий и предпосылок.
Должен быть регламент обслуживания, который всеми согласован. В нашем случае в нем будет прописано, что обслуживание нужно осуществлять по достижению оборудованием определенной наработки, что естественно должно быть согласовано с производителем оборудования. Т.е. на уровне предприятия и производителя есть согласованный документ, что нужно обслужить станок, если он проработал столько-то часов с предыдущего ТО. Там же прописаны и операции по обслуживанию. Если данный документ не соблюдается, то будут проблемы.
Спасибо, внимательнейшим образом изучаю :-)
Это рабочий прототип, потом поджали. К сожалению, пока проект делают, очень редко хватает времени, чтобы фотокорреспондент успел всё заснять :-)
Конечно, надо. Просто - с моей точки зрения - проблему бы легко снимал один маленький переключатель под крышкой на винте под пломбой. Но такие технологии, кажется, утеряны :-)
На этапе первичной настройки системы - это вполне приемлимо. После ввода в эксплуатацию подобные вещи делаем в согласованное технологическое окно. И, естественно, для этого выделяется отдельная релизная ветка в git. Обычный конвейер просто собирает версию, автотесты и всё такое.
Кейс я могу наверное даже придумать, но нет ли за такие придумки тоже какой-нибудь административки? :-)
Я могу лучше вспомнить, как покупал какой-то сыр, и на упаковке была реклама в стиле "отсканируй код и выиграй приз". И код был - datamatrix. Сканер кассы самообслуживания его считал и выпал в осадок - некорректный продукт, красная лампочка, все дела. Ну, минут пять я ждал "к вам спешащего специалиста". Дизайнер перемудрил с дизайном, что скажешь
спасибо, посмотрю :-)
О, большое спасибо, мы посмотрим. Времени как обычно было не очень много - одна из проблем подобных проектов в том, что оборудование сразу едет к заказчику, и на то, чтобы собрать стенд и всё досконально протестировать, есть буквально несколько дней....
Так как мы UI делали на базе уже имеющейся системы, то это правда было быстрее, чем отдельно всю эту историю с ТСД реализовывать. А для того, чтобы была проблема "глухие зоны WiFi" необходимо, чтобы WiFi как минимум присутствовал. А есть предприятия, где WiFi пока вот не развёрнут. И ради одного ТСД его точно делать никто не будет.
Про начальника смены понятно, а вот интересно - в супермаркетах на кассах аналогичное оборудование? Это же прямо вектор атаки...
ТСД мы используем, когда людям надо ходить по территории. А тут - стационарное рабочее место, и заказчик хотел именно АРМ. И сканер - привязан проводом к моноблоку, никто не утащит случайно и не забудет.
Спасибо, буду стараться :-)
В цитатах из закона этого нет, и получается, что счётчик не только передаёт данные, но и принимает их, и ещё и лицевой счёт оперативно отслеживает. Интересно, какой механизм на самом деле прописан в законе.
Игра - огонь! Причём даже семилетняя дочь заинтересовалась, несмотря на символьное оформление.
У меня возник вопрос, если, конечно, это не коммерческая тайна - каким образом формируются лабиринты для тех уровней, где надо жуков взрывать тротилом? Ведь (если ставить условие возможности прохождения автоматически сгенерированного уровня обязательным) надо обеспечить наличие пустой от ловушек зоны 3*3 (возможно, больше?) на пути жука, иначе его нельзя будет никогда взорвать.
И еще - неочевидно, как кидаются гранаты. Я, по привычке, считал, что они полетят по касательной к своей круговой траектории в момент запуска, но тут алгоритм оказался сильно проще :-)
Ждём продолжение - агента EBCDIC :-)
Значок ставили по той же причине, что и Corp. в названии. Большие так делают, значит и мы тоже так будем. При этом что это юридически значит, никто тогда не задумывался. Я сам делал точно так же со своими утилитками :-)
По инерции прочитал "хабровский военный оркестр", а потом задумался - может быть, пора и такой сделать? Кстати, есть ли у хабра гимн, а если нет, то как его придумать, не нарушая копирайт? :-)
Конечно, и про «Страж-птицу», и про «Непобедимого» Лема я вспомнил, пока читал. Мне понравилось, хотя, конечно, если начинать копаться в технике, можно многое накопать. Но если рассматривать это как художественное произведение (каковым оно и является), то все эти возражения можно легко снять. В Страж-птице никого ведь не смущает, что она месяцами летает на не совсем понятном источнике энергии? Нет к Шекли претензий, что недостаточно подробно описаны аккумуляторы и способы удержания заряда? А главного героя «Непобедимого» у Лема спасала почти что шапочка из фольги (ну конечно, не совсем шапочка, а скорее даже сеточка), но тоже никто почему-то к алгоритмам самоорганизации некросети тут не высказывал вопросов.
Проблема любого боевика, детектива и так далее в том, что сначала надо создать непробиваемое препятствие (ну тот же сейф в банке за 77-ю запорами или лабораторию с вирусом). А потом надо придумать, как преступник (или главный герой) всё-таки туда проникает, да ещё так, чтобы это не выглядело совсем забавно (и всё равно зачастую остаётся ощущение, что были перекрыты все выходы, а он вошёл через вход). В данном конкретном случае задача решена вполне достойно и логично — в той логике, которая представлена в самом произведении, а не в руководстве по конструированию истребителей пятого поколения. Называть это графоманией я бы не стал. Интересно, сколько времени ушло на написание этого текста. 18 тысяч знаков с пробелами :-) почти журнальный разворот.
P.S. Кстати, вопрос авторского права — даже если картинка к рассказу взята из открытых источников, я думаю, было бы нелишним указать её автора.
В нашей ситуации были внешние условия и предпосылки, ввиду которых мы реализовали систему именно так. Давайте я их приведу и, думаю, все встанет на свои места:
— Объекты территориально распределены по всей стране;
— Большое количество оборудования;
— Нельзя вмешиваться в локальные и объектовые системы управления, либо вмешательство должно быть минимальным. Соответственно, вмешательство в PLC и «головы» станков – табу;
— Платформа выбрана с учетом того, что в перспективе на нее пойдут и другие данные от распределенных объектовых систем и будут решаться дополнительные задачи уровня MES, а не только расчет наработки.
Поэтому, как видите, задача — не только посчитать наработку с учетом всех внешних условий и финансов, но и заложить базу для дальнейшего развития. Отсюда и отсутствие Siemens, Schneider, Allen-Bradley и General Electric, которые очень хороши как объектовые SCADA, но могут не подойти как MES-платформа. Хотя, есть чудесный продукт Siemens WinCC OA, но это уже совсем другая история… Про Wonderware, вы заблуждаетесь, это довольно мощная и гибкая платформа.
По поводу, квалификации и опыта сильно распаляться не буду, скажу лишь, что у нас есть сотрудники, которые прекрасно знают КИП, PLC, DCS-системы, SCADA-системы ведущих мировых производителей и соответствующие промышленные протоколы, свободно программирующие как на языках группы МЭК 61131-3, так и на общих языках программирования и скриптовых языках. Естественно, сотрудники, которые программируют на C#, не лезут в контроллеры (хотя есть парни, которые и то и то умеют), а те, кто программирует PLC, не занимаются разработкой собственных верхнеуровневых приложений.
Так что к заказчику приходят именно те парни, которые нужны и делают именно то, что нужно с учетом всех внешних условий и предпосылок.