Проектирование проводки между сервером и точкой доступа и RF с оконечным устройством
Мы собираемся разработать внутреннюю отраслевую сеть, состоящую в основном из следующего: 1 сервер, подключенный по проводам к 100 проприетарным точкам доступа RF (в основном встроенным устройствам), каждая из которых может быть подключена по радио к 100 встроенным конечным устройствам. Что-то вроде этого:
Теперь меня интересуют некоторые дизайнерские решения, которые нам необходимо принять, и я уверен, что существует множество похожих дизайнов и множество людей, имеющих опыт их использования, как хорошего, так и плохого. Может быть, ты сможешь вмешаться?
Все оконечные устройства независимы и будут передавать свои собственные уникальные данные на сервер, и наоборот. Следовательно, сервер должен иметь возможность нацеливаться на каждое оконечное устройство индивидуально. Каждое оконечное устройство соединяется с одной точкой доступа, а затем передает с ней проприетарный RF-протокол, TCP / IP здесь не вариант.
Сервер будет знать, какое оконечное устройство сопряжено с какой точкой доступа, поэтому, когда серверу необходимо разговаривать с отдельным оконечным устройством, связь должна проходить через спаренную точку доступа. Следовательно, серверу необходимо напрямую обращаться к точке доступа.
Вопрос: Учитывая ограниченные ресурсы, доступные в частной точке доступа, рекомендуется ли TCP / IP между сервером и точкой доступа для этого сценария? Или вы бы предложили что-то совсем другое?
В случае сомнений используйте IP через Ethernet. Если вы хотите использовать UDP или TCP, это совсем другая проблема. У обоих есть преимущества, но, честно говоря, я бы рассмотрел это.
Насколько стабильна ВЧ-часть? Как часто устройства повторно связываются? Если не часто, то можно довольно легко реализовать систему ленивого обучения, в которой устройство связывается, а точка доступа отправляет один кадр UDP со словами «У меня есть устройство X». Когда устройство X передает, оно может взять эти данные, обернуть их в UDP, немного пометить их некоторой информацией, говорящей, в каком слоте устройства оно находится, и т. Д., А затем передать их хосту.
Я бы не стал использовать для этого TCP. TCP имеет слишком много состояний. С UDP вам может понадобиться какой-то простой протокол отправки / подтверждения или разработать свой ум как можно ближе к мощному компьютеру, чтобы он обнаруживал и запрашивал недостающие данные или справлялся с их отсутствием.
Думали ли вы, что задать этот вопрос в «списке изображений», который полон очень умных типов ИБ?
8051 - очень старый и маленький микроконтроллер. У вас могут возникнуть трудности с внедрением IP-стека на нем в зависимости от требуемых функций. Я также мог бы предположить, что он недостаточно мощный, если, конечно, вы не реализуете его на более высокой тактовой частоте в fpga. При этом использование IP в значительной степени предрешено из-за маршрутизатора и элементов коммутатора, которые есть в вашей топологии. IP легко маршрутизировать, Ethernet легко переключать, а с помощью стека IP-протоколов легко запрограммировать все промежуточные протоколы управления / данных от сервера до точки доступа. Единственный раз, когда это не подходит, если точка доступа просто не имеет вычислительной мощности для обработки мультиплексирования передаваемых RF данных от 100 устройств в один поток tcp / udp или не может обрабатывать сотню tcp / udp. поток (более вероятный сценарий).
Мой инстинкт подсказывает, что в этом примере микроконтроллер 8051 не справляется с этой задачей, поэтому, если вы хотите использовать этот микроконтроллер для точки доступа и у вас нет более быстрого управляющего процессора, вам может потребоваться добавить уровень косвенного обращения. после коммутатора Ethernet, как узел управления, чтобы можно было использовать прямой последовательный протокол с точкой / устройствами доступа. Если скорость передачи данных очень низкая и вы можете жить с UDP, это может быть выполнимо.