Добрый день! Как вы обнаржили эту особенность и как обучались в школе? Интересно то, что ваша профессия очень требовательна к восприятию текста, и вы к этому адаптировались, что вызывает уважение. Спасибо что поделились своей историей.
Да, именно так. Честно говоря, все мы думали также, но приходилось ковырять самостоятельно, и это приносило плоды. Обучение это процесс поиска, именно процесс, усвоение через опыт. По сути, подход с применением ИИ лишает молодых людей усваивать информацию. Таков современный мир, а мы будем наблюдать!
Дискомфорт, это как защитная реакция мозга, что он деградирует, и не работает. Раньше готовили доклады в библиотеках, реально сами искали материал, переписывали, потом еще надо было защитить написанное, и не было ни какого дискомфорта)
Рынок меняется, ни кто не знает, что будет дальше, а дальше будет баланс, всегда наступает равновесие, по аналогии с морем после шторма. Пока что ИИ, это кот в мешке, на поверхности все хорошо, а что внутри, время покажет, ну и не забывайте про хайп, весь Хабр забит статьями про ИИ!
Для меня мой проект, это в первую очередь стенд для отработки навыков и изучения новых технологий, которые новые только для меня Интерес есть, когда есть идея, и ты к ней идешь, реализуешь, пишешь, соображаешь архитектуру, далее новая идея. Так это работает у меня. Иногда думаю и проектируют архитектуру на работе. Дома уже пишу код. И да, это почти каждые день, когда есть время. Когда идея собирается и компилируется, вот тут полный кайф). Самое интересное, что я не разработчик.
СБ обычно решает своюи задачи - чтобы всё было максимально тихо и предсказуемо в ЛВС, поэтому любые сторонние инструменты воспринимаются настороженно. АСУ-службы не всегда находятся в позиции, где можно диктовать условия, особенно вне большого производства. Приходится работать с тем, что есть.
Да, очень знакомая история. У нас ситуация была похожая - инструкция есть, а по факту данные лежат совсем не там. В итоге тоже шли вслепую, анализ ответов прибора + перебор адресов. Modbus Poll в таких случаях реально может выручить, это быстрее, чем пытаться добиться нормальной документации или ответа от поддержки, кто на что горазд!
Обычно работаешь с тем, что уже установлено или установили: разные версии, поставщики и не всегда актуальная документация. Техподдержка, к сожалению, тоже не помогла. Поэтому пришлось разбираться по фактическим ответам прибора. В целом Вы правы на счет техподдержки.
Wireshark это первое, что приходит в голову. Но в реальности не всегда есть возможность его быстро развернуть. В нашем случае были ограничения по ОС, драйверам и политике ИБ на рабочем ноутбуке. Поэтому пошли от задачи сделалав минимальный сниффер под конкретный протокол и получили результат быстрее, чем настраивали бы инструмент. Не всегда есть возможнсть сделать правильно.
Имею в виду обычные внутренние регламенты по ИБ. В рабочей сети не используем инструменты перехвата трафика. Поэтому в таких задачах проще работать локально с устройством.
Я не перехватывал трафик в ЛВС. Работали локально - прибор был отключён от сети, подключились к нему напрямую с ноутбука. У нас требования ИБ жёсткие, поэтому никакого перехвата в сети не делали.
Да, такой подход нормальный, сам с него начинал. Но он не всегда срабатывает - если данные лежат вне ожидаемой области или отдаются по специфическим командам. У меня как раз так и было, поэтому пришлось анализировать обмен заводского ПО.Кстати, раньше в документации был указан адрес начала области памяти, где лежат нужные регистры, в новых версиях это описание убрали.
Спасибо за обратную связь. Да, идея с группировкой регистров и более аккуратной работой с таймаутами разумна, особенно с тамймаутам, можно просто положить систему на них. Подход с общим диспетчером тэгов тоже понятен. В сторону OPC UA я тоже смотрю - это уже де-факто современный стандарт, но для текущего этапа пока хочу сначала довести Modbus/MQTT runtime логику.
Спасибо за развёрнутый комментарий. Подход интересный - по сути, это уже отдельный слой сбора и доставки данных перед самой SCADA. Вполне возможно, что в будущем по такой схеме можно будет выделить отдельные модули.
Спасибо, мысль отличная. Чтение диапазонами выглядит намного логичнее. Нужна чёткая карта регистров и корректно разбирать полученный блок по диапозонам. Буду думать, как это аккуратно встроить в текущую архитектуру. Кстати, тут как раз был опыт поиска данных в памяти прибора ТЭМ104 🙂
Добрый день! Как вы обнаржили эту особенность и как обучались в школе? Интересно то, что ваша профессия очень требовательна к восприятию текста, и вы к этому адаптировались, что вызывает уважение. Спасибо что поделились своей историей.
Да, именно так. Честно говоря, все мы думали также, но приходилось ковырять самостоятельно, и это приносило плоды. Обучение это процесс поиска, именно процесс, усвоение через опыт. По сути, подход с применением ИИ лишает молодых людей усваивать информацию. Таков современный мир, а мы будем наблюдать!
Дискомфорт, это как защитная реакция мозга, что он деградирует, и не работает. Раньше готовили доклады в библиотеках, реально сами искали материал, переписывали, потом еще надо было защитить написанное, и не было ни какого дискомфорта)
Рынок меняется, ни кто не знает, что будет дальше, а дальше будет баланс, всегда наступает равновесие, по аналогии с морем после шторма. Пока что ИИ, это кот в мешке, на поверхности все хорошо, а что внутри, время покажет, ну и не забывайте про хайп, весь Хабр забит статьями про ИИ!
Для меня мой проект, это в первую очередь стенд для отработки навыков и изучения новых технологий, которые новые только для меня Интерес есть, когда есть идея, и ты к ней идешь, реализуешь, пишешь, соображаешь архитектуру, далее новая идея. Так это работает у меня. Иногда думаю и проектируют архитектуру на работе. Дома уже пишу код. И да, это почти каждые день, когда есть время. Когда идея собирается и компилируется, вот тут полный кайф). Самое интересное, что я не разработчик.
СБ обычно решает своюи задачи - чтобы всё было максимально тихо и предсказуемо в ЛВС, поэтому любые сторонние инструменты воспринимаются настороженно. АСУ-службы не всегда находятся в позиции, где можно диктовать условия, особенно вне большого производства. Приходится работать с тем, что есть.
Да, очень знакомая история.
У нас ситуация была похожая - инструкция есть, а по факту данные лежат совсем не там. В итоге тоже шли вслепую, анализ ответов прибора + перебор адресов.
Modbus Poll в таких случаях реально может выручить, это быстрее, чем пытаться добиться нормальной документации или ответа от поддержки, кто на что горазд!
Обычно работаешь с тем, что уже установлено или установили: разные версии, поставщики и не всегда актуальная документация. Техподдержка, к сожалению, тоже не помогла. Поэтому пришлось разбираться по фактическим ответам прибора. В целом Вы правы на счет техподдержки.
Wireshark это первое, что приходит в голову. Но в реальности не всегда есть возможность его быстро развернуть. В нашем случае были ограничения по ОС, драйверам и политике ИБ на рабочем ноутбуке. Поэтому пошли от задачи сделалав минимальный сниффер под конкретный протокол и получили результат быстрее, чем настраивали бы инструмент. Не всегда есть возможнсть сделать правильно.
Имею в виду обычные внутренние регламенты по ИБ. В рабочей сети не используем инструменты перехвата трафика. Поэтому в таких задачах проще работать локально с устройством.
Понял. А какой у вас был ПЛК? Хочется глянуть, как у него устроена память.
Я не перехватывал трафик в ЛВС. Работали локально - прибор был отключён от сети, подключились к нему напрямую с ноутбука. У нас требования ИБ жёсткие, поэтому никакого перехвата в сети не делали.
Да, такой подход нормальный, сам с него начинал. Но он не всегда срабатывает - если данные лежат вне ожидаемой области или отдаются по специфическим командам. У меня как раз так и было, поэтому пришлось анализировать обмен заводского ПО.Кстати, раньше в документации был указан адрес начала области памяти, где лежат нужные регистры, в новых версиях это описание убрали.
Спасибо за обратную связь. Да, идея с группировкой регистров и более аккуратной работой с таймаутами разумна, особенно с тамймаутам, можно просто положить систему на них. Подход с общим диспетчером тэгов тоже понятен. В сторону OPC UA я тоже смотрю - это уже де-факто современный стандарт, но для текущего этапа пока хочу сначала довести Modbus/MQTT runtime логику.
Спасибо за развёрнутый комментарий. Подход интересный - по сути, это уже отдельный слой сбора и доставки данных перед самой SCADA. Вполне возможно, что в будущем по такой схеме можно будет выделить отдельные модули.
Спасибо, мысль отличная. Чтение диапазонами выглядит намного логичнее. Нужна чёткая карта регистров и корректно разбирать полученный блок по диапозонам. Буду думать, как это аккуратно встроить в текущую архитектуру. Кстати, тут как раз был опыт поиска данных в памяти прибора ТЭМ104 🙂