CAL – CAN протокол прикладного уровня для ... - datamicro.ru

CAL - CAN протокол прикладного уровня для промавтоматикиВ отличие от протоколов CANopenи DeviceNet, которые также определяютнепосредственную структуруи части приложения черезфиксированные методы доступадля представления и обменаданными (переменными), CAL неопределяет содержимое данныхили специфические объекты связи,которые должно обеспечиватьнекоторое устройство иликоторые ожидаются системой.Используя CAL, пользовательимеет возможность адаптироватьсистему связи точно к требованиямего приложения или системы.Следовательно, CAL протоколидеально подходит для реализацииспецифических системныхрешений подобно медицинскимили измерительным системам, атакже для реализации закрытыхсистем управления с децентрализованнымиинтеллектуальнымимодулями.Краткаяхарактеристика CALОсновная цель CAL – предоставлениеприкладному программистуинструмента для написания программногообеспечения распределенныхприложений, использующихCAN для объединения узловраспределенного приложения.CAL рассматривает программное обеспечение множестваустройств, объединенных в сеть, не как слабосвязанныеблоки, общающиеся между собой спомощью высокоуровневых сетевых протоколов, акак единое распределенное приложение, различныекомпоненты которого функционируют на различныхузлах сети. Таким образом, CAL предоставляеттот уровень абстракции, который позволяетконцептуально связать компоненты программногообеспечения сетевых узлов в единое целое, а такжеслужит хорошей основой для создания программногообеспечения тематических стандартов болеевысокого уровня.Многие стандарты промышленных сетевых протоколовне полностью содержат все уровни стандартноймодели OSI/ISO, и CAL не исключение (Рис. 1) [7].Приложениеменеджера сетиПриложения узла1 2 3Рис. 1. Модель CAN/CAL в эталонной модели OSI/ISO(без LMT сервиса)Причины отсутствия ряда слоев состоят в следующем:NNNMTCAN шинаDBTCMSПрикладной уровень OSI/ISO 7Представительский уровень. . .Сетевой уровеньПередачаКанальный уровеньCANпротокол4 OSI/ISO 3...6(Уровни отсутствуют)ПриемФизический уровень OSI/ISO 1Интерфейсы:1 Сервис менеджера сети2 Сервис менеджера узла3 Сервис обмена сообщениями4 Сервис канального уровняOSI/ISO 2Протоколы: Протокол менеджера сети Протокол обмена сообщениями Протокол распределения CAN протоколСама природа CAN не имеет возможности длямежсетевой маршрутизации, которую предоставляетсетевой уровень (Network Layer)В распределенных управляющих системах реальноговремени каждое сообщение передаетсясобственным кадром. CAL обеспечивает транспортировкупроизвольных данных большогоразмера на прикладном уровне. Кроме того, CANпротокол уже поддерживает некоторые аспектынадежного подключения. Поэтому транспортныйуровень (Transport Layer) также отсутствуетwww.datamicro.biz • (8634) 314-000 • www.datamicro.ru 4

CAL - CAN протокол прикладного уровня для промавтоматикиNNВ системах управления реальноговремени не используютсясвязи, ориентированныена сессию. Поэтому уровеньсессии (Session Layer) такжеотсутствуетCAL жестко определяет форматыданных для приложенийчерез правила кодирования(“Encoding Rules”). Поэтомупредставительный уровень(Presentation Layer) отсутствует.Стандарт CALПриложение XПриложение X Приложение YrequestrequestindicationconfirmresponseПодтверждаемый сервисЛокальный сервисПриложение X Приложение Y, Z, ...Приложение XrequestindicationindicationindicationindicationУслуги канального уровняВ CAN сообщение передаетсявнутри так называемого COB’а(Communication Object). КаждыйCOB способен перенести до8 байт данных и характеризуетсяуникальным идентификатором(COB-ID).Канальный уровень CAN предлагает примитивы,обеспечивающие широковещательную передачусообщений или чтение конкретного сообщения позапросу. Таким образом, данные не передаются наопределенный узел сети в рамках распределенногоприложения (node-oriented network). Каждыйузел, используя значение COB-ID, самостоятельнопринимает решение, требуются ли ему данные, содержащиесяв принятом пакете (message-orientednetwork). То есть, вообще говоря, приемник не знаетисточника принятых данных. Такая архитектура сохраняетсяи на прикладном уровне (CAL).Основные характеристики CALПрикладной уровень CAL предоставляет приложениючетыре сервисных элемента (serviceelements):NNNCAN Message Specification (CMS)Элемент сервиса определения сообщенийNetwork Management (NMT)Элемент сервиса управления сетьюDistributor (DBT)Элемент сервиса распределения CAN идентификаторовНеподтверждаемый сервисNLayer Management (LMT)Элемент сервиса управления уровнямиCAL протокол определен двояко: с одной стороныопределяются достаточно абстрактные сущностиприкладного уровня и набор так называемых сервисов,позволяющих оперировать этими сущностямив рамках распределенного приложения (ServiceSpecification), с другой – описываются протоколывзаимодействия этих абстрактных сущностейна уровне описания потоков данных в CAN сети(Protocol Specification) [4].Все сервисы CAL реализуются через сервисные примитивы(Рис. 2):NNNrequestЗапрос формируется приложением для передачина CAL уровеньindicationИндикация формируется CAL и оповещает приложениео поступлении данных или возникновениинекоторого события на CAL уровнеresponseCервис инициализациипоставщикаРис. 2. Типы сервиса прикладного уровняОтвет формируется приложением для передачина CAL уровень как реакция на ранее поступившуюиндикациюwww.datamicro.biz • (8634) 314-000 • www.datamicro.ru 5

CAL - CAN протокол прикладного уровня для промавтоматикиNconfirmПодтверждение формируется CAL и оповещаетприложение о поступлении ответаCMS – CAN cпецификациясообщенийСервисный элемент CMS (CANbasedMessage Specification)предоставляет собой язык описанияи манипуляции с объектамираспределенного приложения.Доступ узлов приложения к CMSобъектам осуществляется в моделиклиент-сервер.Имеется возможность использоватьтри типа объектов:NNNПеременныеСобытияДоменыПеременныеОбъекты типа Переменная(Variable) обеспечивают передачуданных, инициируемую клиентом.Переменные обеспечиваютобмен данными размером не бо-лее 8 байт, то есть обмен данными осуществляетсяс помощью передачи всего одного COB’a.Примером применения такого объекта может служитьтревожная сирена. Сервер объекта – узел,непосредственно управляющий сиреной. Клиент– узел, вырабатывающий управляющий сигнал навключение или выключение. Управление сиреной/******************************************************************************** Define CMS. Массив дескрипторов объектов*******************************************************************************/CMS_DEFINITIONS = {Def_VBWO_S ( BUZZER_CMD_CANDRV_CHAN, 1005, BOOLEAN ),Def_ES_S ( AC_STATE_CANDRV_CHAN, 402, STATE_RECORD, 0 ),Def_DM_S ( AC_DATA_CANDRV_CHAN, 403, 404, UNSIGNED8, 0 ),Def_VBWO_S ( AC_CMD_CANDRV_CHAN, 405, CMD_RECORD ),Def_EU_C ( AC_READ_LDATA_CHAN, 102, LDATA_ITEM )};/******************************************************************************** Define CMS. Индексы CMS объектов в массиве дескрипторов объектов*******************************************************************************/enum {BUZZER_CMD_CMS_HANDLE,AC_STATE_CMS_HANDLE,AC_DATA_CMS_HANDLE,AC_CMD_CMS_HANDLE,AC_LDATA_CMS_HANDLE};Рис. 4. Определение CMS объектовCMS модель для сиреныКлиентBuzzerOnOffCMSРеальный сигнална включениеBuzzerOnOff = TRUEСерверBuzzerOnOffПеременная “BuzzerOnOff” BasicWrityOnly BOOLEANРис. 3. Пример CMS модели для управлениясиреной Write Request (BuzzerOnOff, TRUE) Write Indication (BuzzerOnOff, TRUE)осуществляется передачей (записью) требуемогобулевского значения клиентом серверу (Рис. 3).Для описания каждого объекта стандарт предусматриваетсервис Define, определяющий атрибутыобъекта (Табл. 1).В зависимости от значений атрибутов Class и AccessType переменная может требовать одного COB’а дляпередачи данных от сервера клиенту – неподтверждаемыйсервис (Рис. 2), либо двух, в том случае,если протокол требует запроса и подтверждения(результата) – подтверждаемый сервис. НазначениеCOB’ов выполняется сервисным элементом DBT.Стандарт не фиксирует точного синтаксиса сервисаDefine в терминах какого-нибудь языка программирования.Это определяется конкретной реализациейCAL. Например, пакет dmCAL [10] не предполагаетдинамического распределения COB’ов (астандарт это допускает), и при определении пере-www.datamicro.biz • (8634) 314-000 • www.datamicro.ru 6

CAL - CAN протокол прикладного уровня для промавтоматикиТабл. 1. Атрибуты CMS объектовАтрибуты Тип объекта ОписаниеNameUser TypePriorityInhibit TimeData TypeError TypeVariable.EventVariable.EventКаждый CMS объект в рамках одного распределенного приложения имеетуникальное символическое имя, которое, безусловно, должно быть одно и тоже на клиентах и серверах объекта. Используется для динамического распределенияCOB-ID. При статическом распределении COB-ID имя может неиспользоваться.При определении объекта на узле распределенного приложения необходимоуказать, кем по отношению к объекту является узел – клиентом или сервером.Приоритет COB’а (ов), используемых объектом. Используется при динамическомраспределении COB-ID. При статическом распределении COB-ID неиспользуется, так как COB-ID’ы задаются при определении объекта.Время запрещения – минимальное время между двумя передачами COB’а.Каждый узел может указать собственное значение. При динамическом распределенииCOB’ов DBT укажет единое значение для всех узлов, использующихэтот объект.Передаваемые данные могут иметь различный тип. Тип служит для определенияразмера передаваемых данных и гарантирует одинаковое представлениеданных на разнотипных узлах.Подтверждаемые сервисы могут возвращать ошибки. Атрибут определяет типданных, соответствующих возвращаемому коду ошибки.Class Variable Переменная может относиться к одному из двух классов: базовая (Basic) илимультиплексная (Multiplexed). Для мультиплексной переменной дополнительнодолжны быть заданы Variable Set Name и Multiplexor. Несколько мультиплексныхпеременных на одном множестве используют одинаковые COB’ы.EventDomainСобытие может относиться к одному из трех классов: неуправляемое(Uncontrolled); управляемое (Controlled), клиент может запретить или разрешитьсерверу оповещение о событии; событие с памятью (Stored), серверосуществляет оповещение о событии, кроме того, клиент может прочестьданные события, как для ReadOnly переменной.Домен может относиться к одному из двух классов: базовый (Basic) илимультиплексный (Multiplexed). Мультиплексный домен благодаря различнымзначениям мультиплексора обеспечивает передачу различных данных некоторогоузла, используя один и тот же COB.Access Type Variable Тип доступа клиента к переменной. Допустимые значения:Variable SetNameMultiplexorMultiplexorData TypeMultiplexedVariablesMultiplexedVariablesMultiplexedDomainsNNNТолько для записи (WriteOnly), для такой переменной клиент может записатьновое значение переменной, сервис чтения значения переменнойотсутствуетТолько для чтения (ReadOnly), для такой переменной клиент может прочестьзначение переменной, сервис записи значения переменной отсутствуетДля чтения и записи (ReadWrite), клиент может как читать, так и писатьзначение переменнойИмя множества, объединяющего несколько мультиплексных переменных.Мультиплексные переменные, принадлежащие одному и тому же множеству,имеют один и тот (те) же COB-ID. Используется при динамическом распределенииCOB-ID.Мультиплексор (индекс), позволяющий различить мультиплексные переменныена одном множестве.Для правильной интерпретации мультиплексора на клиенте и сервере следуетобеспечить их одинаковое представление, что обеспечивается указаниемтипа данных мультиплексора.www.datamicro.biz • (8634) 314-000 • www.datamicro.ru 7

CAL - CAN протокол прикладного уровня для промавтоматикименной следует задавать COB(ы),и нет необходимости задаватьимя и приоритет. Для идентификацииCMS объектов в приложенииудобнее использовать не имя,а индекс в таблице объектов приложения(Рис. 4).Для манипуляции с переменнымистандарт предусматривает сервисычтения (Read), записи (Write)и обновления (Update) данных.На рис. 5 приведен фрагментпрограммы, реализующий серверBasic WriteOnly переменной дляуправления сиреной.Все сервисы CMS, реализуемыечерез примитив indication, требуютожидания поступления данных. Если на узлеприсутствует несколько CMS объектов, которыедолжны одновременно ожидать приема данных(например, сервер WriteOnly переменной и клиентсобытия), то реализовать такое ожидание удобнеевсего в рамках мультизадачной операционной системы.В таком случае реализация, например, сервераодной WriteOnly переменной будет представлятьсобой отдельную задачу.В зависимости от класса и способа доступа для обслуживаниясервисов приема/передачи может требоватьсяодин или два COB’а.СобытияОбъекты типа Событие (Event) обеспечивают передачуданных, инициируемую сервером. Событияобеспечивают обмен данными размером не более8 байт.Примером применения такогообъекта может служить датчиксчитывания смарт-карты, используемойв качестве пропуска (Рис.6). Сервер объекта – узел, содержащийсчитыватель и оповещающийзаинтересованные узлы оприкладывании пропуска. Клиент– узел, принимающий событие.Данные события – код пропуска.При определении события с помощьюсервиса Define необходимоуказать его атрибуты (см. Табл.1).//=== Задача управления сиренойvoid BuzzerOnOff_task(void){BOOL cData;Start_VBWO_S( BUZZER_CMD_CMS_HANDLE );for(;;) {Wait_VBWO_S_Indication( BUZZER_CMD_CMS_HANDLE, (byte*)&cData, NOTOUT );if( cData ) BuzzerOn();else BuzzerOff();} //for(;;)} //BuzzerOnOff_taskРис. 5. Задача – сервер Basic WriteOnly переменной,сервис WriteCчитывательсмарткартыСерверSmart-CardCмарткартаCMSCMS модель для смарткартыСобытие “Smart_Card” Stored CODE_RECORDРис. 6. Пример CMS модели считываниясмарт-карты…//=== Инициализация Stored Event – событие модуля доступаsData.stChange = 0;Start_ES_S( AC_STATE_CMS_HANDLE, (byte CMS_STORAGE*)&sData );…//=== Оповещение о событииsData.stChange = evPersonalPermit; // Событие – вставка карточки личного// пропускаmemmove( sData.stDat, COD, COD_LEN ); // Копирование кода пропускаStoreAndNotify_ES_S( AC_STATE_CMS_HANDLE, (byte CMS_STORAGE*)&sData );…Рис. 7. Фрагменты программы – сервер Storedсобытия, сервис NotifyКлиентSmart-Card NotifyRequest (Smart_Card, card_code) NotifyIndication (Smart_Card, card_code)www.datamicro.biz • (8634) 314-000 • www.datamicro.ru 8

CAL - CAN протокол прикладного уровня для промавтоматикиДля манипуляции с событиями стандарт предусматриваетсервисы оповещения (Notify), чтения(Read), обновления (Store) данных и изменениястатуса (SetControlState).На Рис. 7 приведен фрагмент программы, реализующийсервер Stored события для работы со считывателемпропусков.ДоменыОбъекты типа Домен (Domain) обеспечивают передачуданных, инициируемую клиентом. Размер массиваданных, вообще говоря, не ограничен.В качестве примера сервера мультиплексного доменаможно рассмотреть узел, выполняющий считываниеразличных данных с некоторого лабораторногооборудования. При этом мультиплексор будет определятьто, какие данные требуется получить клиенту(Рис. 8).При определении события с помощью сервисаDefine необходимо указать его атрибуты (см. Табл.1).Передача больших блоков данных с помощью доменаобеспечивается за счет разбиения блокаданных на сегменты, помещающиеся в один COB.Таким образом, для сегментированного приема ипередачи стандарт предусматривает сервисы инициализациипередачи (InitiateDomain Download, InitiateDomain Upload), собственнопередачи сегмента (DownloadDomain Segment, Upload DomainSegment) и прерывания обмена(Abort Domain Transfer). Причемесли инициатором обмена можетвыступать только клиент, то прерватьобмен может как клиент,так и сервер.При использовании сегментированногообмена ответственностьза правильность разбиения доменана сегменты и определениезавершения передачи лежит наприкладной программе. Если жеприменять не сегментированныйсервис (Domain Download,Domain Upload), то все управлениеобменом выполняет CAL.На Рис. 9 приведен фрагментпрограммы, реализующий сервермультиплексированного доменаCMS модель для считывания данныхлабораторного оборудованияCMS(см. Рис. 8).КлиентLab_DataМультиплексированный домен “Lab_Data” Multiplexed UNSIGNED8Типы данныхСерверLab_Data Download (Lab_Data, mux_value, data) Initiate Download (Lab_Data, mux_value) Segment Download (Lab_Data, mux_value, data)Рис. 8. Пример CMS модели для считыванияблока данныхСервисы определения переменных и событий содержататрибут типа данных. CMS определяет стандартныетипы данных и способы конструированияпроизводных типов данных. Использование типовvoid DataExchange_task(void){…Start_DM_S( AC_DATA_CMS_HANDLE );for (;;) {req = Wait_DM_S_Indication( AC_DATA_CMS_HANDLE, buf, NOTOUT, state );switch (req) {case cmsINITDOWN_REQ_DOM: //Инициализация загрузкиswitch( mux_value = *bDM_M(buf) ){…//Анализ мультиплексора}break;case cmsDOWN_REQ_DOM: //Запрос на очередной сегментswitch( mux_value ){…//Прием очередного сегмента}break;case cmsABORT_DOM: //Отказ от обменаstate = dtsINIT;continue;} //switch( req )Send_DM_S( AC_DATA_CMS_HANDLE, buf, (byte*)&mux_value );} //for(;;)} //DataExchange_taskРис. 9. Задача – сервер Multiplexed доменаwww.datamicro.biz • (8634) 314-000 • www.datamicro.ru 9

CAL - CAN протокол прикладного уровня для промавтоматикипозволяет абстрагироваться от внутреннего представленияданных в тех или иных процессорах и использоватьв рамках одного распределенного приложениясистемы, различающиеся по внутреннемупредставлению данных.Тип данных определяет так называемые правилакодирования (Encoding Rules) [4]. Эти правила четкоспецифицируют побитовый формат различныхтипов данных. Однако если в приложении используетсяформат отличный от того, который определенстандартом CAL, то ответственность за преобразованиележит на приложении. Более того, CAL неимеет достаточных средств контроля того, что дляодного и того же объекта на разных узлах используетсяодин и тот же тип данных. Гарантировать этодолжен прикладной программист, выполняющийинтеграцию распределенного приложения.Реализация dmCAL использует указание типа данныхпри определении CMS объекта для подключенияфункций преобразования CAL приложение длясоответствующего типа данных.NMT – управление сетьюСервисный элемент NMT (Network ManagemenT)отвечает за собственно сетевые аспекты распределенногоприложения. Сервисы уровня NMT не взаимодействуютс прикладными задачами (например,управлением производственным процессом).Для управления сетью NMT определяет три объекта:NNNnetwork objectСеть. Представляет собой набор описаний всехузлов (до 256) сети. Описание сети (т.е. networkobject) может находиться только на одном узлеCAN сети, называемом NMT Masternode objectУзел. Описание узла CAN сети в network objectна NMT Masterremote node objectУдаленный узел. Описание узла сети в модуле.Модули, содержащие такой объект, называютсяNMT SlaveДля каждого remote node object на NMT Slave должнасуществовать пара node object на NMT Master. НаРис. 10 представлена NMT модель CAL сети.Основные атрибуты node object и remote nodeobject:NNNNNMT Address – адрес узлаNodeID – номер узлаОба служат для идентификации узла и используютсяNMT сервисамиNodeClass – класс узлаNodeState – состояние узлаОпределяет доступные сервисы NMT и возможностьвыполнения сервисов CMSУзелОбъектNodeNMT SlaveNMT сервисУзелNMTпротоколОбъект NetworkОбъектОбъектRemote NodeRemote Объект NodeRemote NodeNMT Master/SlaveNMT сервисNMT сервисNMTпротоколОбъектNodeCAN сетьNMTсервисОбъектNodeNMT SlaveУзелРис. 10. Модель NMTwww.datamicro.biz • (8634) 314-000 • www.datamicro.ru 10

CAL - CAN протокол прикладного уровня для промавтоматикиТабл. 2. Ресурсы, используемые модулями системыМодуль обмена(RS-232/CAN)МодульдоступаПроходнаяSAB Siemens C505CA C505C C505C C505CXRAM 256 Byte 256 Byte 256 Byte 256 ByteДрайвер CAN [CODE] 0,7 kByte 0,7 kByte 0,7 kByte 0,7 kByteОС РВ [CODE] 0,5 kByte 0,5 kByte 0,5 kByte 0,5 kByteCAL [CODE] 1,5 kByte 2,5 kByte 2,5 kByte 2,5 kByteПриложение [CODE] 3,8 kByte 8,3 kByte 12,3 kByte 5,8 kByteВсе ПО [CODE] 6,5 kByte 12 KByte 16 kByte 9,5 kByteРазгрузкаNMT предоставляет три группы сервисов:NNNModule Control ServicesСервисы управления модулями обеспечиваютопределение node object и remote node object,инициализацию NMT Slave, а также смену состоянияобъектовError Control ServicesСервисы управления ошибками обеспечиваютобнаружение и обработку ошибок и отказов CANсети, удаленные ошибки обнаруживаются черезпротокол Node/Network GuardingConfiguration Control ServicesСервисы управления конфигурированием позволяютконфигурировать узлы, загружать и читатькод и данные приложения.Класс узла определяет набор поддерживаемыхузлом сервисов. Минимальный NMT класс соответствуеттак называемой минимальной NMT функциональности– статическое назначение NMT параметрови невозможность их изменения средствамиCAL.DBT – распределениеидентификаторовСервисный элемент DBT (DistriBuTor) обеспечиваетдинамическое назначение COB-ID’ов и Inhibit Time.Динамическое назначение идентификаторов позволяетосуществлять горячее подключение узлов иоперативную реконфигурацию сети.Для реализации процесса распределения используетсямодель Master/Slave, подобная модели NMT(Рис. 10). На DBT Master (который может бытьтолько один в сети) размещается COB Database, содержащаяинформацию, в первую очередь именавсех CMS объектов на всех узлах сети. DBT Slave(совпадающий с NMT Slave) может запросить у DBTMaster выполнение распределения идентификаторов.DBT предоставляет две группы сервисов:NNDistribution Control ServicesСервисы распределения обеспечивают динамическоеназначение идентификаторовConsistency Control ServicesСервисы этой группы обеспечивают возможностьпроверки корректности одноименных CMSобъектов, созданных на различных узлах.LMT – управление уровнямиСервисный элемент LMT (Layer ManagemenT) позволяетизменять NMT адрес и некоторые параметрыканального уровня сети (bit timing parameters).Возможность изменения NMT Address обеспечиваетвыполнение оперативной реконфигурации сети.Для реализации процесса распределения используетсямодель Master/Slave, подобная модели NMT(Рис. 10). Каждый LMT Slave обладает не изменяемымLMT Address (серийным номером), благодарякоторому LMT Master может идентифицировать LMTSlave, для которого требуется изменить или прочестьпараметры.Пакеты CAL протоколаСуществуещее на рынке программное обеспечение,реализующее CAL протокол, позволяет легкои быстро создавать CAL приложения. Так, напри-www.datamicro.biz • (8634) 314-000 • www.datamicro.ru 11

CAL - CAN протокол прикладного уровня для промавтоматикиТабло888888Весовая АВТОРазгрузка ЖДABBВесовая ЖДТабло888888A BBПроходнаяCANРазгрузкаАВТО12Отпускныевесы наводуТаганрогскийзаливAABBBBАВТО весыRS232УзелдоступаШлюзCANRS232ЛабораторияУзелдоступаЛаб. весы IЖД весыRS232CANШлюзCANRS232Лаб. весы IIЯМРRS232RS232CAN сеть технологического процессаРадиоEthernet на подсистемууправления и принятия решенияМастертех. процессаРис. 11. Структура системы управления приемки зерна на зерновой терминалмер, пакет CAL Protocol Software от фирмы IXXATAutomation GmbH 2 , который поставляется в исходномкоде, покрывает все коммуникационные задачи,определяемые спецификацией CAL. Это позволяетпроектировщику системы сконцентрироватьсятолько на его приложении.Согласно делению CAL на четыре сервисных элемента(см. Рис. 1), CAL Protocol Software такжесостоит из отдельных модулей. Пакет может бытьлегко сконфигурирован и адаптирован к функциональнымвозможностям, требуемым приложением.Это означает, что к прикладным задачам не будутдобавлены ненужные функциональные сетевыевозожности.Доступ к CAN контроллеру (например, передача иприем объектов) выполняется через интерфейс канальногоуровня данных, который также реализованв виде отдельного модуля. Это позволяет выполнятьпростую адаптацию пакета к различным CAN контроллерами ресурсам системы. Пакет доступен вверсиях Slave и Master/Slave.2 http://www.ixxat.comВ случае, если проектировщик желает полностьюотделить прикладную систему от процесса связи поCAN, он может воспользоваться интеллектуальнойинтерфейсной PC/CAN платой, например iPC-I 320/PCI (на контроллере от DALLAS Semiconductor, совместимомс 8051), iPC-I 165 (на контроллерах отSiemens), tinCAN (PCMCIA), и микрокодом пакетаCAL Windows DLL.Все функциональные возможности CAL протоколареализуются через API, который доступен в видеDLL для Windows 3.11, 95/NT (включая требуемыедрайверы). Доступна версия и для DOS, котораяможет быть легко перенесена на другие операционныесистемы, подобные VxWorks, VRTX или OS/2.Пакет CAL Windows DLL доступен в версиях Slave иMaster/Slave.Пример реализациираспределенной системы сиспользованием CALВсе примеры, приведенные в статье, взяты из реальногопроекта управления приемкой зерна наwww.datamicro.biz • (8634) 314-000 • www.datamicro.ru 12

CAL - CAN протокол прикладного уровня для промавтоматикизерновом терминале (г. Таганрог). Общая структурасистемы приведена на рис. 11.Цель системы – обеспечить съем и передачу информациииз разнообразного оборудования в подсистемуучета и принятия решений зернового терминала.Сеть объединяет и обеспечивает съем данныхи управление следующим оборудованием:NNNNNВесовые автомобильная – Лахта СВ-60000А (Петровес,Россия) и железнодорожная – Лахта СВ-100000АРазгрузки автомобильные и железнодорожнаяОтпускные морские весы – MWET (Buhler, Германия)Лабораторное оборудование для анализа качествазерна – высокоточные весы САРТ-ГОСМBP2100 (Сарториус, Россия)Ядерно-магнитный резонатор – Minispec (Bruker,Германия)Большая часть оборудования использует интерфейсRS-232 для управления и передачи данных. Каждаяединица оборудования оснащена двумя CAN узлами:шлюзом RS232/CAN и модулем доступа, обеспечивающимавторизацию оператора с помощью бесконтактнойReadOnly смарт-карты (фирма EM-MARIN)и учет транспорта с зерном с помощью “таблетки”iButton (фирма DALLAS Semiconductor).При разработке прикладного программного обеспечениябыл использован пакет dmCAL. Данныйпакет разработан на языке ANSI C. При реализациимодулей пакета использовались базовые программныесредства ОС РВ dmOS-51 2.0 [8] и драйвер CANканального уровня [9].Благодаря тому, что программы пакета написаны наязыке C, в процессе выполнения работы при незначительныхзатратах он был портирован для ОС РВRTX-51 Tiny (Keil Software), MS DOS и Windows 9x/NT.Основная проблема состояла в переносе драйвераCAN, так как использовались существенно разныеОС и различные CAN контроллеры.На написание прикладного ПО было затрачено около2 человеко/месяцев. Реализация подобного распределенногоприложения без использования CALпотребовала бы существенно больших временныхзатрат при большом количестве ошибок.Литература1. Jens Uphoff, Theory and Practi-cal Experience withCAL-based Indus-trial Control, Proc. of the FirstInt. CAN Conf. (iCC’94), CiA, Erlangen, Germany2. Wolfhard Lawrenz: “Vernetzte Systeme imAutomobil dez Zukunft – Modellbildung”, HohereLagen, Werkzeuge, forderkennzeichen: TV8933Prometheus Phase II, TIB Hannover, September19933. Третьяков С.А., «CAN на пороге нового столетия»,МКА, № 2, с. 54-65, 19994. CiA/DS201/DS207 CAL Specification, Version 1.1,February 19965. Wolfhard Lawrenz. CAN System Engineering.,Springer, 19976. Erich-Jurgen Heins, A Real-time PC with iRMX forWindows con-trols Medical System Components directlyvia a CAN Network, Proc. of the First Int. CANConf. (iCC’94), CiA, Erlangen, Germany7. CAN Specification. Version 2.0. 1991, Robert BoschGmbH8. ОС dmOS-51, v.2.0. Руководство программиста.DATAMICRO, Таганрог, октябрь 1998.9. Драйвер CAN-контроллера, v.2.0. Руководствопрограммиста. DATAMICRO, Таганрог, октябрь1998.10. Пакет CAL Slave, v.1.01. Руководство программиста.DATAMICRO, Таганрог, декабрь 1998.www.datamicro.biz • (8634) 314-000 • www.datamicro.ru 13