Вопрос к гуру (многопоточное приложение + сетевой доступ к устройствам)
Добрый день. Я новичек на этом форуме, да и в .NET вцелом. Занимаюсь программированием промышленных контроллеров, иногда пишу на VC++ 6, да и по образованию программист (но сейчас не об этом). В данный момент курю Троелсона по С# - читается на одном дыхании, но есть вопросы, которые не решаются прочтением похожих книг. Поэтому я здесь, спросить у вас - опытных людей.
Есть задача. Имеется площадка (склад) с 30-ью датчиками, которые подключены к модулю ввода, который в свою очередь через преобразователь интерфесов RS485->Ethernet подключен к LAN. Есть кары которые ездят по складу, на них стоят датчики RFID, которые ориентируются по меткам в полу. Датчики на каре через WI-FI так же выходят в сеть. Есть комп оператора (2-х ядерный коре) - довольно шустрый. Так вот на этом компе будет софт написаный на шарпе, который будет анализировать данные с датчиков площадки и кар, принимать некие решения и вести протоколы средствами ADO.NET на MySQL. Собственно у меня как раз архитектурный вопрос касаемый принципов создания приложения и возможностей .NET.
Все датчики надо опрашивать всё время (в некотором цикле). Самый правильный способ, по-моему мнению, это создать 4 потока:
- в первом цикл опроса всех датчиков площадки
- во втором цикл опроса датчиков со всех кар
- в третьем анализ информации собранной в первых двух потоках и вывод ее оператору + запись в бд
- четвертый поток для интерфейса программы (чтобы типа не висела, а могла отрабатывать нажатие кнопок, перерисовку формы).
Вот такое видение... В связи с этим несколько вопросов к Вам:
1. Реально ли такую многопоточку реализовать в этой среде?
2. Насколько быстро приложение получит данные от сенсоров? Считывание с датчиков будет происходить примерно каждые 100 мс. Смогу ли я добится хорошей оперативности реацкии в потоках?
Заранее спасибо. У кого есть что сказать и/или есть вопросы - не стесняйтесь, буду мониторить тему постоянно.
Есть задача. Имеется площадка (склад) с 30-ью датчиками, которые подключены к модулю ввода, который в свою очередь через преобразователь интерфесов RS485->Ethernet подключен к LAN. Есть кары которые ездят по складу, на них стоят датчики RFID, которые ориентируются по меткам в полу. Датчики на каре через WI-FI так же выходят в сеть. Есть комп оператора (2-х ядерный коре) - довольно шустрый. Так вот на этом компе будет софт написаный на шарпе, который будет анализировать данные с датчиков площадки и кар, принимать некие решения и вести протоколы средствами ADO.NET на MySQL. Собственно у меня как раз архитектурный вопрос касаемый принципов создания приложения и возможностей .NET.
Все датчики надо опрашивать всё время (в некотором цикле). Самый правильный способ, по-моему мнению, это создать 4 потока:
- в первом цикл опроса всех датчиков площадки
- во втором цикл опроса датчиков со всех кар
- в третьем анализ информации собранной в первых двух потоках и вывод ее оператору + запись в бд
- четвертый поток для интерфейса программы (чтобы типа не висела, а могла отрабатывать нажатие кнопок, перерисовку формы).
Вот такое видение... В связи с этим несколько вопросов к Вам:
1. Реально ли такую многопоточку реализовать в этой среде?
2. Насколько быстро приложение получит данные от сенсоров? Считывание с датчиков будет происходить примерно каждые 100 мс. Смогу ли я добится хорошей оперативности реацкии в потоках?
Заранее спасибо. У кого есть что сказать и/или есть вопросы - не стесняйтесь, буду мониторить тему постоянно.
1. Да реально - по крайней мере теоретически это должно работать стабильно.
2. Вы не можете контролировать этот процесс, если в качестве среды работы будете использовать MS Windows. Данная ОС не является системой реального времени. Но периоды порядка 100 мс вполне могут обрабатываться в системе, т.е. реактивность будет вполне достаточной. По имеющимся наработкам, в такой временной зазор позволяет работать как оператору, так и опросу. По крайней мере, датчики бункера загрузки в бетонный узел вполне нормально обслуживаются.
2. Вы не можете контролировать этот процесс, если в качестве среды работы будете использовать MS Windows. Данная ОС не является системой реального времени. Но периоды порядка 100 мс вполне могут обрабатываться в системе, т.е. реактивность будет вполне достаточной. По имеющимся наработкам, в такой временной зазор позволяет работать как оператору, так и опросу. По крайней мере, датчики бункера загрузки в бетонный узел вполне нормально обслуживаются.
Я не гуру в этой области, но несколько заметок для размышления.
1. Система у Вас очень сложная, я бы ее делал по частям, соствляя из нескольких более простых. Я бы сгруппировал первый и второй поток в одно приложение (сервис?), назовем его "сборщик данных", соответственно, 3ий и 4ый потоки в другое приложение, назовем его "диспетчер". Группировка позволит "физически" отделить часть, которая оперативно накапливает данные, от части, которая их хранит и обрабатывает, и от части, которая их показывает и использует (интерфейс). Первое приложение, представлется, можете спокойно реализовать на VC++ - здесь не нужен интерфейс. Делаем опрос, кладем в базу. Второе приложение делаем, например, на .NET. Связь через СУБД. Делаем запрос, получаем порцию свежих данных или любых других, какие Вы захотите за период с заданным интервалом, анализируем, если надо "принимаем некие решения". Отдельное место в этой задаче занимает время...
2. Не уверен, что Вы сможете обеспечить доступ к датчикам через сеть на уровне 100мс. Например, у меня сеть Wifi дома - ничего обсенного: AP DLINK DIR-615, два компа. ping от одного компа до другого плават от 30 до 150 мс. Аналогично Ethernet не резиновый. Скорости, конечно, на порядки выше, но... Опросить одного стройство может быть можно быстро, а опрос 30 датчиков может не уложиться во 100мс.
Про real-time внутри OS уже написали!
1. Система у Вас очень сложная, я бы ее делал по частям, соствляя из нескольких более простых. Я бы сгруппировал первый и второй поток в одно приложение (сервис?), назовем его "сборщик данных", соответственно, 3ий и 4ый потоки в другое приложение, назовем его "диспетчер". Группировка позволит "физически" отделить часть, которая оперативно накапливает данные, от части, которая их хранит и обрабатывает, и от части, которая их показывает и использует (интерфейс). Первое приложение, представлется, можете спокойно реализовать на VC++ - здесь не нужен интерфейс. Делаем опрос, кладем в базу. Второе приложение делаем, например, на .NET. Связь через СУБД. Делаем запрос, получаем порцию свежих данных или любых других, какие Вы захотите за период с заданным интервалом, анализируем, если надо "принимаем некие решения". Отдельное место в этой задаче занимает время...
2. Не уверен, что Вы сможете обеспечить доступ к датчикам через сеть на уровне 100мс. Например, у меня сеть Wifi дома - ничего обсенного: AP DLINK DIR-615, два компа. ping от одного компа до другого плават от 30 до 150 мс. Аналогично Ethernet не резиновый. Скорости, конечно, на порядки выше, но... Опросить одного стройство может быть можно быстро, а опрос 30 датчиков может не уложиться во 100мс.
Про real-time внутри OS уже написали!
ваш пинг позволяет предположить что есть проблемы либо в обжиме кабеля либо еще какие. В локальной сети из двух компьютеров пинг не может пониматься более 0.5 ms. 100 ms - приблизительно соотвествует кванту времени для процесса с нормальным приоритетом. За это время вполне проходит опрос 10-50 датчиков.
Даже для вай-фай сети 30-150 мс - это не малое значение - внешние сервера, типа майл.ру пингуются примерно в 200-300 мс.
Цитата: Kraft
1. Реально ли такую многопоточку реализовать в этой среде?
2. Насколько быстро приложение получит данные от сенсоров? Считывание с датчиков будет происходить примерно каждые 100 мс. Смогу ли я добится хорошей оперативности реацкии в потоках?
Реально. Первая мысль: большую часть времени система будет ждать ответа от датчиков, так как здесь вовлечены вай-фай и айзернет, но вопрос масштабирования не стоит закрывать.
Цитата: grgdvo
Я не гуру в этой области, но несколько заметок для размышления.
...
Первое приложение, представлется, можете спокойно реализовать на VC++ - здесь не нужен интерфейс. Делаем опрос, кладем в базу. Второе приложение делаем, например, на .NET. Связь через СУБД.
...
Первое приложение, представлется, можете спокойно реализовать на VC++ - здесь не нужен интерфейс. Делаем опрос, кладем в базу. Второе приложение делаем, например, на .NET. Связь через СУБД.
Мысль верная - нужно отделить подсистемы сбора данных от интерфейса и логики аналитики. Нужен именно сервис (демон) собирающий данные и отдельная программа для мониторинга, аналитики и т.п. Вот смысла в использовании нескольких языков/платформ (управляемый C# и нативный C++) пока не видно, но я не исключаю потребности C++ в деле создания оболочки для протокола обмена. Более того, реализуя систему в рамках .NET можно получить определенные бонусы: единый код для доступа к базе данных (реляционной или тупо к файлам), возможность прозрачного взаимодействия всех приложений посредством .NET Remoting.
Я на канале написал, что я про это думаю - на тему "отделить подсистемы сбора данных от интерфейса и логики аналитики. Нужен именно сервис (демон) ...". ИМХО сделайте для начала РАБОТАЮЩЕЕ приложение. А потом можно думать про сервис и пр. Но опять же ИМХО - а почему и зачем? Вся работа идет на уровне пользовательском - зачем сервис и т.д.? в БД писать? Оставьте это для пользовательского уровня - сервис при том не обязателен. Хотя принципиально возможнен. Регистрация события в БД и последующее чтение из нее при условии что работа допустима с уровнем 0,003-0,09 секунды
Спасибо, за рекомендации. По поводу отдельного сервиса... Самая приоритетная задача в этом проекте - максимально быстро "принять решение" на основе инфы от дачиков. А вариант с разделением на сервис сбора данных и клиентскую программу, ИМХО гораздо дольше отрабатывать будет....
Цитата: Kraft
Спасибо, за рекомендации. По поводу отдельного сервиса... Самая приоритетная задача в этом проекте - максимально быстро "принять решение" на основе инфы от дачиков. А вариант с разделением на сервис сбора данных и клиентскую программу, ИМХО гораздо дольше отрабатывать будет....
Ну вот из этого и нужно исходить. Если вопрос в скорости принятия решения (опрос-анализ), то да, в едином приложении он решается сравнительно просто.
Кстати, я нигде не говорил о коммуникации сервиса и интерфейса посредством БД. В дотнете возможно прямое взаимодействие посредством ремотинга. Но это уже "навороты".