Тут, на мой взгляд, есть огромный отрыв текущего образования (стандартов и инструментария которому учат) от фактической потребности рынка труда — после размещения вакансии со словами "со знанием только Компаса не беспокоить" мне позвонило за месяц 36 соискателей — мол можем научиться, но опыта нет...
В сторону автора — он же действительно пишет что они построили модель диагностики по части параметров. Составление многопараметрической системы это удел не машинного обучения, а четкое ТЗ от эксперта в области. На мой взгляд, даже оценка ряда параметров, которые могут привести к выходу оборудования из строя — это уже хорошо, а комплексная оценка с применением предиктивных моделей — типа произошло что-то стоит обслужить, хотя по параметрам все +- норм, это то к чему стоит стремиться.
Ну тогда стоило бы расписать о физических типах передачи данных - аналоговые(токовые и напряжения) и дискретные, плюс огромная подчасть дискретных - цифровые. Ну и далее рассказать о логических типах цифровых типов - Modbus, Profibus, Can и т.д. И вынести в отдельную часть конвертеры типов сигналов - передача любого типа например через TCP/IP.
Ну нужно разделять типы данных и их передачу и преобразование сигналов. Управляет не условный rs или токовая петля, а управляет преобразователь сигнала в изменение частоты или другого параметра. В случае реле там все проще - там преобразователь сухой контакт, в случае исполнительных механизмов там сложнее - уже открываются и катушки для штоков и другие устройства. Про мир пневматики с ее исполнительными механизмами я вообще молчу. Если коротко - то как управлять это задача алгоритмизации, а с помощью чего это приборов и устройств.
Ну есть рабочие вопросы- у меня до этого года на мегафоне (тариф с полной безлимиткой по звонкам по РФ) долгое время лимита по времени не было. А тут по-моему час стал лимитов - долгие звонки нечасто но бывают и было непривычно даже.
У адекватных вендоров да, но иногда эти нюансы могут доходить чуть ли не абсурда - пример есть одного вендора где писать нужно практически на чистом ассемблере и это не мэк язык, но они на рынке с советских времен.
Вы меня не так поняли — я не предлагаю заменить МЭК тотально на что-то другое — каждое уместно в своем направлении. ЗП в некоторых направлениях и АСУ могут быть достойными, но это очень узкие направления.
Ну извините, но по моему опыту (пара крупных проектов в нефтехиме) в асу тп есть и обычные программисты на классических языках и вообще очень сильное разделение труда. При высокой стоимости проекта и ответственности в фирме интеграторе у спецов зп +- одинаковые, но! таких проектов единицы на нашу страну(если берем РФ), а это уже другая болячка экономическая… Не суть важно на каком железе будет крутиться ОСРВ, самая суть АСУ ТП и каким яп программироваться, важно чтобы это было экономически обоснованно. Когда законы не предполагают ответственности за выбор системы АСУ — типа вы что нибудь предложите, такой ад и будет по финансам в отрасли.
Подождите, АСУ это многогранная вещь — там может быть как и бэкенд написанный не на МЭК, так и просто система с HMI контроля и управления, в лучшем случае со SCADA, так и вообще железный ПАЗ на релюшках) Все эти уровни абстракций часть АСУ. И требования к персоналу по разработке и обслуживанию у них разные.
Ну вот лично мне за 10 лет ковыряния ПЛК не нравятся урезанные IDE кучи производителей, гды ты завязан только на реализованные ими блоки. Пример из классики — типа декларативные ЯП и императивные… Мне зачастую гораздо проще написать (или применить готовые) свои обработчики RS-485 для разных типов датчиков, 4...20 входов/выходов, чем юзать не пойми что "любезно" подсунутое мне производителем. Финансово тут есть вопросы — есть компании интеграторы — там тоже не во всех адекватные труду зарплаты, а есть компании пользователи — там вообще треш по уровню зп… Потому потихоньку под менторством родственника синьора учу джаву) Реально удобство IDE для джавы и IDE для пром программирования это небо и земля.
Ну вообще академически есть 3 сущности - 1. Противоаварийка, 2. Контроль и управление, 3. Мониторинг и диагностика неисправностей. Вы описываете 3ю совмещенную со 2й: важна же суть сообщения, а не ее интерпретация- или текст или графика… Для отображения информации есть неплохой стандарт ISA 101.01 /zanudaModeOff
Вот интересно сколько в стране (РФ) водоканалов оборудованы датчиками pH в отгружаемой воде, это пол дела… Другой вопрос что, например, в РФ качество воды считается на границе выхода с водозабора, что туда могут прилить дальше это не его зона ответственности… Соответственно поэтому водоканал у нас не отвечает за качество воды в кране…
При проектировании оборудования обычно производятся расчеты показателей надежности и запаса прочности. Соответственно срок службы и можно принять при эксплуатации в нормальных условиях равным требованиям стандартов промышленности. Учет аномалий, конечно, только опытным путем можно наработать.
Жалко операционную систему- я на неё с ios уходил) Первая Nokia 720 — потом 735 и уже под рабочие нужды последняя как раз и была 2х симочная 640. Для того времени это были прикольные не особо лагучие телефоны, которые неплохо оптимизированы. Из косяков 720 — она вначале бесила тем, что доступа к памяти не имелось — книжки и разные файлы приходилось с компьютера через onedrive закидывать, потом с каким то из апдейтов это починили. Общий косяк люмий — это отвратительные, на мой слух, звуковые характеристики в наушниках.
Ну если учесть, что по факту Steam Deck это обычный компьютер практически по железу, то новость выглядит так: на linux в virtual box запустили mac os. /sarcasm
В случае стабильного процесса проще выстроить модель нормального протекания реакции и уже через МГК отфильтровывать аномалии — такая схема снижает нагрузку на обработку. Но опять же это справедливо только при более-менее статичном процессе, если отслеживать много параметров, то придется под нормальное течение каждого из них строить свои модели, что в случае большого количества параметров не самая лучшая затея… Модели можно строить хоть на экспертных базах, хоть на нечеткой логике. Панацеей данный метод, конечно не является. Вообще для себя храню
таблицу плюсов и минусов методов
Для сложных случаев уже необходимо синтезировать совмещенные системы.
Подождите, ладно для настройки, а для эксплуатации Вы считаете что лучше открыть щиток и посмотреть что там внутри, чем поуправлять со внешней панели?
Тогда какое его исполнение по ip? Зачем ему панель своя, если например в запыленном месте будет? Лучше отдельная защищеная. Ну и винты надежнее)
Это же контроллер для бытовых нужд? Сертификации и все остальное как я вижу из дизайна не рассматриваете под промку?
Тут, на мой взгляд, есть огромный отрыв текущего образования (стандартов и инструментария которому учат) от фактической потребности рынка труда — после размещения вакансии со словами "со знанием только Компаса не беспокоить" мне позвонило за месяц 36 соискателей — мол можем научиться, но опыта нет...
В сторону автора — он же действительно пишет что они построили модель диагностики по части параметров. Составление многопараметрической системы это удел не машинного обучения, а четкое ТЗ от эксперта в области. На мой взгляд, даже оценка ряда параметров, которые могут привести к выходу оборудования из строя — это уже хорошо, а комплексная оценка с применением предиктивных моделей — типа произошло что-то стоит обслужить, хотя по параметрам все +- норм, это то к чему стоит стремиться.
Ну тогда стоило бы расписать о физических типах передачи данных - аналоговые(токовые и напряжения) и дискретные, плюс огромная подчасть дискретных - цифровые. Ну и далее рассказать о логических типах цифровых типов - Modbus, Profibus, Can и т.д. И вынести в отдельную часть конвертеры типов сигналов - передача любого типа например через TCP/IP.
Ну нужно разделять типы данных и их передачу и преобразование сигналов. Управляет не условный rs или токовая петля, а управляет преобразователь сигнала в изменение частоты или другого параметра. В случае реле там все проще - там преобразователь сухой контакт, в случае исполнительных механизмов там сложнее - уже открываются и катушки для штоков и другие устройства. Про мир пневматики с ее исполнительными механизмами я вообще молчу. Если коротко - то как управлять это задача алгоритмизации, а с помощью чего это приборов и устройств.
Ну есть рабочие вопросы- у меня до этого года на мегафоне (тариф с полной безлимиткой по звонкам по РФ) долгое время лимита по времени не было. А тут по-моему час стал лимитов - долгие звонки нечасто но бывают и было непривычно даже.
У адекватных вендоров да, но иногда эти нюансы могут доходить чуть ли не абсурда - пример есть одного вендора где писать нужно практически на чистом ассемблере и это не мэк язык, но они на рынке с советских времен.
Вы меня не так поняли — я не предлагаю заменить МЭК тотально на что-то другое — каждое уместно в своем направлении. ЗП в некоторых направлениях и АСУ могут быть достойными, но это очень узкие направления.
Ну извините, но по моему опыту (пара крупных проектов в нефтехиме) в асу тп есть и обычные программисты на классических языках и вообще очень сильное разделение труда. При высокой стоимости проекта и ответственности в фирме интеграторе у спецов зп +- одинаковые, но! таких проектов единицы на нашу страну(если берем РФ), а это уже другая болячка экономическая… Не суть важно на каком железе будет крутиться ОСРВ, самая суть АСУ ТП и каким яп программироваться, важно чтобы это было экономически обоснованно. Когда законы не предполагают ответственности за выбор системы АСУ — типа вы что нибудь предложите, такой ад и будет по финансам в отрасли.
Подождите, АСУ это многогранная вещь — там может быть как и бэкенд написанный не на МЭК, так и просто система с HMI контроля и управления, в лучшем случае со SCADA, так и вообще железный ПАЗ на релюшках) Все эти уровни абстракций часть АСУ. И требования к персоналу по разработке и обслуживанию у них разные.
Ну вот лично мне за 10 лет ковыряния ПЛК не нравятся урезанные IDE кучи производителей, гды ты завязан только на реализованные ими блоки. Пример из классики — типа декларативные ЯП и императивные… Мне зачастую гораздо проще написать (или применить готовые) свои обработчики RS-485 для разных типов датчиков, 4...20 входов/выходов, чем юзать не пойми что "любезно" подсунутое мне производителем. Финансово тут есть вопросы — есть компании интеграторы — там тоже не во всех адекватные труду зарплаты, а есть компании пользователи — там вообще треш по уровню зп… Потому потихоньку под менторством родственника синьора учу джаву) Реально удобство IDE для джавы и IDE для пром программирования это небо и земля.
Ну вообще академически есть 3 сущности - 1. Противоаварийка, 2. Контроль и управление, 3. Мониторинг и диагностика неисправностей. Вы описываете 3ю совмещенную со 2й: важна же суть сообщения, а не ее интерпретация- или текст или графика… Для отображения информации есть неплохой стандарт ISA 101.01 /zanudaModeOff
Вот интересно сколько в стране (РФ) водоканалов оборудованы датчиками pH в отгружаемой воде, это пол дела… Другой вопрос что, например, в РФ качество воды считается на границе выхода с водозабора, что туда могут прилить дальше это не его зона ответственности… Соответственно поэтому водоканал у нас не отвечает за качество воды в кране…
С наступающим всех!
Для сложных случаев уже необходимо синтезировать совмещенные системы.