Распределенные сетевые системы характеризуются высоким уровнем сложности. Большинство распределенных приложений требует большего сервиса, чем это предоставляется канальным уровнем спецификации CAN и ISO 11898. Например, подуровень LLC (Logical Link Control) CAN-канального уровня данных не позволяет передать и запросить блок данных более чем 8 байт.
При отсутствии стандартов разработчик вынужден опускаться на регистрово-битовый уровень, что влечет риск ошибок, закрытость программного обеспечения и высокую стоимость разработки. Поэтому были созданы протоколы верхнего уровня для CAN-сетей.
Действующий стандарт CAN ограничивается спецификацией только двух самых нижних уровней эталонной семиуровневой модели взаимодействия открытых систем OSI/ISO – физического и канального (рисунок 2.1).
Рисунок 2.1 – Соотношение эталонной модели ISO/OSI и CAN-протоколов
На физическом уровне определяются физические характеристики канала связи и параметры сигналов.
Канальный уровень формирует основную единицу передаваемых данных – пакет и отвечает за дисциплину доступа устройства к каналу связи (Medium Access Control) и установление логического соединения (Logical Link Control).
Описываются физические параметры среды передачи данных (только в ISO 11898), форматы сообщений, процессы передачи данных длиной до 8 байт, механизмы обнаружения ошибок и др. Но за рамками стандарта остаются решения таких важных при разработке вопросов, как адресация узлов, распределение между ними CAN-идентификаторов, интерпретация содержимого фрейма данных, передача данных длиной более 8 байтов и др., то есть все то, что обычно рассматривается на более высоких уровнях, вплоть до 7-го прикладного. Сервисов двух нижних уровней может оказаться вполне достаточно, когда речь идет о разработке сравнительно простой сети, не планируемой к расширению и состоящей из созданных под нее узлов-модулей. Или, к примеру, стоит задача создать «закрытую» сеть на основе оригинального протокола. Но в подавляющем большинстве случаев практических CAN-разработок двух «стандартных» уровней оказывается недостаточно. Поэтому с самого начала опубликования CAN-спецификаций и выпуска первых CAN-компонентов как независимыми компаниями, так и ассоциациями по промышленной автоматизации непрерывно велась и продолжается до сих пор работа над созданием спецификаций протоколов верхнего уровня – HLP (Higher Level Protocol) для CAN-сетей.
Уже разработанные и существующие в настоящее время спецификации протоколов CAN HLP, как правило, имеют сжатую трехуровневую архитектуру (рисунок 2.1), включающую в себя два базовых уровня CAN-протокола, иногда дополняемых спецификациями физического уровня (соединители, кабели и т. п.), и прикладной уровень. Сервисные функции промежуточных уровней либо отсутствуют, либо включены в прикладной. Соблюдение полной иерархии уровней эталонной модели OSI/ISO в системах управления не требуется, кроме того, наличие дополнительных изолирующих межуровневых интерфейсов привело бы к потере производительности системы в режиме реального времени и сделало бы существенно менее предсказуемыми задержки прохождения сообщений в сети.
Преимущества использования стандартных HLP при разработке CAN-сетей очевидны и немалочисленны. Во-первых, в отличие от использования только сервисов ISO 11898 или Bosch 2.0A/B, вместе с тем или иным HLP разработчик использует уже готовые механизмы передачи данных любой длины, процедуры начальной инициализации, распределения идентификаторов и т. п., а кроме этого, часто и конкретную спецификацию физической среды: длина и топология шины, скорости передачи, типы кабелей, соединителей и т. п. – для своей области применения (например гидравлика, общественный транспорт), на подготовку и тестирование которой в реальных условиях уже потрачены силы большого числа разработчиков и экспертов. Во-вторых, появляется возможность интегрирования модулей сторонних производителей и простого наращивания сети в будущем, применения широкого спектра имеющихся на рынке инструментальных средств для того или иного HLP, что значительно снижает время и стоимость разработки и положительно сказывается на показателях надежности. В-третьих, протоколы HLP позволяют максимально эффективно задействовать многие преимущества CAN, особенно при работе в режиме реального времени. И, наконец, немалое число всевозможных групп пользователей и производителей оборудования для тех или иных HLP способны помочь решить разработчику его задачу.
Многочисленность существующих CAN-протоколов прикладного уровня – на сегодня их уже более четырех десятков – наряду с наличием метапротоколов (например, CAN Kingdom) в известной мере снимает проблему, связанную с оборотной стороной любой стандартизации и заключающуюся в ограничении свободы системного разработчика. Среди многообразия CAN HLP, представленных на современном рынке CAN-технологий, особого внимания заслуживают CAL, CANopen, CAN Kingdom, DeviceNet и SDS (Smart Distributed System), поддерживаемых ассоциацией CiA и получивших наибольшее распространение в последнее время.
