Сеть CAN: популярные прикладные протоколы

   
А. Щербаков
Сеть CAN: популярные прикладные протоколы

Выпущенный из недр автомобилестроительных лабораторий полторадесятка лет назад, джин CAN-технологий (CAN — Controller Area Network) стремительно проникает буквальново все сферы человеческой деятельности — от домашнего хозяйства до орбитальных космических станций. Общеечисло CAN-сетей, которые будут установлены в мире в текущем году, по прогнозам ассоциации CiA (CAN inAutomation, ) должно составить около 83 млн. (против 11млн. в 96 году), а в 2000 году — превысить 125 млн. На родине CAN-технологий — в Германии — CAN-шинаустойчиво держит первое место по популярности на фоне всех прочих стандартов полевых шин.
    Среди многочисленных факторов, обеспечивших взлет популярности CAN в последние годы,следует отметить разнообразие элементной базы CAN (от десятков ведущих производителей полупроводников — Intel,Philips, Siemens, Motorola и др.), ее дешевизну (простейшие устройства ввода/вывода — CAN SLIO (2.0А) стоятменее доллара), гарантированную доступность в течение не менее 10 лет. Это высокая степень и надежности, и“живучести” сети благодаря развитым механизмам обнаружения ошибок (одна незамеченная ошибка за тысячу летпри ежедневной 8-часовой работе сети на скорости 500 кбит/с), повтору ошибочных сообщений, самоизоляциинеисправных узлов, иммунитету к электромагнитным помехам. Немалую роль играет и возможность поддержкиразнотипных физических сред передачи данных — от дешевой витой пары до оптоволокна и радиоканала. А рядоригинальных механизмов сетевого взаимодействия (мультимастерность, широковещание, побитовый арбитраж) всочетании с высокой скоростью передачи данных (до 1 Мбит/с) способствуют эффективной реализации режимареального времени в системах распределенного управления.
    Однако сетевых сервисов спецификации Robert Bosch CAN Specification 2.0A/B имеждународного стандарта ISO 11898 зачастую явно недостаточно для эффективной разработки CAN-сетей. Дело втом, что упомянутые документы описывают лишь два самых нижних уровня эталонной (семиуровневой) моделивзаимосвязи открытых систем OSI/ISO — физический и канальный (рис. 1). Определены форматы сообщений,процессы передачи данных длиной до 8 байт, механизмы обнаружения ошибок, некоторые физические параметрысреды передачи данных (только в ISO 11898) и др. Но “за кадром” остаются такие важные на этапе разработкимоменты, как адресация узлов, распределение между ними CAN-идентификаторов, интерпретация содержимого фреймаданных, передача данных длиной более 8 байт и др. Поэтому с началом массового выпуска CAN-компонентов иширокого распространения CAN-приложений рядом независимых компаний и некоммерческих ассоциаций в областисистем промышленной автоматизации, транспорта и т. д. проводилась (и продолжается по сей день) работа посозданию и стандартизации спецификаций протоколов верхнего уровня — HLP (Higher Level Protocol) дляCAN-сетей.

Рис. 1. Эталонная модель OSI/ISO и спецификации CAN

Как правило, большинство существующих на сегодня CAN HLP имеетсжатую трехуровневую архитектуру (рис. 1), включающую два базовых уровня (физический, часто дополненный болееконкретными спецификациями, и канальный) CAN-протокола и прикладной. Сервисы промежуточных уровней либоотсутствуют, либо включены в него. Уменьшенное число уровней против полных семи позволяет обеспечитьпредсказуемость задержек прохождения сообщений в сети и повысить ее производительность в режиме реальноговремени.
    При разработке CAN-приложений на базе стандартных прикладных протоколов разработчикполучает в руки уже готовые механизмы передачи данных любой длины, процедуры начальной инициализации,распределения идентификаторов и т. п. Появляется возможность простой интеграции стандартных модулейнезависимых производителей и наращивание сети в будущем, а так-же максимально полной реализации основныхпреимуществ CAN протокола, особенно при работе в режиме реального времени. И наконец, многочисленные группыи ассоциации пользователей и производителей оборудования под те или иные прикладные протоколы, широкопредставленные в Интернете множеством сайтов, значительно облегчают нелегкую жизнь системного разработчика.
    К настоящему времени известно уже более четырех десятков CAN HLP. Среди подобногомногообразия CAN HLP наибольшее распространение, в особенности в системах промышленной автоматизации,получили четыре, поддерживаемых ассоциацией CiA и рассмотренных ниже. Это CAL/CANopen, CAN Kingdom,DeviceNet и SDS (Smart Distributed System).

CAL/CANopen

Разработка и поддержка открытого протокола прикладного уровнядля сетей промышленной автоматизации были одними из приоритетных целей создания организации CiA в 1992 году.Основой такого протокола послужил HLP, разработанный фирмой Philips, после доработки и усовершенствованиякоторого рабочей группой CiA, в 1993 году была опубликована спецификация CAL — CAN Application Level (CiADS 20x). Фундаментом CAL служит канальный уровень CAN. CAL не является ориентированным на конкретныеприложения стандартом протокола, не содержит каких-либо профилей, привязанных к конкретным устройствам, ине определяет содержание передаваемых данных, но предлагает стандартизованные элементы сетевого сервисаприкладного уровня. CAL включает в себя четыре составные части:

  • Спецификация CAN сообщений (CMS — CAN Message Specification);
  • Сетевое управление (NMT — Network Management);
  • Распределение идентификаторов (DBT — Identifier Distributor);
  • Управление уровнем (LMT — Layer Management).

CMS определяет типы объектов взаимодействия в рамках объектно-ориентированного подхода, правила и механизмы передачи данных разных типов посредством CAN фреймов, включаяпередачу пакетов длиной более 8 байт. Сетевое управление построено на взаимодействии типа мастер-слуга. Одинмодуль сети является NMT-мастером, все остальные — NMT-ведомые. NMT-мастер инициализирует, управляет NMT-слугами, которые желают принять участие во взаимодействии, и позволяет им общаться между собой посредствомCMS-сервисов. Также в задачи сетевого управления входят контроль ошибок и конфигурирования устройств.Благодаря DBT-сервисам происходит бесконфликтное распределение идентификаторов среди модулей под контролемDBT-мастера. Посредством LMT-сервисов возможны запрос и изменение текущих параметров (значений идентификаторов, скорости передачи, битового квантования и т. п.) в модулях непосредственно из CAN-сети.
    Сетевые CAN приложения, основанные на прикладном уровне CAL, в настоящее времяуспешно работают в медицинской электронике, системах контроля дорожного движения, на транспорте, впромышленном оборудовании.
    Результатом дополнения CAL (точнее, некоторого его подмножества) системой профилей(устройств, интерфейсов, приложений и т. д.) и спецификациями физического уровня (типы соединителей, правилабитового квантования и т. д.) явилось появление более “конкретного” стандарта протокола CANopen. По существуCANopen является приложением прикладного уровня CAL. Первоначально CANopen предназначался для сетейуправления движущимися механизмами в системах промышленной автоматики. Однако впоследствии протокол нашелприменение в медицине, морской электронике, на транспорте и в системах автоматизации зданий.
    CANopen базируется на двух уровнях стандарта CAN (ISO 11898, Bosch CAN Specification2.0 A/B). В дополнение к спецификациям физического уровня ISO 11898 (среда передачи данных — двухпроводнаядифференциальная линия), CANopen содержит собственные правила битового квантования, а также определяет трирекомендуемых типа соединителей:

  • 9-контактный D-Sub (DIN 41652);
  • 5-контактный круглый Mini (ANSI/B93.55M-1981);
  • 5-контактное открытое клеммное соединение.

Разводкой контактов для всех типов соединителей предусмотренавозможность подачи питания на трансиверы узлов, имеющих гальваническую развязку. В сети CANopen определенывосемь градаций скоростей передачи данных: 1 Мбит/с, 800 кбит/с, 500, 250, 125, 50, 20 и 10 кбит/с. Поддержкаскорости 20 кбит/с является обязательной для всех модулей.
    Прикладной уровень представляет собой подмножество CAL и основано на 4-х егосервисных элементах — CMS, NMT, DBT и LMT, дополненных профилем соединения (CiA DS 301), определяющим базовыеправила обмена данными и структуру словаря объектов. Более развитые механизмы сетевого взаимодействия дляинтеллектуальных устройств (человеко-машинные интерфейсы — HMI, PC-контроллеры, PLC, инструментальныесредства и т. п.) описаны в дополнении к коммуникационному профилю (CiA DS 302).
    В сети CANopen на прикладном уровне модули обмениваются между собой объектами-сообщениями — COB (Communication Object), включающими в себя один или более CAN фреймов. Всего существуетчетыре типа таких объектов:

  • данных процесса — Process Data Objects (PDO);
  • сервисных данных — Service Data Object (SDO);
  • специальных функций — Special Function Objects;
  • сетевого управления — Network Management Objects.

 SDO-объекты позволяют модулям обмениваться данными любогообъема (при последовательностях более 8 байт — благодаря использованию нескольких CAN фреймов) в ацикличномнизкоприоритетном режиме. Как правило, этот тип обмена (обязательный к поддержке всеми модулями) используетсядля конфигурирования устройств или настройки формата PDO объектов. В противоположность SDO типу, обмен наоснове PDO объектов используется для синхронной (цикличной или ацикличной) или асинхронной (инициируемыйвнешними прерываниями) скоростной передачи не более 8 байт (длина поля данных фрейма CAN), имеет болеевысокий приоритет, чем SDO и применяется для пересылок данных в режиме реального времени. Объекты специальныхфункций служат для выполнения ряда специальных задач: запуска синхронных процессов, передачи значенияабсолютного времени и кодов ошибок. Объекты сетевого управления включают сообщения NMT, LMT и DBT сервисов.
    Администрированием сети занимается NMT-мастер, который инициализирует устройства,обеспечивает контроль ошибок, а также производит их периодическую “перекличку” (Life Guarding) с помощью PDOсообщений (Node Guarding Object) для выявления узлов, находящихся в нерабочем состоянии ввиду физическогоотсутствия или отключения от шины (bus off) по счетчику ошибок.
    Для максимального упрощения процесса интеграции модулей независимых производителей вединую сеть в CANopen используется концепция профилей. К настоящему времени завершено формирование следующихпрофилей устройств:

  • Модули ввода/вывода (аналоговые и цифровые) (DSP-401);
  • Приводы и модули управления перемещением (DSP-402);
  • Элементы человеко-машинного интерфейса (DSP-403);
  • Измерительные устройства и регуляторы (WD-404);
  • Кодеры (DSP-406).

Разрабатываются профили для модулей управления гидравлическимимеханизмами, дизельными двигателями и железнодорожным транспортом.
    Первым профилем приложения стал WD-407 (IBIS-CAN) для электронных систем управленияна общественном транспорте Европы (билетный контроль, подсчет пассажиров и т. п.), где CAN-сети применяютсядостаточно широко.

CAN Kingdom

Протокол шведской компании KVASER-AB () занимаетособое место среди CAN HLP не только из-за своего необычного названия (CAN королевство), но и в значительнойстепени благодаря оригинальной концепции сетевого взаимодействия и эффективности CAN-приложений на его основе. Началу работ над первой версией (текущая — третья) протокола CAN Kingdom в 1990 году предшествовал многолетний опыт компании в области создания систем распределенного управления. Протокол был специально разработан для управления движущимися машинами и механизмами — промышленными роботами, текстильными станками, мобильными гидравлическими устройствами, — и позволяет достичь высокой производительности в режиме реального времени при удовлетворении жестких требований безопасности. CAN Kingdom является также основой американского военного стандарта CDA 101 и широко используется в военной технике — от надувных лодок и систем наведения на цели до сверхзвуковых истребителей и ракет.
    Основной целью создания протокола было предоставление системному разработчикумаксимальной свободы в реализации своих идей при построении сети, сохранив при этом возможность использованиястандартных модулей от независимых производителей. CAN Kingdom не является “готовым” протоколом в том смысле,в каком это справедливо, например, по отношению к стандартам типа CANopen или DeviceNet. Это скорее наборпримитивов — метапротокол, — с помощью которых можно “собрать” протокол под конкретную сеть модулей. Этимдостигается уникальное сочетание простоты интеграции готовых модулей с высокой степенью “закрытости”оригинального протокола.
    При разработке спецификации CAN Kingdom авторы отказались от принятого в подобныхслучаях и широко распространенного следования правилам взаимосвязи открытых систем OSI/ISO, посколькусемиуровневая модель OSI/ISO создавалась изначально для описания традиционных компьютерных сетей, от которыхне требуется работа в реальном масштабе времени, и предназначены они для обслуживания пользователей,требования которых априори (на этапе построения такой сети) неизвестны и непредсказуемы. В системах жеуправления реального времени ситуация прямо противоположная — на стадии разработки все коммуникационныепотребности модулей должны быть известны.

Рис. 2.
а) Традиционное представление CAN-сети и
б) в терминах CAN Kingdom

Краеугольным камнем концепции сетевого взаимодействия CAN Kingdomявляется принцип: “Модули обслуживают сеть” (MSN — Modules Serves the Network) в отличие от принципа “Сетьобслуживает пользователей” (NSM — Network Serves the Modules), свойственного компьютерным сетям.
    Представление CAN сети в терминах CAN Kingdom (в сравнении с традиционным) дано нарис. 2. В CAN Kingdom сеть CAN — это страна (королевство) со своей столицей (центральный контролирующий узел)и провинциальными городами (остальные узлы). Король (управляющая программа-супервизор) управляет всемкоролевством и отвечает за соблюдение закона и порядка в нем, а за местное управление (в пределах своего узла)отвечают мэры городов (управляющие программы узлов). Каждый город экспортирует или импортирует продукцию —информацию — посредством почты, которая циркулирует по почтовому тракту (CAN-шина) и проходит черезпочтмейстеров (CAN контроллеры). Типы почтовой корреспонденции (информация, передаваемая по сети) и еесоответствие CAN-терминам таковы:

Письмо CAN-фрейм(данных или удаленного запроса) Конверт CAN-идентификатор Страница Поле данных CAN-фрейма Строка Байт данных Элемент строки Бит данных

Неформальный язык описания протокола позволяет любому специалисту,далекому от вычислительной техники или электроники — биологу, механику или врачу — благодаря интуитивнопонятному описанию сети (как должны функционировать общество или страна, примерно представляют себе все)активно участвовать если не в процессе разработки системы, то хотя бы сознательно формулировать техническиеусловия и иметь представление о принципах ее функционирования. CAN система на базе протокола CAN Kingdomобладает следующими особенностями:

  • Распределение CAN идентификаторов находится под полным контролем разработчика.
  • Максимальное время прохождения любого сообщения в сети предсказуемо.
  • Во время начальной инициализации системы происходит обязательный этап настройки (setup) протокола,включая построение форматов данных, начиная с битового уровня, методов управления шиной, распределениеидентификаторов и т. д.
  • В системе всегда должен присутствовать (как минимум до завершения настройки протокола) супервизор (Король), производящий инициализацию системы, контроль подключенных узлов и т. д. Ни один модуль не может приниматьучастие в сетевом обмене без разрешения Короля.
  • Перед инициализацией сети каждый модуль (город) должен иметь свой номер (CAN Kingdom не описываетконкретный способ установки номера модуля — это может быть DIP-переключатель, энергонезависимая память иликонфигурация соединителя) и “знать” идентификатор сообщения инициализации (королевское письмо) и скоростьпередачи данных в сети.
  • В сеть CAN Kingdom возможна интеграция любых CAN-модулей, включая разработанных для других протоколов,например, DeviceNet или SDS.
  • Не существует каких-либо рекомендуемых скоростей передачи данных. Но за первые 200 мс после подачипитания узел обязан настроиться на прослушивание шины на скорости 125 кбит/с. Допустимы отличающиеся от ISO11898 спецификации физического уровня.

Наличие одного центра-Короля, который содержит всю информацию осистеме, избавляет от использования профилей устройств, часто применяемых в других HLP.
    Правила идентификации модулей основаны на использовании международного кода EAN/UPC,включающего код производителя и продукта. Среди других особенностей CAN Kingdom можно отметить гибкостьрежимов передачи и упаковки данных (включая использование поля арбитража для передачи данных), объединениеузлов в группы, поддержка часов реального времени, различных режимов доступа к шине.

DeviceNet

DeviceNet — протокол, разработанный и опубликованный в 1994 годукомпанией Allen-Bradley () корпорации Rockwell и впоследствии переданный в ведение специальноорганизованной для его поддержки ассоциации ODVA (Open DeviceNet Vendor Association Inc.,). DeviceNet — недорогое, простое и эффективное решение дляобъединения разнообразных устройств промышленной автоматизации независимых производителей в единую систему:фото-, термодатчики, стартеры, считыватели штриховых кодов, элементы человеко-машинного интерфейса —клавиатуры, дисплейные панели, — наряду с управляющими устройствами — PLC, компьютерами и т. д. (рис. 3).При разработке протокола помимо снижения стоимости также стояла задача упрощения и унификации диагностикиподобных устройств. Первые устройства, удовлетворяющие спецификации DeviceNet, появились на рынке в начале1995 года. DeviceNet также построен на двух нижних уровнях стандарта CAN, дополненных более детальными, чемв других HLP, спецификациями физической среды.

Рис. 3. Пример сети DeviceNet

Сеть DeviceNet имеет шинную топологию с отводами. Физическойсредой передачи является 4-проводной кабель (CAN_H, CAN_L, Vcc, Ground), причем возмож-ны две егоразновидности: толстый (внешний диаметр 12,2 мм) и тонкий (6,9 мм). Определены лишь три значения скоростипередачи данных — 125, 250 и 500 кбит/с. Максимальные длины центральной магистрали и отводов в зависимостиот скорости передачи и типа кабеля приведены в табл. 1.
Таблица 1. Ограничения на протяженность сети DeviceNet Скорость передачи, кбит/с Длина магистрали, м Длина отводов, м Толстый кабель Тонкий кабель Одиночных Сумарная 125 500 100 6 156 250 250 100 6 78 500 100 100 6 39

Важной особенностью сети DeviceNet является возможность питаниямодулей непосредственно от сетевого кабеля (24 В, до 8 А на толстом кабеле), а также допускается применениенескольких источников питания в любой точке шины. Все это дает возможность построения автономной сети, независящей от наличия или качества внешнего питания, а при необходимости позволит легко демонтировать и сноваразвернуть систему на новом месте. Сеть DeviceNet допускает “горячее” (без обесточивания сети) подключение иотключение модулей.
    Стандарт DeviceNet содержит также подробное описание многочисленных типов переходников,разветвителей (одиночных и многопортовых), соединителей (Mini, Micro), сетевых отводов и т. п.
    При описании организации типов данных, сетевого поведения модулей в DeviceNetиспользуется объектно-ориентированная модель. Обязательные классы объектов включают в себя следующие:

  • объект удостоверения (Identity object). Содержит информацию о модуле (код производителя, продукта,версия и т. п.);
  • объект соединения (Connection object). Логический порт ввода/вывода устройства;
  • объект DeviceNet. Включает MAC ID (идентификатор модуля), скорость передачи, состояние модуля и т. п;
  • объект роутера сообщения (Message router object). Перенаправляет явное сообщение получателю.

Сообщения в сети DeviceNet могут быть двух типов:

  • сообщения ввода/вывода (I/O messages) — предназначены для целей управления устройствами ипередачи данных в реальном времени между узлами в широковещательном или в режиме точка-точка. Используютидентификаторы с высоким приоритетом, которые и определяют содержание сообщения;
  • явные сообщения (Explicit messages) — для многоцелевого обмена данными в режиме точка-точка. Обеспечивают типичный сервис запрос/ответ. Используют идентификаторы с низким приоритетом иприменяются обычно для конфигурирования устройств и целей диагностики. Значение сообщения содержится в поледанных.

При необходимости передачи данных длиной более 8 байт применяетсямеханизм фрагментации. В зависимости от потребностей обмена и возможностей модулей, возможны мастер-слуга(master-slave), мультимастерный (multi-master), или равноправный (peer to peer) способывзаимодействия устройств. Пересылки данных могут инициироваться путем опроса, циклически или по изменении ихзначения (change of state). Максимальное число узлов в сети DeviceNet — 64.
    Модули в сети могут быть как UMCC-типа (UnCon-nected Message Manager),способные выставлять равноправные (peer to peer) соединения с другими модулями, так и Predefined Master/Slave-типа, требующие меньшей длины кода и производительности управляющего микроконтроллера, но которые не могутпроизвольно выбирать путь соединения, и их объекты соединения конфигурируются при включении устройства.
    Для обеспечения “стыкуемости” устройств разных производителей и их взаимодействия врамках единой сети стандарт DeviceNet, подобно многим HLP, определяет ряд профилей устройств. Формированиембиблиотек профилей занимаются специальные группы (Special Interest Groups) ассоциации ODVA.

SDS (Smart Distributed System)

SDS — разработка компании Honeywell Inc. (Micro Switch Division,). Наряду со стандартом DeviceNet,SDS представляет собой еще одно недорогое и законченное решение для сетевого управления интеллектуальнымидатчиками и актуаторами от центрального контроллера (PLC, компьютера) в системах промышленной автоматизации.
    По степени завершенности — от спецификаций физической среды до прикладного уровня, —ориентировке на снижение стоимости, SDS-стандарт напоминает DeviceNet.
    Шинная топология представляет собой линейную шину (магистраль или транк) с короткимиотводами (рис 4). Определены два базовых типа кабельной разводки: Mini (применяемый при сборке транка сети) —4-проводной кабель с максимальной токовой нагрузкой 8 А, 5-контактный разъем — и Micro (для подключенияфизических устройств к сети) — 4-проводной кабель, 3 А, 4-контактный разъем без отдельного контакта дляэкрана кабеля.

Рис. 4. Пример сети SDS

В сети SDS допускается и обычная проводная разводка сиспользованием открытых клеммных соединителей. Всеми типами кабельной разводки и соединителей, также как и всети DeviceNet, предусмотрено подведение питающего напряжения (диапазон 11–25 В на стороне устройства) кузлам. Предельные значения длин магистрали и отводов сети SDS в зависимости от скоростей (их четыре) передачиприведены в табл. 2.

Таблица 2. Предельные значения длин магистрали и отводов сети SDS Макс.длина магистрали, м Скорость передачи, кбит/с Макс.длина отводов, м Макс. количество узлов 22,8 1000 0,3 32 91,4 500 0,9 64 182,8 250 1,8 64 457,2 125 3,6 64

Сообщения, циркулирующие в сети SDS, носят название APDU(Application layer Protocol Data Unit) — блоки данных протокола прикладного уровня. APDU представляетсобой CAN фрейм стандартного формата (расширенный формат фрейма в SDS-сети не применяется), элементы которогоимеют свое собственное назначение в SDS. APDU имеет две формы — укороченную (не используется при передачеданных и содержит в поле DLC нули) и длинную.
    При необходимости передачи последовательностей данных более 6 байт используетсяфрагментированный формат (до 64 фрагментов по 4 байт) длинной формы APDU.
    Укороченная форма APDU используется в следующих сервисах прикладного уровня:

  • Change of State (OFF, ON, OFF ACK, ON ACK) — обнаружение изменения состояния логического устройства;
  • Write (ON State, OFF State, ON State ACK, OFF State ACK) — управление состояниями логическогоустройства.

К сервисам, использующим длинную форму APDU, относятся:

  • Channel — обеспечивает как широковещательный (multicast), так и равноправный (peer to peer)каналы соединения;
  • Connection — открытие/закрытие индивидуальных типов соединения;
  • Write — чтение атрибутов объектов устройства;
  • Read — изменение атрибутов объектов устройства;
  • Action — команда объекту устройства выполнить действие;
  • Event — сигнализация о событии объектом устройства.

При инициализации взаимодействия модулей сети SDS используются4 сервисных функции-примитива:

  • Запрос (Request) — генерация APDU устройством-инициатором соединения;
  • Ответ (Response) — ответный APDU устройства-ответчика;
  • Индикация (Indication) — фиксация факта приема APDU устройством-ответчиком;
  • Подтверждение (Confirm) — подтверждение приема APDU устройством-инициатором.

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

Заключение

Происходящее в настоящее время расширение областей примененияCAN-технологий на фоне усиливающейся отраслевой дифференциации дополнительных спецификаций CAN-стандарта,объединение производителей CAN оборудования в промышленные группы и ассоциации, поддерживающие тот или инойCAN HLP, при все возрастающем на рынке предложении готовых модулей и HLP-ориентированных инструментальныхсредств приводит к тому, что создание конкурентоспособных разработок и изделий с использованием CAN-сетейзачастую становится возможным лишь на основе того или иного стандартного прикладного протокола.

E-mail: Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript






Рекомендуемый контент




Copyright © 2010-2017 housea.ru. Контакты: info@housea.ru При использовании материалов веб-сайта Домашнее Радио, гиперссылка на источник обязательна.