Всем привет!

Требуется разработать сетевую карту PCI –> 100BASE-T Ethernet. Необходимо реализовать однонаправленную передачу данных на аппаратном уровне.
К карточке нужно будет обращаться по локальной сети с определенной периодичностью и забирать переменные в базу данных.

Товарищи, подскажите в каком направлении двигаться для составления структурной схемы и ТЗ дальнейшем.
Какие компоненты и интерфейсы лучше выбрать из всего многообразия?

Заранее благодарю за дельные советы.

???
Многие протоколы требуют наличия подтверждения правильности приема пакета. Поэтому передача не однонаправленная, трафик в разных направлениях сильно отличается.

Ну так берем микросхему Ethernet-контроллера с шиной PCI, к ней трансформатор и резисторы...
Хотя бы Микрел KSZ8841 с буквами для PCI или что-то в этом роде...

Можно ли реализовать проверку пакетов на промежуточном контроллере между pci и ethernet? Или использовать отдельную микруху памяти доступ на запись к которой будет только со стороны PCI. Возможно такое?

UDP как вариант - работает без проверки.

2iosifk

Тогда получится программная реализация. Вопрос в аппаратном уровне "однонаправленности".

Аппаратный контроллер протокола? А зачем это нужно?
Возьмите микропроцессор KS8695PX - у него с одной стороны PCI с другой - Ethernet. В микропроцессоре будет Линукс для обработки пакетов верхних уровней протокола...
А делать аппаратный обработчик протокола? Зачем?

Таким образом получится аппаратный фаервол. Проще купить его тогда, чем собрать. Но как мы знаем и они не дают 100% надежность.

http://ancud.ru/products/diod.htm
Как заявляет производитель, осуществляется гарантированная односторонняя передача данных. Вот это ближе к делу, но по ряду причин эта железяка не подходит.

А если использовать не мост PCI-ETh, а включится снаружи. Сделать устройство ETh-ETh. Берём две микрухи с MII, и соединяем их этими интерфейсами в одну сторону, TXD одной на RXD второй, а TXD второй на RXD первой не соединяем!?
И дешево и сердито.

Сердитей по ком-порту )

Это не совсем то, что нужно. Тем не менее, так вообще возможно организовать работу?
Тогда сетевая карта должна работать по протоколу без подтверждения. Понадобиться только прикладное ПО для карточек написать?

UDP протокол, вы же сами писали что он без подтверждения работает.
Смотрим на каком кристалле сделана сетевая, достаем документацию на этот чип (самое сложное) и пишем прикладное ПО.
По сом порту сердитей, но не далеко метров 5-10ть.)

А возможна ли работа подобного процессора с PCI-шиной в одном направлении? Если с этой стороны подобраться?




А кто-нибудь сталкивался с подобным? Есть что почитать?
Либо, как вариант, можно проектировать свою, с любым удобным чипом.

PCI шина двунаправленная, по стандарту. чтобы инициализировать любое PCI устройство придется с ним вести определенный протокольный обмен...



о какой надежности идет речь?

Надежность в плане защиты информации.

и каким образом (методика) эта надежность оценивается ? экспертное заключение ?

Вообще есть служба ФСТЭК. Она выдает сертификаты.

В моем случае я бы сказал - "на глаз". Любой фаервол по-моему можно "сломать" при определенном желании.
А я хочу получить простое (в т.ч в дальнейшем обслуживании) и надежное устройство.

то есть Вы "верите" что фаервол (iptables, к примеру, с открытым кодом) может содержать уязвимость при правиле DROP на все входящие данные (таблица INPUT) ? или ФСТЭК верит ?

Понятия не имею. Я что-то на своём опыте не хочу проверять. А если зловредное ПО?
Нет возможности содержать админа для настройки и вообще там должна стоять винда.

Буду спокойно спать, если это будет железная защита. В прямом и переносном смысле.

SFx, вы согласитесь со мной?

OMG , Винда! (((((
Вероятность того что iptables зловредное ПО в тысячи раз ниже чем зловредная Винда...

кроме того, код функций обработчиков INPUT -j DROP в iptables можно проаудировать...

Зачем такие штуки то вообще нужны? Технология Стелс? а контроль целостности данных? даже в оптическом кабеле может битовая ошибка, не считая самих трансиверов....

Нужно подключить OPC-сервер предприятия к БД. Здесь должен быть шлюз.

Особых требований к целостности нет пока. Взять дискретность с запасом. Если отвалится часть информации - ничего. Опять же расстояние и куча оборудования: медиаконвертеры, свичи. Думаю, только на практике будет понятно.

Собственно, может другим путём пойти? Если необходимость есть в обработке протоколов, а с чипом для PCI не получится в одном напралении.. Может тогда другие шины попробовать? COM-порт, LPT. Как считаете? Ethernet в конце концов, как предложил vadimp61 .

Вообще, я рассчитывал, что это будет проще. Почему не сделать отдельно контроллер PCI, отдельно контроллер или микропроцессор для Ethernet со всем необходимым на борту (Линукс)? А между ними обеспечить поток данных в одном направлении. Например, через память, если к ней можно будет обращаться таким образом или через еще один микроконтроллер.
В итоге получаем почти нормальную сетевую карту. Качество связи, удобство в работе.

Что скажете?

Скорость то какую нужно?

микроконтроллер врят-ли обеспечит 100 мегабит.. хорошо если 10 только...

Делайте тогда фильтрацию по МАС адресам на программируемой логике типа ALTERA.

пойдет!

всего 600 переменных типа real. 40Кбит/с более чем достаточно. К тому же их можно растянуть на несколько секунд =)

это точно делать лучше на Ком-Порте (usb2com) тогда. проще и дешевле.
если только никакая гальваническая развязка не нужна... или канал - медь.

Это некая иллюзия. А откуда уверенность, что в той реализации софта нет бага, из-за которого этот софт можно "сломать" и получить обратный доступ? Простые фаерволы обычно ломаются за счет ошибок именно в реализации стека. То есть Вам понадобится для этой задачи специально переписанный UDP стек "в одну сторону".

То есть совсем без софта на плате??? Или под софтом понимается ПО на Винде?
Коробочка роутера (хоть Cisco, хоть D-Link) - это софт или хард? Так ведь ломают и те и другие...

И вам на ваше решение нужен сертификат ФСТЭК? Если да - то купить готовое будет на порядки дешевле.

Не понял зачем фильтрация.




Т.е usb -> com -> Eth ? Можно чуть подробней?
Или вы имеете ввиду связать 2 компьютера через com-порт? Ethernet нужен, т.к надо связаться через локальную сеть.


Я не электронщик по профессии, но вроде довольно ясно изложил свои требования. Если вы прочитаете тему, то поймете, что устройство независимо от прикладного софта, должно обеспечивать однонаправленную передачу данных. В каком именно месте это сделать и как я пытаюсь выяснить.

Насколько я понимаю, UDP-протокол как раз и есть "в одну сторону".


Я писал выше:
"Вообще, я рассчитывал, что это будет проще. Почему не сделать отдельно контроллер PCI, отдельно контроллер или микропроцессор для Ethernet со всем необходимым на борту (Линукс)? А между ними обеспечить поток данных в одном направлении."




Давайте про эту службу забудем вообще. Я её для примера привел. Мне от них ничего не надо.



Я бы рад купить. Но мой поиск не принес результатов.
Подобные решения обычно программные.

USB->Com->TX pair only->COM->USB.
но это все телепатия.

Вы напишите нормальное описание задачи. Какая инфраструктура, ОС, коммутаторы, роутеры, среда ( оптика/медь/радио ), расстояния, допустимые интерфейсы с PC, шифрование.


сделать то можно что угодно, только цена будет иметь значение. и напишите цену, которую вы готовы заплатить (10тр-100тр-1млн). может то что вы хотите даже не возможно в принципе ? телепаты в отпуске.

http://www.moxa.ru/good/show/14885/17070/ может такое даже?

Ну так чего проще - взять стандартную PCI-Ethernet плату и перерезать нужную дорожку (Tx или Rx петлю соответственно).
Замкнуть программно перерезанную дорожку - почти невыполнимая задача.

Не уверен, что в этом случае свитч или карточка "признает" наличие активного лика - несущей-то не будет.

Итак, еще раз.

Соединяем OPC-сервер (4 шт.) с базой данных по локальной сети. Требуется шлюз с однонаправленной передачей данных. Он должен быть на стороне OPC и обеспечивать передачу в БД. В компах обычные АТХ матери, соответственно
доступные интерфейсы: COM, LPT, USB, Ethernet, PCI, PCIex.
OC: WinXP.
Сеть: Медь-оптика-медь (полный список оборудования выяснить тяжело)
Шифрование не требуется.
Нужна гальваническая развязка, скорость не менее 40 Кбит/с, поддержка TCP, возможность написания собственного прикладного ПО.
Цена. Думаю 2-3 тр за шт найдем без проблем. Если потребуется разработка и цена перевалит за 50тр – тоже можно.

Осталось добавить, что в это описание можно внести обоснованные изменения по некоторым позициям.

По цене лучше вы меня сориентируйте. Можно за такую сумму разработать и изготовить?



Подобное устройство как раз видел на местной рекламе в Стартеркит.
Видимо на чем-то таком и надо будет остановиться - сильно дороже разработка для PCI.
Насколько надежна будет передача в одном направлении, если использовать com-порт без Тх?


Всё таки я склоняюсь к протоколу с подтверждением. Делать, так сразу нормально.

50 тыщ -это зп инженера на месяц без налогов. в эту сумму разработку вы 100% не уложите. потому что есть материальные затраты, типа печатных плат, компонентов и т.п.
ну или студента нанять... который не сделает ничего хорошего... разработка нормальная стоит от миллиона. и длится может до года, в зависимости от колличества глупостей, написанных в ТЗ.

речь идет о поддержки TCP до самого устройства ? а дальше однонаправленная передача ?


скорость usb2com может достигать 2х мегабит/c - вы можете одни и теже данные хоть 10 раз отправить.
самое ненадежный канал - тот что длиннее.


как можно сделать однонаправленную передачу с подтверждением ? (а вдруг подтверждения хакнут ? :-D )


если взять сетевуху оптическую - то признает.

между OPC и шлюзом односторонняя. Просто отправляем данные на com-порт.



через COM отправляем данные. На этом канале откусываем ногу Тх ))

Вот режимы работы устройства:
Виртуальный COM-порт
TCP Server
TCP Client
UDP Server/Client

Я понимаю, что преобразователь реализует TCP/IP на своём CPU и таким образом мы получаем желаемое.

Дерзайте.

Ну тогда берется 2-волоконный медиаконвертер с оптики на медь и не подключается приемный разъем.

нуда типа того)

Ну так постройте ОТДЕЛЬНУЮ локалку от 4-х серверов и компа с БД. Или к БД обращаются из другого города по Internet? Если нет, то кто тогда может ее хакнуть непонятно?

Одобряете?


Попробуем с com-портом для начала.


Да, локалкой не обойдешься. К тому же расстояния. Не зря между ними оптика.

Спасибо всем, принявшим участие в обсуждении! Столько людей откликнулось.

Устройство должно было реализовать шлюз внутри себя. А так возникает вопрос в электрической части com-порта =) Похожа ли она на транзисторную или если перебрать драйвер этого порта, то можно писать данные на любую линию?
Может быть новую тему открыть?

Трудозатраты на реализацию выше, чем с одним отрезанным оптическим линком

Снова здравствуйте!
Покритикуйте схему в том же контексте.

Eth -> МК -> SPI ->(Опторазвязка только на 3 линии:MOSI,SCLK,SS)-> SPI -> МК -> Eth.

Минимум действий: всё, что прилетело в Ethernet отправилось на Ethernet c другой стороны. В каждом МК обработка протоколов верхнего уровня, TCP/IP работает, связь между сетками в одну сторону.

PS. Медиаконвертеры не хотят работать без Rx. Если только карточку с FlowControl, но у меня такой не нашлось.

http://www.altx-soft.ru/groups/page-269.htm



P.S. Цена вопроса 50 т.р.

Мда. Безумству храбрых, как говорится.

Берем карту (свич), отключаем на ней функцию Auto-MDIX (так же неплохо смотрится какая-нибудь древняя карта без этой фичи) и переводим ее в 10МБит. Пару TX на стороне приемника, естественно отрываем, а в линию в направлении к внешнему миру, дабы на другой стороне был Link, подаем импульсы Link Pulse, которые генерируются любым удобным способом


Все

Спасибо, но работает этот комплекс только с файлами и директрориями. И это UDP протокол.





И это UDP получится. Хотя суровое решение. Главное, что бы карточка не поменяла направление случайным образом при обновлении драйвера, например.

А других с односторонней передачей не получится.



Можно карту с отдельным PHY (очень часто в современных матерях) и обрезать TXD на уровне PHY-EMAC.

Если уж очень хочется что-то разработать, то возьмите две микросхемы PHY KSZ8041TL и включите их в режиме жопка-к-жопке (Back-To-Back) с разрывом одной из связи TXD-RXD. Подробности в даташите.

Чем вам не нравится тоже самое, только с двумя контроллерами?

Деталей много Опять же, много лишнего софта, вряд ли Вы его нормально напишите. А ведь Вы хотите

А как можно заставить работать такое решение с коммутатором? Широковещательными пакетами?

Всё таки, подскажите, какой интерфес можно использовать для связи контроллеров между собой кроме SPI? Он удобен для опторазвязки. Может взять контроллеры с двумя MII? Один для ethernet, другой - для связи с МК.

Хочу попробовать на отладочных платах. Надо определиться с выбором.

SergeyMak, пишите в личку. У меня есть наработки по данному вопросу.