Сеть CAN: популярные прикладные протоколыА. Щербаков
Выпущенный из недр автомобилестроительных лабораторий полтора
десятка лет назад, джин CAN-технологий (CAN Controller Area Network) стремительно проникает буквально
во все сферы человеческой деятельности от домашнего хозяйства до орбитальных космических станций. Общее
число CAN-сетей, которые будут установлены в мире в текущем году, по прогнозам ассоциации CiA (CAN in
Automation, www.can-cia.de) должно составить около 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 (CiA
DS 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 Specification
2.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 (www.kvaser.se) занимает
особое место среди 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 кбит/с. Допустимы отличающиеся от ISO
11898 спецификации физического уровня.
Наличие одного центра-Короля, который содержит всю информацию о
системе, избавляет от использования профилей устройств, часто применяемых в других HLP.
Правила идентификации модулей основаны на использовании международного кода EAN/UPC,
включающего код производителя и продукта. Среди других особенностей CAN Kingdom можно отметить гибкость
режимов передачи и упаковки данных (включая использование поля арбитража для передачи данных), объединение
узлов в группы, поддержка часов реального времени, различных режимов доступа к шине.
DeviceNet
DeviceNet протокол, разработанный и опубликованный в 1994 году
компанией Allen-Bradley (www.ab.com) корпорации Rockwell и впоследствии переданный в ведение специально
организованной для его поддержки ассоциации ODVA (Open DeviceNet Vendor Association Inc.,
www.odva.org). 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,
www.honeywell.sensing.com). Наряду со стандартом DeviceNet,
SDS представляет собой еще одно недорогое и законченное решение для сетевого управления интеллектуальными
датчиками и актуаторами от центрального контроллера (PLC, компьютера) в системах промышленной автоматизации.
По степени завершенности от спецификаций физической среды до прикладного уровня,
ориентировке на снижение стоимости, SDS-стандарт напоминает DeviceNet.
Шинная топология представляет собой линейную шину (магистраль или транк) с короткими
отводами (рис 4). Определены два базовых типа кабельной разводки: Mini (применяемый при сборке транка сети)
4-проводной кабель с максимальной токовой нагрузкой 8 А, 5-контактный разъем и Micro (для подключения
физических устройств к сети) 4-проводной кабель, 3 А, 4-контактный разъем без отдельного контакта для
экрана кабеля.
В сети SDS допускается и обычная проводная разводка с
использованием открытых клеммных соединителей. Всеми типами кабельной разводки и соединителей, также как и в
сети DeviceNet, предусмотрено подведение питающего напряжения (диапазон 1125 В на стороне устройства) к
узлам. Предельные значения длин магистрали и отводов сети 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: say@tande.com
| Ваш комментарий к статье | ||||
