Валидация сообщений

Под валидацией понимается установление факта, что сообщение не содержит ошибок. Момент времени, в который устанавливается факт правильности сообщения, отличается для передатчика и приемника.

Сообщение считается достоверно переданным, если не было ошибок при передаче от начала до конца фрейма. Если сообщение содержало ошибку, оно автоматически повторяется в соответствии с текущими приоритетами.

Сообщение считается достоверно принятым, если не было обнаружен ошибок при его приеме. Если ошибка обнаружена, устройство посылает в шину флаг ошибки.

В CAN рассматривается 5 типов ошибок:

- ошибки передачи бита (контролируется уровень на шине и сравнивает с передаваемым. Ошибка обнаруживается во время передачи одного бита);

- ошибка стаффинга (обнаруживается при отсутствии бита стаффинга в 6-й позиции последовательности одинаковых битов);

- CRC-ошибка;

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

- ошибка уведомления (обнаруживается трансивером, если он не находит доминантное состояние в поле уведомления о получении).

Устройство, обнаружившее любую из перечисленных ошибок, сигнализирует об этом с помощью флага ошибки.[4]

3 Прикладной уровень: CANopen

Общие положения

Прикладной уровень модели OSI обеспечивает интерфейс между сетью и программным приложением, которое может взаимодействовать с аналогичными приложениями в других устройствах сети. На прикладном уровне реализуется также механизм синхронизации между устройствами.

К сожалению, разработка CAN закончилась на первых двух уровнях модели OSI. Это привело к появлению множества несовместимых между собой протоколов прикладного уровня, среди которых самыми распространенными и поддерживаемыми организацией CiA являются CANopen и DeviceNet.

Канальный уровень CAN, рассмотренный выше, практически невозможно использовать в SCADA-пакетах, поскольку он оперирует битами, фреймами, полями. Для написания же прикладных программ нужно использовать понятия: переменная, массив, событие, клиент, сервер, имя устройства и т. п.

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

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

- запрос приложения к прикладному уровню, публикуемый приложением для вызова сервиса;

- индикация, публикуемая прикладным уровнем для приложения, чтобы сообщить о внутренних событиях, обнаруженных прикладным уровнем или чтобы показать, что сервис запрошен;

- ответ, публикуемый приложением для прикладного уровня, чтобы ответить на ранее полученную индикацию;

- подтверждение, публикуемое прикладным уровнем для приложения, чтобы отчитаться о результатах ранее изданного запроса.

Cервисы также делятся на несколько типов сервисов:

- локальный сервис - который выполняет запрос приложения без взаимодействия с другими сервисами того же ранга;

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

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

- сервис, инициированный провайдером - вовлекает только локальный сервис.

CANopen предлагает серию стандартизованных коммуникационных механизмов и функций, выполняемых устройствами в сети (профилей). Серия профилей доступна и поддерживается организацией CiA (CAN in Automation); для ее использования не требуется лицензий.

Устройство в сети CANopen представляется состоящим из трех частей:

- коммуникационный интерфейс (к шине CAN) и программный протокол обмена;

- словарь объектов;

- интерфейс к устройствам ввода-вывода и прикладная программа.

Коммуникационный интерфейс и программный протокол обеспечивают сервис по передаче и получению через сеть коммуникационных объектов. Словарь объектов описывает типы данных, коммуникационные объекты и прикладные объекты, использованные в устройстве для обмена через интерфейс к устройствам ввода вывода. Прикладная программа обеспечивает внутреннее управление функциями устройства и интерфейсом к устройствам ввода-вывода.

Наиболее важной частью устройства в CANopen является словарь объектов. Под объектами понимаются типы данных, профили устройств, коммуникационные объекты, регистр ошибок. Каждый объект в словаре адресуется 16-битным индексом.

В CANopen используются следующие типы данных: Boolean, Integer, UnsignedN, Float, Date, Time, которые имеют общепринятый смысл. Имеется также несколько сложных типов данных для PDO и SDO параметров (Process Data Object - объект данных технологического процесса и Service Data Object - объект сервисных данных).

Объекты PDO и SDO используются для передачи данных. Сообщения PDO позволяют передавать данные в реальном времени. Существует два типа объектов PDO. Первый из них выполняет передачу данных (Transmit-PDO или TPDO), второй - прием данных (Receve- PDO или RPDO). Коммуникационные параметры PDO определяют его коммуникационные возможности и описываются в словаре объектов.

Объект SDO обеспечивает доступ к словарю объектов. SDO может использоваться также для передачи групп данных от клиента к серверу и наоборот.

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

Коммуникационная модель CANopen определяет различные коммуникационные объекты и сервисы, а также доступные режимы запуска передачи сообщений, поддерживает передачу синхронных и асинхронных сообщений. Синхронные сообщения используются для сбора данных или управления исполнительными устройствами. Синхронные сообщения передаются относительно сообщений синхронизации, которые определяются заранее; асинхронные сообщения могут передаваться в любое время.

В CANopen используют три типа взаимодействий между передающим и принимающим устройством:

- ведущий/ведомый;

- клиент/сервер;

- производитель/потребитель.