Плотный проект - это круто! И это несомненно будет работать, но не долго. Через небольшое время, камера покроется слоем пыли, а сетевой диск отвалится и оператор не нажмет кнопку. И так далее. В вашей модели в основе - "костыли", которые "подпирают" процесс, но не автоматизируют. Автоматизация предполагает унификацию, сокращение участков обработки информации, упрощение, отказ от промежуточных блоков обработки, что ведёт к надёжности и возможности запустить линейные и цикличные процессы в автоматическом или автоматизированном режиме (надеюсь понимаете в чем разница) и уже потом отказ от оператора или максимальное снижение зависимости от действий оператора. Не просто так учат в университетах отдельно на промышленную автоматизацию и там нет Pyton, потому что он там не нужен (медленно и не надёжно, требует больших ресурсов для вычисления, что недопустимо для процессов). То, что вы сделали подходит для проведения исследований и переноса этого алгоритма на автоматизацию через ПЛК.
А в чем проблема использовать конвейерные весы? Зачем делать такой сложный механизм анализа? В производстве, если вы делаете высокую точность, 1 минута - это очень много. PID регуляторы отрабатывают порой миллисекунды и крутятся на ПЛК. Да, возможно я не понял суть задачи и мы делали что-то похожее, но так или иначе потом переносили софтовые решения на железо. Иметь кусок программы (для управления, а не для статистики и анализа) в производственном цикле - это огромный риск. Но, если описанный технологический процесс не имел вообще никакой автоматизации, то да, временно, таким сложным, софтовым решением можно закрыть эту "дыру".
Я просто не понимаю, как микросервисы, web и Pyton ассоциируются с надёжностью, доступностью, отказоустойчивостью на уровне промышленной автоматизации? А уж тем более файлы на сетевом диске!
Очень интересные размышления. Главное - актуальные. Предлагаю рассмотреть оба варианта, но с другой стороны. Сделать вообще распределенную систему умного дома, в которой локальные контроллеры самостоятельные единицы и не привязаны к софтверной логике, они могут работать не зависимо от локального сервера (при потере связи с ним). Локальный сервер - это больше визуализация и объединение данных + комплексное управление. Облако - в большей мере - это удалённый доступ без каких либо сокетов, которые отвечают за управление, визуализация и ограниченное управление. Как показывает практика промышленной автоматизации - лучше всего иметь распределены системы. Они как правило надёжнее и не влияют на соседние процессы. Это мои мысли, но возможно они будут полезны.
Плотный проект - это круто! И это несомненно будет работать, но не долго. Через небольшое время, камера покроется слоем пыли, а сетевой диск отвалится и оператор не нажмет кнопку. И так далее. В вашей модели в основе - "костыли", которые "подпирают" процесс, но не автоматизируют. Автоматизация предполагает унификацию, сокращение участков обработки информации, упрощение, отказ от промежуточных блоков обработки, что ведёт к надёжности и возможности запустить линейные и цикличные процессы в автоматическом или автоматизированном режиме (надеюсь понимаете в чем разница) и уже потом отказ от оператора или максимальное снижение зависимости от действий оператора. Не просто так учат в университетах отдельно на промышленную автоматизацию и там нет Pyton, потому что он там не нужен (медленно и не надёжно, требует больших ресурсов для вычисления, что недопустимо для процессов). То, что вы сделали подходит для проведения исследований и переноса этого алгоритма на автоматизацию через ПЛК.
А в чем проблема использовать конвейерные весы? Зачем делать такой сложный механизм анализа? В производстве, если вы делаете высокую точность, 1 минута - это очень много. PID регуляторы отрабатывают порой миллисекунды и крутятся на ПЛК. Да, возможно я не понял суть задачи и мы делали что-то похожее, но так или иначе потом переносили софтовые решения на железо. Иметь кусок программы (для управления, а не для статистики и анализа) в производственном цикле - это огромный риск. Но, если описанный технологический процесс не имел вообще никакой автоматизации, то да, временно, таким сложным, софтовым решением можно закрыть эту "дыру".
Я просто не понимаю, как микросервисы, web и Pyton ассоциируются с надёжностью, доступностью, отказоустойчивостью на уровне промышленной автоматизации? А уж тем более файлы на сетевом диске!
Понравился фрагмент "Раньше тела из самолётов просто сбрасывали наружу", понимаю что очепятка, но улыбнуло.
Очень интересные размышления. Главное - актуальные. Предлагаю рассмотреть оба варианта, но с другой стороны. Сделать вообще распределенную систему умного дома, в которой локальные контроллеры самостоятельные единицы и не привязаны к софтверной логике, они могут работать не зависимо от локального сервера (при потере связи с ним). Локальный сервер - это больше визуализация и объединение данных + комплексное управление. Облако - в большей мере - это удалённый доступ без каких либо сокетов, которые отвечают за управление, визуализация и ограниченное управление. Как показывает практика промышленной автоматизации - лучше всего иметь распределены системы. Они как правило надёжнее и не влияют на соседние процессы. Это мои мысли, но возможно они будут полезны.