Я Вас услышал, но мой совет из другого мира (хим оборудование) - добавьте rs 485 или 232 как вывод на панель оператора и по modbus настройки и параметры оборудования- не все будут ставить стандартные щитки и не везде их разрешено ставить, и если уберете встроенную панель, если это удешевит продукт может он и в промке найдет свое место. Это мое мнение)
Тут, на мой взгляд, есть огромный отрыв текущего образования (стандартов и инструментария которому учат) от фактической потребности рынка труда — после размещения вакансии со словами "со знанием только Компаса не беспокоить" мне позвонило за месяц 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
Я Вас услышал, но мой совет из другого мира (хим оборудование) - добавьте rs 485 или 232 как вывод на панель оператора и по modbus настройки и параметры оборудования- не все будут ставить стандартные щитки и не везде их разрешено ставить, и если уберете встроенную панель, если это удешевит продукт может он и в промке найдет свое место. Это мое мнение)
Подождите, ладно для настройки, а для эксплуатации Вы считаете что лучше открыть щиток и посмотреть что там внутри, чем поуправлять со внешней панели?
Тогда какое его исполнение по 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 в отгружаемой воде, это пол дела… Другой вопрос что, например, в РФ качество воды считается на границе выхода с водозабора, что туда могут прилить дальше это не его зона ответственности… Соответственно поэтому водоканал у нас не отвечает за качество воды в кране…
С наступающим всех!