CAN-сеть - платформа создания распределенных систем управлен

CAN-сеть - платформа создания распределенных систем управления.

Д. Калачев, С. Третьяков

CAN-сеть - платформа создания распределенных систем управления

Несмотря на относительно небольшой срок существования, можно говорить о том, что у CAN есть своя история. Началась она с того, что в 1983 году Robert Bosch GmbH и Intel (подключилась к работам в 1984 году) начали совместные работы над проектом высокоскоростной сети с простым подключением узлов и блоков к шине, призванной заменить радиальную проводку в автомобилях. В 1986 была опубликована первая спецификация CAN, описывающая кроме всего прочего только стандартный (11-бит идентификатор) формат CAN-сообщения. В 1987 году Intel выпустил первый автономный CAN-контроллер - i82527. В 1991 году была опубликована CAN-спецификация для расширенного (29-бит идентификатор) формата CAN-сообщения.Большую работу по стандартизации CAN-технологий проводит международная ассоциация потребителей и производителей CAN - CAN in Automation (CiA), основанная в марте 1992 года ().Отличные характеристики CAN: широковещательный способ передачи (broadcasting), мультимастерность (multiMaster), превосходная обработка ошибок, различная среда передачи, наличие аппаратной поддержки - обусловили лавинное увеличение приложений на базе CAN и расширение областей применения: автомобильный и железнодорожный транспорт, авиация, судостроение, управление технологическим оборудованием, управление вооружениями и многие другие.

Аппаратная поддержка протокола

На начальном этапе становления CAN-технологий для аппаратной поддержки создаваемых решений использовались автономные (Stand-alone) CAN-контроллеры. В процессе развития и увеличения количества распредел╦нных систем, созданных на основе CAN, был создан ряд однокристальных микроконтроллеров со встроенными CAN-контроллерами (табл. 1). Такое решение позволило существенно снизить сложность и стоимость систем.

Таблица 1. Фирмы, выпускающие контроллеры, поддерживающие CAN

Фирма, веб-сайт Один чип из многих Характеристики CAN-контроллера Bosch,
CC750 2,0 B, Stand-alone, 14 Tx/Rx буферов + 1 сдвоенный Rx буфер, 2 глобальные маски + 1 маска для Rx сдвоенного буфера Dallas Semi.,
DS80C390 2x2,0 B, 8-бит, 14 Tx/Rx буф. + 1 сдв. Rx буф. Fujitsu,
MB90F443G 2x2,0 B, 16-бит (16LX), 16 Tx/Rx буф., 16 пол. бит. масок + 2 гл. маски Hitachi,
semiconductor.hitachi.com/h8 SH7055 2,0 B, 32-бит, 30 Tx/Rx буф. + 2 Rx буфер, 30 пол. бит. маски + 2 гл. маски Infineon,
C515C 2,0 B, 8-бит, 14 Tx/Rx буф. + 1 Rx буф., 15 пол. бит. маски + 1 гл. маски Inicore,
iniCAN 2,0 B, 8-бит или DSP, по спецификации заказчика Intel,
developer.intel.com AN87C196 2,0 B, 16-бит, 14 Tx/Rx буф. + 1 сд. Rx буф., 15 пол. бит. масок + 1 гл. маски Microchip,
PIC18F248 2,0 B, 8-бит, 3 Tx буф.+ 2 Rx буф., 6 пол. бит. масок + 2 гл. маски Micronas Inter.,
CDC1607E 3x2,0 B, 16-бит, 16 Tx/Rx буф., 16 пол. бит. масок + 1 гл. маски Mitsubishi,
M306NOMCT 2x2,0 B, 16-бит, 16 Tx/Rx буф., 16 пол. бит. масок + 3 гл. маски Motorola,
MC68F375 2,0 B, 32-бит, 16 Tx/Rx буф., 16 пол. бит. масок + 3 гл. маски National Semi.,
CR16MCS9VJE 2,0 B, 16-бит, 15 Tx/Rx буф.+ 1 Rx буф., 14 пол. бит. масок + 1 гл. маски NEC,
SCAN - ╣PD703079Y 2x2,0 B, 32-бит RISC (V850), 32 Tx/Rx буф., 64 пол. бит. масок + 4 гл. маски OKI Elec.,
MSM9225 2,0 B, Stand-alone, 16 Tx/Rx буф., 16 пол. бит. масок Phili ps,
www-us.semiconductors.philips.com P8XC592/8 2,0 В, 8-бит, 1 Tx буф. + 2 Rx буф., 1 гл. 8-бит. Масок Sican,
CAN Core 2,0 B, по спецификации заказчика ST Microelec.,
ST72532J4 2,0 B, 8-бит, 3 Tx/Rx буф., 2 гл. 11-бит маски Texas Instrum.,
TMS320F2406 2,0 B, 16-бит DSP, 6 Tx/Rx буф., 2 пол. бит. масок + 1 гл. маски Toshiba,
doc.semicon.toshiba.co.jp TMP95FW54F 2,0 B, 16-бит, 15 Tx/Rx буф. + 1 Rx буф., 15 пол. бит. масок + 1 гл. маски

Дальнейшее развитие происходит как в направлении интеграции в одном микроконтроллере средств для аппаратной поддержки, помимо CAN и других сетевых протоколов (J1850: Motoro-la PC9S12DJ64, LIN: Fujitsu MB90F394, byteflight: Motorola PC9S12DB32 и другие), так и в увеличении CAN-интерфейсов (Fujitsu, Hitachi, Motorola, Micronas и другие) и мощности CAN-контроллеров (количество аппаратных буферов у Hitachi SH7055F, Bosch C_CAN, TTCAN увеличено до 32, тогда как стандартной величиной является 8╦16).

Стандартные прикладные CAN-протоколы

Спецификация CAN определяет только физический и канальный уровни (CAN Layer 2 Protocol по Эталонной модели OSI). При создании простых приложений - небольшое количество однотипных узлов, слабая изменчивость, например, сбор данных и передача в центральный модуль, - использование CAN Layer 2 вполне достаточно. Однако при создании сравнительно сложных систем (десятки и сотни узлов), в которых узлы существенно различаются по функциональности (например, управление технологическим процессом), требуется модификация и дополнение системы без полной е╦ перестройки, использование только протоколов канального уровня становится уже неприемлемым. Для обеспечения большей над╦жности разработки, модифицируемости и сопровождаемости системы возникает необходимость использования более высокого уровня абстракций - протоколов более высокого - прикладного уровня (High Level Protocol - HLP). Необходимость создания унифицированных решений обуславливает открытость таких протоколов.

Как правило, все HLP определяют два уровня - уровень управления сетью (Network Layer) и собственно прикладной уровень (Application Layer). Первый служит для обеспечения функционирования сети, выполнения подключения/отключения узлов, настройки и конфигурирования, второй - собственно обеспечивает работу приложений. В табл. 2 приведены наиболее известные в настоящее время протоколы прикладного уровня на базе CAN.

Таблица 2. Высокоуровневые протоколы, основанные на CAN

Имя HLP-протокола, веб-сайт Кто сопровождает Область использования CAL,
CiA Системы специального назначения. Определяет стандарт для обмена сообщениями - CMS и конфигурированием и управлением сетью - LMT, NMT и DBT CANopen,
CiA Системы общего назначения, промышленная автоматика. Определяется документами: DS-301 определяет профиль связи, DS-40x - профили различных устройств DeviceNet,
ODVA Системы общего назначения, промышленная автоматика CAN Kingdom,
Kvaser AB Приложения специального назначения SDS - Smart Distributed System,
content.honeywell.com Honeywell Системы общего назначения, промышленная автоматика SAE J 1939,
SAE Автомобилестроение, системы управления и диагностики грузовиков, прицепов, сельскохозяйственной и пожарной техники CANaerospace,
M. Stock GmbH Авиация и космос, системы сбора данных и управления оборудованием самол╦тов и вертол╦тов. CDA 101,
МО США Военные объекты и приложения NMEA 2000,
NMEA Морское оборудование и морские приложения: военные корабли, подводные лодки, торговые суда SeleCAN,
Selectron Системы специального назначения WesyCAN,
Sulzer Ruti Ltd. Текстильная промышленность Инструментальные средства разработки

Разработка сложных распредел╦нных систем на базе CAN требует использования разнообразных инструментальных средств на базе PC, которые резко сокращают время разработки как программного обеспечения, так и всей системы в целом. К ним относятся:

мониторы и анализаторы шины, обеспечивающие выполнение функций: мониторинг трафика - показ всех (или в соответствии с заданным фильтром) CAN-кадров; измерение загрузки шины и индикация ошибок; запись принятых CAN-кадров в файл (так называемый CAN Log); генерация CAN-кадров и воспроизводство предварительно записанных - эмуляция трафика; конфигураторы, обеспечивающие функции загрузки конфигурации и настройки узлов, управления их состоянием; редакторы EDS- и DCF-файлов - средства описания и редактирования конфигурации узлов; библиотеки, обеспечивающие поддержку как CAN Layer 2 Protocol, так и высокоуровневых протоколов - CANopen, DeviceNet и других; эмуляторы узлов сети (ориентированные на определ╦нный тип высокоуровневых протоколов).

Как правило, предлагаемые на рынке средства разработки представляют собой комплексные продукты, реализующие всю или большую часть указанной выше функциональности. Наиболее типичными представителями являются пакеты canAnalizer/32 и CANalyzer.

Для обеспечения взаимодействия PC с CAN-устройствами выпускается достаточно большой спектр интерфейсных плат - CAN-контроллеров (табл. 3), обладающих различными характеристиками. Отрадно отметить, что в данном секторе CAN-устройств представлены и изделия Российских производителей.

Таблица 3. Инструментальные ср-ва и аппаратная поддержка CAN-протокола

Фирма, веб-сайт ПО и Tools Аппаратная поддержка IXXAT Automation GmbH
canAnalyser/32 (lite, professional)
CANopen Client
CANopen Node Manager
CANopen EDS Editor
CANopen Config Studio
Data Interpreter Client ┘ iPC-I 320/ISA/AT96/PCI/104
iPC-I 165/ISA/PCI
tinCAN (PCMCIA)
CANdy, CANdy lite (Centronics)
USB-CAN
CANcorder (CAN Log Unit) ┘ Kvaser AB
CANscope
CANking
CANopen Founder
Kingdom Founder ┘
PCIcan-S/-D/-Q
PCcan- S/-D/-Q
LAPcan/LAPcanII
WAVEcan (wireless)
USBcan ┘ Vector Informatik GmbH
CANalyser
proCANopen/CANsetter
CANoe, CANape,
CANscope, CANdbLib
CANeds
CANdid, CANdb++ ┘ CANcardX (PCMCIA)
CAN-AC2/-AC2-PCI
CANcard2
CANextender, CANpar i
CANscope, CANview
CANstress ┘ esd GmbH
CANalyser CAN-PCI/360/331
CAN-ISA/331/200
CAN-PCC (Centronics)
CAN-PCMCIA
VME-CAN4/-CAN2/CAN2B
CAN-SB01
CAN-IP65
CAN-CDI16/CDO16/CDIO1616 ┘ port GmbH
CANopen Library EtherCAN (gateway)
CPC_XT1
CPC_PP ┘ Марафон (Москва)
- PC-CAN/ISA/PCI Каскод (Санкт-Петербург)
- CAN104D
CANPC527D

Таблица 4. Сравнительные характеристики различных систем, реализованные на CAN

Проект Рассто- яние, м Кол-во, тип узлов Ско- рость, Кбит/с Трафик, frames/s Арх-ра HLP Инструментальные средства, драйверы, пакеты разработки GPSC 500 20 (CAN), до 48 125 20÷100 шина CAL ОС РВ dmOS-51, драйвер dmDRV-51.CAN,
dmCAL, реализующий уровни CMS и DBT протокола CAL, CANPC527D ACS-2000 (I) 4000 24 (CAN) 125 На сег.:
ср. - 60
пик. - 200
Между сег.:
ср. - 15
пик. - 150 иерархия HCDA ОС РВ dmOS-51, драйверы dmDRV-51.CAN,
dmVCI-SERVER, VCI (IXXAT), iPC-I 320/PCI ACS-2000 (II) 1000 20 (CAN)
60 (LIN) 125 ср. - 60
пик. - 200 шина HCDA ОС РВ dmOSEK-16LX,
драйверы dmDRV-16LX.CAN,
dmVCI-SERVER,
VCI (IXXAT),
canAnalyser/32, iPC-I 320/PCI HACS 100÷4000 до 60000 125÷1000 иерархия eHCDA eHCDA СЭС 100 10 (CAN), до 127 500 ~ 3200 шина CAN canAnalyser/32, iPC-I 320/PCI СКВ 100 8 (CAN) 500 ~150 шина CAN canAnalyser/32, iPC-I 320/PCI Тепловоз 40 до 16 500 ~100 шина CAN canAnalyser/32, iPC-I 320/PCI Стенд-тренаж╦р 20 до 127 (CAN) 1000 ~ 7000 шина CAN dmOSEK-16LX, драйвер dmDRV-16LX.CAN, VCI (IXXAT), dmVCI-SERVER Использование CAN при построении распределенных систем

CAN-протокол обладает великолепными характеристиками:

широким диапазоном скоростей; различной средой передачи: витая пара, один провод (второй - корпус), коаксиальный кабель, оптоволокно, радиоканалы, силовые линии электропередачи; над╦жностью и превосходной обработкой ошибок - гарантированная доставка сообщений и возможность автоматического отключения удал╦нного узла; хорошей поддержкой построения сетей с большим количеством абонентов и ориентированностью на создание распредел╦нных систем управления - широковещательный способ передачи, мультимастерность, разрешение конфликтов на основе приоритетов сообщений; возможностью использования как синхронной, так и асинхронной моделью передачи данных; поддержкой систем, управляемых событиями - ориентированность на адресацию (идентификацию) сообщений, а не узлов; масштабируемостью - от простейших до сложных микроконтроллеров и сетевых CAN-плат для обычных и индустриальных PC; возможность использования единой шины для подключения как программируемых контроллеров, так и простейших сенсоров и исполнительных механизмов; наличием аппаратной поддержки - автономных и встроенных в микроконтроллеры CAN-контроллеров стоимостью до 5$. Различные варианты архитектурной реализации распределенных систем

CAN может использоваться для построения систем, имеющих самую различную сетевую конфигурацию. Далее рассматриваются типовые варианты построения распредел╦нных систем.

Простая (шинная) CAN-сеть

Все существующие стандарты HLP и большинство применений CAN основаны на шинной архитектуре. Основные характеристики таких применений: не более нескольких десятков узлов, протяж╦нность не более нескольких сот метров. Это автомобильный транспорт, отдельные подсистемы морских судов и самол╦тов.

Иерархическая CAN-сеть

Для реализации сложных и больших систем - управления зданием (гостиницей, бизнес-центром и т.п.), управления технологическим процессом, - требующих большого числа (несколько сот) CAN-узлов или имеющих несколько ч╦тко выраженных логических и/или физических сегментов - этажей, корпусов, - обычно требуется иерархическая структура сети. Таким образом, можно сказать, что иерархия сети нужна там, где присутствует ч╦тко выраженная иерархия объектов управления и потоков данных между контроллерами и/или имеется необходимость построения распредел╦нной системы на больших расстояниях и с большим количеством узлов. Как правило, в таких системах при понижении уровня иерархии используемые контроллеры упрощаются, а их количество увеличивается.

Можно указать следующие проблемы построения иерархических сетей:

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

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

CAN-сеть в интеграции с локальными сетями более низкого уровня

С целью понижения стоимости оборудования систем управления и контроля автомобилей фирмами Audi AG, BMW AG, DaimlerChrysler AG, Motorola Inc, Volcano Com-munications Technologies AB, Volkswagen AG и Volvo Car Corporation был разработан новый протокол - Local Interconnect Network - LIN (). Это сравнительно низкоскоростной протокол (до 20 Кбит/с), предназначенный для подключения интеллектуальных датчиков и исполнительных механизмов. Таким образом, вста╦т задача создания гетерогенных сетей, использующих CAN и LIN.

Построение иерархических распределенных приложений Цель создания HCDA

Протокол прикладного уровня для построения иерархических распредел╦нных приложений на базе CAN - Hierarchical CAN Distributed Application (HCDA) представляет собой разработку стандарта, предназначенного для создания сложных распредел╦нных при-ложений, базирующихся на CAN-протоколе. Данный стандарт имеет смысл использовать при разработке систем (проектов), характеризующихся следующими параметрами:

большим (более 255) количеством CAN-контроллеров (узлов) в сети; возможностью подключения к CAN-контроллерам подсетей уровня датчиков и исполнительных механизмов, например, LIN; большим (до 2000√3000) количеством объектов распредел╦нного приложения - логических объектов, которые выступают в качестве самостоятельных единиц с точки зрения функционирования системы в целом; сравнительно невысоким временем реакции на внешние события (единицы секунд); размещением на большой территории и, как следствие, наличием нескольких физических сегментов сети; возможностью иерархического объединения сегментов сети, объединяемых пассивными и/или активными повторителями и/или маршрутизаторами; а также тем, что подтверждаемые сервисы прикладного уровня (команды) мультимастерны, то есть возможно поступление одной и той же команды от разных инициаторов для одного исполнителя. Сетевая архитектура HCDA

Уровень управления сетью HCDA обеспечивает:

управление состояниями контроллеров; охрану узлов - обнаружение отключений и подключений узлов; возможность уникальной идентификации каждого узла в рамках всей сети; автоматическое определение идентификатора подключенного (подключаемого) узла; загрузку конфигурации и ПО.

Уровень приложения HCDA обеспечивает: определение прикладных сущностей - объектов распредел╦нного приложения (Distributed Appli-cation Object) и их идентификацию в пределах всей системы, не зависящую от идентификации узлов (контроллеров) сети; обмен данными между DAO в реальном времени с использованием двух основных типов сообщений: подтверждаемых - команд и не подтверждаемых - событий; привязку прикладного уровня к физической конфигурации сети.

Описание объектов и их элементов через профили

Для обеспечения возможностей гибкой настройки и реконфигурируемости обеспечена стандартизация механизмов конфигурирования контроллеров и объектов распредел╦нного приложения. Стандартизация реализована через профили (аналогично тому, как это сделано в CANopen) - типовые конфигурации контроллеров, объектов распредел╦нного приложения, элементов - датчиков, управляющих механизмов и т.п.

Примеры создания территориально распределенных систем Комплексная система автоматизации переработки зерна и зернопродуктов

Комплексная система автоматизации переработки зерна и зернопродуктов - GPSC (Grain Processing Control System) состоит из подсистем:

контроля при при╦ме сырья и отпуске продукции (измерение массы, объ╦ма, качества); контроля среды при хранении сырья, полуфабрикатов и готовой продукции (измерение температуры, влажности, уровня); управления технологическим оборудованием; управления транспортными операциями; целевого управления производством; охранно-пожарной безопасности.

В настоящее время GPSC реализована на зерновом терминале Таганрогского миниэлеватора:

подсистема при╦ма зернопродуктов предназначена для оперативного контроля и управления процессом при╦мки зерна на элеваторах и хлебопри╦мных предприятиях, а также для формирования баз данных о количестве принятого зерна и его качественных показателях; подсистема отгрузки зернопродуктов предназначена для оперативного контроля и управления процессом отпуска продукции, а также формирования баз данных о количестве и качественных показателях отпущенной продукции. Система тревожной (охранно-пожарной) сигнализации

Комплексная система управления тревожным (охранно-пожарным) оповещением ACS-2000 (Alert Control System) предназначена для организации охранной, пожарной и охранно-пожарной служб гостиничных, санаторных и туристических комплексов, вузов, учебных корпусов, банков, бизнес-центров, супермаркетов, а также жилых многоквартирных домов. Система способна взять на себя все заботы, связанные с обеспечением безопасности имущества граждан, а также материальных ценностей, находящихся в служебных помещениях как в пределах здания, так и на удалении от него на расстояние до 6000 м.

Комплекс ACS 2000 представляет собой специализированную локальную многоуровневую территориально распредел╦нную систему, реализованную на CAN- и LIN-сетях.

Одна из реализаций системы ACS-2000 представляет собой пример иерархической CAN-сети, при построении которой в полной мере были оценены преимущества использования протокола прикладного уровня HCDA.

Дальнейшее развитие проект ACS-2000 получил в системе комплексной автоматизации работы гостиничного комплекса - HASC (Hotel Automation Control System).

Управления системой кондиционирования воздуха в самолете

Система кондиционирования воздуха (СКВ) является одной из важнейших систем обеспечения пол╦тов современных самол╦тов в различных погодных и высотных условиях.

Центральным звеном СКВ является промышленная установка охлаждения воздуха, содержащая обычно несколько ступеней с регулирующими заслонками и датчиками. Кроме того, в СКВ входит ряд запорно-соединительных заслонок и воздушных магистралей, с помощью которых обеспечиваются различные режимы работы СКВ. Размещение, параметры и характеристики указанных элементов СКВ в значительной мере определяются конструкцией и назначением самол╦та. Поэтому основная проблема создания СКВ заключается в разработке блока управления (ЦБУК) и объединения всех элементов СКВ в единую систему.

Одной из основных конструктивных особенностей ЦБУК является применение модульного принципа построения и сетевой системы связи модулей и подсистем СКВ. Для этой цели применяется CAN. ЦБУК состоит из модуля центрального процессора, основного и резервного модулей ввода/вывода. Модули соединены между собой по CAN-шине. Также по CAN-шине связаны и оба блока ЦБУК (левый и правый борт). Применение CAN прида╦т ЦБУК высокую универсальность и над╦жность, так как позволяет осуществлять дистанционную загрузку и полное изменение управляющей программы без демонтажа блока.

Система электроснабжения самолета

Для системы сбора и обработки параметров качества электроэнергии системы электроснабжения (СЭС) самол╦та был разработан сетевой измерительно-вычислительный комплекс (СИВК), представляющий собой совокупность контроллеров сбора данных в реальном времени, объедин╦нных в локальную CAN-сеть под управлением PC.

Большой объ╦м передаваемых данных и ж╦сткие временные ограничения потребовали создания собственного прикладного протокола, основанного на CAN Layer 2.

СИВК успешно применяется на ТАНТК им. Бериева при проведении стендовых и бортовых испытаний СЭС самол╦тов Бе-200 и А-50.

Анализ потоков данных и времени реакции в описанных выше системах позволяет утверждать, что CAN может быть использован для создания самого широкого спектра распредел╦нных систем с различными требованиями по пропускной способности сетевой шины и временам реакции.







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




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