PROTOCOLO CANopen El bus CAN solo tiene definidas las capas fsicas y de enlace, con el protocolo CANopen se implementa

la capa de aplicacin que permite asignar y utilizar los identificadores, a dems de datos de los mensajes. Para estandarizar la comunicacin en los sistemas y asegurar la funcionalidad de los dispositivos de distintos fabricantes se utiliza la capa de aplicacin y dos perfiles ms que permiten administrar el sistema, estos son: Capa de aplicacin: proporciona un conjunto de servicios y protocolos para los dispositivos de la red. Perfil de comunicacin: define cmo configurar los dispositivos y los datos, y la forma de intercambiarlos entre ellos. Perfiles de dispositivos: aade funcionalidad especfica a los dispositivos.

El protocolo CANopen se basa en la capa de aplicacin CAL (CAN Application Layer) desarrollado por Philips Medical System, conformada por 4 servicios como son: CMS (CAN-based Message Specification): ofrece objetos de tipo variable, evento y dominio para disear y especificar cmo se accede a la funcionalidad de un dispositivo a travs de su interfaz CAN. NMT (Network ManagemenT): proporciona servicios para la gestin de la red. Realiza las tareas de inicializar, arrancar, parar o detectar fallos en los nodos. Se basa en el concepto de maestro-esclavo, habiendo slo un NMT maestro en la red. DBT (DistriBuTor): se encarga de asignar de forma dinmica los identificadores CAN (de 11 bits), tambin llamados COB-ID (Communication Object Identifier). Tambin se basa en el modelo maestro-esclavo, existiendo slo un DBT maestro. LMT (Layer ManagemenT): permite cambiar ciertos parmetros de las capas como por ejemplo el identificador de un nodo (Node-ID) o la velocidad del bus CAN.

CMS define 8 niveles de prioridad en sus mensajes, cada uno con 220 COB-IDs, ocupando desde el 1 al 1760. Los identificadores restantes (0, 1761-2031) se reservan para NMT, DBT y LMT. Este estndar asume a CAN2.0A (CAN Standard Message Frame) con identificadores de 11 bits. Pero tambin es posible utilizar CAN2.0B (CAN Extended Message Frame) con identificadores de 29 bits. A continuacin se muestra la distribucin de los COB-ID en la capa de aplicacin:

Tabla1. Distribucin de los COB-ID

CANopen se encuentra por encima de CAL ya que es quien define los contenidos y tipos de objetos CMS utilizando un subconjunto del protocolo de comunicacin. CANopen es el diccionario de objetos (OD, Device Object Dictionary), este es un concepto utilizado por otros buses de campo. El diccionario de objetos CANopen es un grupo ordenado de objetos que describe la funcionalidad de cada dispositivo y permite su configuracin mediante mensajes SDO a travs del propio bus. Cada objeto se direcciona utilizando un ndice de 16 bits. Para permitir el acceso a elementos individuales de las estructuras de datos tambin existe un subndice de 8 bits.

Tabla 2. Estructura general del diccionario de objetos.

Para cada nodo de la red existe un OD (diccionario de objetos), que contiene todo los parmetros que describen el dispositivo y su comportamiento en la red. En CANopen hay documentos que describen perfiles. Un perfil define para cada objeto del diccionario su funcin, nombre, ndice, subndice, tipos de datos, si es obligatorio u opcional, si es de slo lectura, slo escritura o lectura escritura. CANopen maneja la distribucin de los identificadores de mensajes de forma tal que haya un mensaje de emergencia por cada nodo, mensaje de sincronizacin, un SDO, mensaje NMT y 4 PDO de trasmisin y recepcin por dispositivo, este identificador contiene 11 bits que son distribuidos as: 4 bits para el cdigo de funcin 7 bits para el identificador del nodo

Imagen 1. Estructura del identificador de mensajes

La distribucin de los identificadores corresponde con una estructura de tipo maestroesclavo. El maestro conoce los Node-IDs de todos los esclavos conectados (mximo 127). Pero dos esclavos no pueden comunicarse entre s ya que no conocen sus identificadores. El modelo de comunicaciones CANopen define cuatro tipos de mensajes objetos de la comunicacin como son: Objetos administrativos: permiten la configuracin de las distintas capas de red, su inicializacin, configuracin y supervisin. Se basa en los servicios NMT, LMS (LSS) y DBT de la capa CAL. SDO (Service Data Object): utilizados para leer y escribir cualquiera de las entradas del diccionario de objetos de un dispositivo. PDO (Process Data Objects): utilizados para el intercambio de datos de un proceso, en tiempo real. Mensajes predefinidos: de sincronizacin, emergencia y time stamp, se encargan de la sincronizacin de los dispositivos (objetos SYNC) y generan notificaciones de emergencia en forma opcional.

CANopen soporta modelos de comunicacin punto-a-punto, maestro-esclavo y productor-consumidor ya sea push o pull. En el modelo push los productores colocan los eventos en el canal y ste se los enva a los consumidores. En el pull el flujo de eventos ocurre en el sentido contrario, es decir, los consumidores solicitan eventos al canal y ste los solicita a los productores.

CANopen define dos tipos de transferencia para los SDO, esto depende de la longitud de datos que se desee enviar. La transferencia expedita es para datos con longitud de 4 bytes o menor (no es fragmentada), la transferencia de segmentos para una longitud de datos mayor de 4 bytes (es fragmentada). Al entrar en el diccionario de objetos del servidor es posible que se produzca un error, con el protocolo Abort DomainTransfer se notifica tanto a los clientes como a los servidores. Los mensajes PDO de un nodo o dispositivo pueden dividirse en dos categoras, los tPDO son mensajes con informacin del proceso que el nodo transmite (la lectura de un sensor) y los rPDO son mensajes con informacin del proceso que el nodo escucha (un nodo que controla la apertura de una bomba escuchar el bus en busca de rdenes). La transferencia de PDO se puede hacer de forma sncrona con eventos, temporizadores o una solicitud remota, por otro lado la transferencia puede ser asncrona de modo cclico o aciclico.