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

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 года (www.can-cia.org).Отличные характеристики CAN: широковещательный способ передачи (broadcasting), мультимастерность (multiMaster), превосходная обработка ошибок, различная среда передачи, наличие аппаратной поддержки - обусловили лавинное увеличение приложений на базе CAN и расширение областей применения: автомобильный и железнодорожный транспорт, авиация, судостроение, управление технологическим оборудованием, управление вооружениями и многие другие.

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

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

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

Дальнейшее развитие происходит как в направлении интеграции в одном микроконтроллере средств для аппаратной поддержки, помимо 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

Инструментальные средства разработки

Разработка сложных распредел╦нных систем на базе 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-протокола

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

Использование 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 (www.lin-subbus.org). Это сравнительно низкоскоростной протокол (до 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 может быть использован для создания самого широкого спектра распредел╦нных систем с различными требованиями по пропускной способности сетевой шины и временам реакции.