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

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 может быть использован для создания самого широкого спектра распределённых систем с различными требованиями по пропускной способности сетевой шины и временам реакции.