СПОСОБ И УСТРОЙСТВО ДЛЯ АДАПТИРУЕМОЙ К РАЗМЕРАМ ПАМЯТИ ПОСЛЕДОВАТЕЛЬНОЙ ПЕРЕДАЧИ ДАННЫХ Российский патент 2016 года по МПК G06F13/42 H04L12/40 

Область техники, к которой относится изобретение

Настоящее изобретение относится к способу и устройству для адаптируемой к размерам памяти последовательной передачи данных между по меньшей мере двумя абонентами в последовательной шинной системе. Уровень техники

Известен, например из семейства стандартов ISO 11898-1…-5, протокол сети контроллеров (CAN - сокр. от англ. "Controller Area Network"), а также расширение протокола CAN, называемое синхронизированным по времени, или синхровременным, протоколом CAN (TTCAN, сокр. англ. "Time-Triggered CAN"), ниже также называемые стандартом на протокол CAN. Используемый протоколом CAN метод управления доступом к среде передачи основан на побитовом арбитраже. При побитовом арбитраже несколько абонентских станций могут одновременно передавать данные по каналу шинной системы, не создавая помех для передачи данных. Кроме того, абонентские станции при передаче бита по каналу могут определять логическое состояние канала (0 или 1). Если значение посланного бита не соответствует определенному логическому состоянию канала, то доступ абонентской станции к каналу прекращается. В случае протокола CAN побитовый арбитраж обычно выполняется на основе идентификатора, содержащегося в передаваемом по каналу сообщении. После того как абонентская станция полностью отправила идентификатор в канал, она знает, что у нее есть право монопольного (исключительного) доступа к каналу. Таким образом, окончание передачи идентификатора соответствует началу временного интервала разрешения доступа, в течение которого абонентская станция может пользоваться каналом монопольно. Согласно протоколу CAN другие абонентские станции не могут обращаться к каналу, т.е. посылать в этот канал данные, до тех пор, пока ведущая передачу абонентская станция не передаст поле контрольной суммы, или циклического избыточного кода (CRC), входящее в структуру сообщения. Таким образом, момент окончания передачи поля CRC соответствует концу временного интервала разрешения доступа.

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

С неуклонно возрастающей степенью объединения оборудования современных транспортных средств сетями передачи данных и с внедрением дополнительных систем, улучшающих эксплуатационные качества транспортных средств, например в плане обеспечения безопасности движения или комфорта водителя и пассажиров, растут требования к передаваемым объемам данных и к допустимым временам задержки при передаче данных. Примерами таких систем являются системы управления динамикой движения, например электронная система поддержания курсовой устойчивости (ESP), системы помощи водителю, например система автоматического регулирования дистанции (САРД), или системы информирования водителя, например система распознавания дорожных знаков (см., например, описания соответствующих систем в Автотехническом справочнике фирмы "Бош" (Bosch Kraftfahrtechnisches Handbuch), 27-ое издание, 2011, изд-во Vieweg+Teubner).

В публикации DE 10311395 A1 описана система, в которой асинхронная последовательная связь в качестве альтернативы может осуществляться посредством асимметричного физического или симметричного физического протокола CAN, за счет чего для асинхронной связи достигается более высокая скорость или безопасность передачи данных.

В публикации DE 102007051657 A1 предлагается осуществлять в выделяемых на исключительной основе временных окнах протокола TTCAN асинхронную быструю передачу данных, не соответствующую протоколу CAN, что позволяет повысить объем передаваемых данных.

В статье G. Gena и A. Valenzano под названием "Overclocking of Controller Area Networks" ("Как повысить тактовую частоту в сетях контроллеров"), Electronics Letters, том 35, №22 (1999), стр. 1924, рассматриваются факторы влияния повышения опорной частоты шины в отдельных частях сообщений на достигаемую эффективную скорость передачи данных.

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

Раскрытие изобретения

Ниже рассматриваются сущность изобретения и его преимущества, а возможности осуществления изобретения представлены ниже в описании, поясняемом чертежами. Предмет изобретения не ограничивается представленными и рассматриваемыми вариантами его осуществления.

Преимущества изобретения

Настоящее изобретение относится к передаче сообщений, логическая структура которых соответствует стандарту ISO 11898-1 на протокол CAN, в шинной системе, включающей в себя по меньшей мере два устройства обработки данных, являющихся абонентами шины, т.е. участвующих в обмене данными по шине, причем указанная логическая структура включает в себя бит начала кадра, поле арбитража, поле управления, поле данных, поле циклического избыточного кода (CRC), поле подтверждения и последовательность конца кадра, а поле управления включает в себя код длины данных, содержащий информацию о длине поля данных.

В изобретении предлагается способ, отличающийся тем, что поле данных в сообщениях может иметь, в отличие от стандарта ISO 11898-1 на протокол CAN, более восьми байт, причем для установления размера поля данных значения четырех битов кода длины данных интерпретируют, по меньшей мере частично, иначе по сравнению со стандартом ISO 11898-1 на протокол CAN, для передачи данных между полем данных и прикладным программным обеспечением предусмотрено применение по меньшей мере одного буферного запоминающего устройства, и передаваемый объем данных по меньшей мере в случае, если размер поля данных отличается от размера используемого буферного запоминающего устройства, адаптируют соответственно разнице в размерах между полем данных и используемым буферным запоминающим устройством. Этим достигается то преимущество, что прикладное программное обеспечение можно продолжать использовать без изменений, а размер коммуникационного контроллера не требуется излишне увеличивать, даже если размер поля данных может быть увеличен по сравнению с предусмотренным стандартом на протокол CAN.

Если размер поля данных превышает размер используемого буферного запоминающего устройства, составляющий, как правило, восемь байт, то из поля данных принятого по шине сообщения целесообразно выбирать, по заданному или задаваемому методу выбора, объем данных, соответствующий размеру используемого буферного запоминающего устройства, в частности содержащий восемь байт, и передавать его в буферное запоминающее устройство. Если размер поля данных превышает размер используемого буферного запоминающего устройства, то в поле данных посылаемого по шине сообщения вносят содержимое буферного запоминающего устройства, помещая это содержимое по меньшей мере в одну заданную или задаваемую область поля данных сообщения, а оставшуюся область или оставшиеся области поля данных заполняют по заданному или задаваемому методу. Чтобы избежать излишнего прироста длины сообщения, целесообразно заполнять битами заполняемые области поля данных посылаемого по шине сообщения таким образом, чтобы в эти области не нужно было вставлять дополняющие биты (также называемые стаф-битами) согласно правилам стандарта ISO 11898-1 на протокол CAN.

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

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

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

Для обеспечения возможности прослеживания процесса выполнения используемого в соответствующем случае способа передачи данных целесообразно предусмотреть один или несколько дополнительных битов состояния, посредством которых прикладному программному обеспечению предоставляется информация, относящаяся к способу передачи данных, отличному от предусмотренного стандартом ISO 11898-1 на протокол CAN. При этом могут использоваться, например, биты состояния для уведомления об успешной посылке, для уведомления об успешном приеме или для уведомления о виде последней возникшей ошибки. В зависимости от частоты появления ошибок при использовании способа передачи данных, отличного от предусмотренного стандартом ISO 11898-1 на протокол CAN, целесообразно переключаться обратно на способ передачи данных по стандарту ISO 11898-1 на протокол CAN и сигнализировать об этом посредством еще одного бита состояния.

В запоминающем устройстве для сообщений и/или буферном запоминающем устройстве может быть предусмотрен один или несколько дополнительных битов сообщения, обозначающих способ передачи данных, использованный или подлежащий использованию для соответствующего сообщения. Здесь можно, например, вносить предусмотренные в сообщении метки.

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

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

Преимуществом является также возможность использования значительных частей теста соответствия CAN (стандарт ISO 16845). В предпочтительном варианте своего осуществления предлагаемый в изобретении способ передачи данных может комбинироваться с дополнениями, предусмотренными протоколом TTCAN (стандарт ISO 1 1898-4).

Краткое описание чертежей

Ниже подробнее рассматривается осуществление изобретения, поясняемое следующими чертежами.

На фиг. 1a показаны две альтернативы для структуры сообщений в формате CAN (основной и расширенный форматы сообщения) согласно стандарту ISO 11898-1 на протокол CAN, представляющему уровень техники. На фиг. 1б показаны две аналогичные альтернативы для формата сообщений, модифицированных в соответствии с изобретением в одном из вариантов его осуществления.

На фиг. 2 представлены различные возможности того, как содержимое кода длины данных может интерпретироваться в соответствии с изобретением иначе по сравнению со стандартом ISO 11898-1 на протокол CAN.

На фиг. 3 схематически представлен предусмотренный изобретением процесс приема в абонентской станции шинной системы в одном варианте осуществления изобретения.

На фиг. 4 схематически представлен предусмотренный изобретением процесс приема в абонентской станции шинной системы в еще одном варианте осуществления изобретения.

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

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

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

На фиг. 8 показан адаптированный соответственно этому варианту осуществления изобретения процесс приема, выполняющийся в абонентской станции шинной системы.

Осуществление изобретения

На фиг. 1a представлена структура сообщений в том виде, как она используется для передачи данных по шине CAN. Показаны оба различающихся формата сообщений, а именно основной (стандартный) и расширенный форматы. Предлагаемый в изобретении способ в соответствующих вариантах его осуществления применим в равной мере к обоим форматам.

Сообщение начинается битом начала кадра (SOF - сокр. от "Start of Frame"), сигнализирующим о начале сообщения. К этому биту примыкает участок, который служит, в первую очередь, для идентификации сообщения и на основании которого абоненты шинной системы решают, принимать или не принимать это сообщение. Этот участок сообщения называется полем арбитража и содержит идентификатор. Далее следует поле управления (контрольное поле), которое содержит, в том числе, код длины данных. Код длины данных содержит информацию о размере поля данных сообщения. К полю управления примыкает поле данных, содержащее собственно данные, которыми между собой обмениваются абоненты шинной системы. Далее следует поле циклического избыточного кода (CRC) с содержащей 15 битов контрольной суммой и разделителем, а затем - два бита подтверждения (ACK), которые служат для того, чтобы сигнализировать отправителю об успешном приеме сообщения. Завершается сообщение последовательностью конца кадра (EOF - сокр. от "End of Frame").

При осуществлении способа передачи данных по протоколу CAN поле данных может содержать максимум 8 байт, т.е. 64 бит, информации. Код длины данных содержит согласно стандарту четыре бита, т.е. может принимать шестнадцать различных значений. Из этой области значений в современных шинных системах используется лишь восемь различных значений для различных размеров поля данных от 1 до 8 байт. Поле данных размером 0 байт в стандарте на протокол CAN не рекомендуется, а размеры поля данных свыше 8 байт не допускаются. Соотношение значений кода длины данных с размерами поля данных для обычных сообщений по стандарту CAN представлено в таблице на фиг. 2, в столбце "обычн. CAN".

На фиг. 1б в аналогичном фиг. 1a представлении показаны модифицированные сообщения, передаваемые в соответствии с изобретением и построенные, соответственно, на основе двух предусмотренных стандартом форматов.

При осуществлении способа передачи данных, модифицированного в соответствии с изобретением, поле данных уже может содержать более 8 байт, а именно, в рассматриваемом случае, до K байт. В отличие от стандарта CAN, другие значения, принимаемые кодом длины данных, могут использоваться для обозначения больших полей данных. Например, вышеупомянутые четыре бита кода длины данных могут использоваться для представления значений от нуля до 15 байт. Вместе с тем, можно использовать и другие соотношения, например, значение кода длины данных DLC=0b0000, которое в настоящее время в сообщениях CAN обычно не используется, можно использовать для еще одного возможного размера поля данных, например для размера 16 байт.

Эти две возможности представлены в приведенной на фиг. 2 таблице столбцами DLC 1 и DLC 2. Максимальный размер поля данных К имеет в этих случаях значение 15 и 16 байт, соответственно. Еще одна возможность заключается в том, чтобы для значений кода длины данных, превышающих 0b1000 и составляющих до 0b1111, соответствующие размеры поля данных увеличивались с большим приращением. Пример этого случая представлен в таблице столбцом DLC 3. Максимальный размер поля данных K достигает в этом варианте значения 64 байт. Разумеется, возможен и другой выбор приращения размера поля данных, например приращения 4 байта.

Для обеспечения возможности определения предлагаемым в изобретении коммуникационным контроллером того, каким образом он должен интерпретировать содержимое кода длины данных, целесообразно, чтобы он самостоятельно узнавал, осуществляется ли связь в шинной системе по стандарту CAN или согласно предлагаемому в изобретении способу. Одна из возможностей для этого заключается в использовании зарезервированного бита, находящегося внутри поля арбитража или поля управления, для обозначения сообщения меткой, чтобы из этой метки коммуникационный контроллер мог вывести первое условие переключения (т.е. сделать вывод о наличии такого условия переключения), в зависимости от которого он выбирает способ передачи данных. Например, в качестве метки можно использовать второй бит поля управления, обозначенный на фиг. 1б как r0.

Установление того или иного способа передачи данных также может выбираться в зависимости от формата идентификатора. Так, в случае основной адресации, т.е. адресации по основному формату сообщений, одной возможностью обозначения соответствующих изобретению сообщений является вставка рецессивного бита увеличенной длины данных (EDL - сокр. от "Extended Data Length") в поле управления в положение бита r0, который в сообщениях, соответствующих стандарту на протокол CAN, всегда доминантен. В случае расширенной адресации, т.е. адресации по расширенному формату, рецессивный бит EDL может занимать в поле управления положение бита r1, всегда доминантного в сообщениях, соответствующих стандарту на протокол CAN.

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

Еще одна возможность заключается в том, чтобы предписать для модифицированного в соответствии с изобретением способа передачи данных использование расширенного формата сообщений. Сообщения в расширенном формате распознаются абонентами шины по значению бита расширения идентификатора (IDE, см. фиг. 1a), и этот бит одновременно может представлять первое условие переключения UB1, так чтобы для сообщений расширенного формата всегда применялся модифицированный способ передачи данных. В качестве альтернативы этому решению, в сообщениях расширенного формата в качестве метки, или для вывода первого условия переключения может использоваться зарезервированный бит r1. Вместе с тем, этот зарезервированный бит также можно использовать, как это поясняется ниже, для вывода второго условия переключения, инициирующего переключение между более чем двумя различными размерами поля данных, или соотношениями значений кода длины данных с размерами поля данных.

В качестве альтернативы, предлагаемый в изобретении способ может использоваться в подходящих для этого коммуникационных контроллерах, которые даже не рассчитаны на осуществление связи в соответствии со стандартом на протокол CAN. В этом случае можно обходиться и без установления наличия или отсутствия вышеназванного первого условия переключения, например в зависимости от соответствующей метки, обозначающей сообщения. Напротив, коммуникационные контроллеры работают в этом случае исключительно согласно одному из описанных способов, и соответственно этому могут применяться только в шинных системах, в которых используются исключительно такие выполненные согласно изобретению коммуникационные контроллеры. Содержащиеся внутри сообщения бит или биты, которые в иных ситуациях привлекались для обозначения предлагаемых в изобретении сообщений с целью их выделения из соответствующих стандарту сообщений, в данном случае также могут не использоваться, или могут игнорироваться абонентами шины, т.е. участниками связи, применительно к предлагаемому способу передачи данных.

В случае увеличения поля данных сообщений, как это предусмотрено в изобретении, также может быть целесообразным адаптировать используемый метод контроля целостности данных с помощью циклического избыточного кода (CRC), чтобы достичь достаточной устойчивости к ошибкам. В частности, в этом отношении может быть выгодным использовать иной полином CRC, например полином более высокого порядка, и соответственно предусмотреть в модифицированных в соответствии с изобретением сообщениях поле CRC, отличающееся по размеру от предусмотренного стандартом. Это отражено на фиг. 1б, где показано, что в представленном примере поле CRC в соответствующих изобретению сообщениях имеет длину L бит, причем число L, в отличие от стандарта на протокол CAN, может быть неравным 15, в частности может быть больше 15.

Об использовании модифицированного метода вычисления контрольной суммы CRC абонентам шины можно сигнализировать посредством метки, представляющей третье условие переключения. Эта метка и третье условие переключения также может совпадать с первой меткой и/или первым условием переключения. В этом случае меткой также может служить, например, зарезервированный бит r0, показанный на фиг. 1б, или может использоваться бит SRR, как это описано выше. В сочетании с применением способа в сообщениях расширенного формата также возможно использование бита IDE или же бита r1.

В соответствующих стандарту CAN контроллерах код CRC посылаемых сообщений CAN генерируется посредством сдвигового регистра с обратной связью, на вход которого поочередно подаются последовательно посылаемые биты сообщения. Ширина, или разрядность, сдвигового регистра соответствует порядку полинома CRC. Кодирование кодом CRC осуществляется путем логического объединения содержимого регистра с полиномом CRC во время операций сдвига. Соответственно, при приеме сообщений CAN последовательно принимаемые биты сообщения подаются в сдвиговый регистр CRC. Контроль с помощью кода CRC считается успешным, если в конце поля CRC все биты сдвигового регистра имеют значение "ноль". Как генерация кода CRC в случае передачи, так и контроль с помощью кода CRC в случае приема выполняются на аппаратном уровне, не требуя вмешательства в программные средства. Таким образом, модификация кодирования кодом CRC не затрагивает прикладного программного обеспечения.

В возможном варианте осуществления изобретения коммуникационный контроллер рассчитывают таким образом, чтобы он обладал совместимостью со стандартом на протокол CAN, т.е. чтобы в шинной системе CAN он работал согласно стандарту на соответствующий протокол, а в шинной системе, модифицированной в соответствии с изобретением, он, с одной стороны, допускал в сообщениях большие поля данных, а с другой стороны - обеспечивал адаптированные, или скорректированные, вычисление и проверку контрольной суммы CRC.

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

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

Описанная реализация двух параллельно работающих сдвиговых регистров CRC делает возможным еще одно усовершенствование: Полином CRC, предусмотренный стандартным протоколом CAN (x15+x14+x10+x8+x7+x4+x3+1), рассчитан на длину сообщений менее 127 битов. Если в сообщениях, передаваемых в соответствии с изобретением, используются более длинные поля данных, то для поддержания надежности передачи целесообразно использовать другой, в частности более длинный, полином CRC. Соответственно этому, сообщения, передаваемые в соответствии с изобретением, получают измененное, в частности более длинное, поле CRC. В процессе работы коммуникационные контроллеры динамически переключаются с одного сдвигового регистра CRC на другой, т.е. между сдвиговым регистром, работающим соответственно стандарту на протокол CAN, и сдвиговым регистром, работающим в соответствии с изобретением, чтобы использовать подходящий в соответствующем случае полином.

Естественно, в зависимости от длины поля данных или требуемой надежности передачи можно использовать, в определенной градации, и более двух сдвиговых регистров, а соответственно - и более двух полиномов CRC. В этом случае необходимо, если требуется сохранить совместимость со стандартом на протокол CAN, адаптировать соответствующую метку и связанное с ней условие переключения. Например, зарезервированным битом r0 или битом SRR, показанным на фиг. 1б, может инициироваться наступление первого условия переключения, означающего переключение на более длинные поля данных, например, указанные в столбце DLC 1 таблицы на фиг. 2, и на соответствующий второй полином CRC. Для сообщений в расширенном формате дополнительно может быть инициировано наступление второго условия переключения, обозначаемого, например, показанными на фиг. 1б зарезервированным битом r1 или битом IDE и означающего переключение на другой набор размеров поля данных, например указанный в столбце DLC 3 таблицы на фиг. 2, и третий полином CRC.

Впрочем, возможен также вариант, в котором первое условие переключения, обозначаемое, например, зарезервированным битом r0 или битом SRR, обеспечивает переключение на возможность использования более длинных полей данных и на соответствующую интерпретацию содержимого кода длины данных, и тогда установление наличия третьего условия переключения и сопутствующий этому выбор полинома CRC, анализируемого для проверки контрольной суммы CRC, производится в зависимости от содержимого кода длины данных. Третье условие переключения, соответственно, также может принимать более двух значений. Например, размеры поля данных могут выбираться в соответствии со столбцом DLC 3 таблицы на фиг. 2, т.е. могут принимать значения от 0 до 64 байт, и тогда контрольные суммы могут вычисляться параллельно на основании трех полиномов CRC посредством соответствующих сдвиговых регистров, например, на основании соответствующего стандарту полинома CRC - для полей данных размером до 8 байт, второго полинома CRC - для полей данных размером до 24 байт и третьего полинома CRC - для полей данных размером до 64 байт.

На фиг. 3 в упрощенном представлении показан фрагмент предлагаемого в изобретении процесса приема сообщения, выполняющегося в абонентской станции шинной системы. Здесь представлен случай обеспечения совместимости со стандартом на протокол CAN, достигаемой за счет того, что поведение коммуникационного контроллера адаптируется, или корректируется, в зависимости от первого условия переключения. Хотя на фиг. 3 выбрано представление, обычное для описания процессов выполнения программ, предлагаемый в изобретении способ полностью пригоден для его реализации аппаратными средствами. Представленная схема применима также к вариантам осуществления изобретения, в которых условия переключения, например описанное выше условие переключения UB1, не используются. Однако процесс приема упрощен поскольку, поскольку в действительности проходится лишь один из путей его алгоритма, вообще проходимых в зависимости от соответствующего условия переключения. Отдельное представление такой упрощенной блок-схемы здесь не приводится.

Абонентская станция сначала находится в состоянии прослушивания шины, пока на шине отсутствует обмен информацией. Таким образом, в состоянии опроса 302 станция ждет прохождения по шине доминантного бита. Этот бит характеризует начало нового сообщения.

Как только обнаружено начало нового сообщения, в блоке 304 начинается вычисление по меньшей мере двух параллельно вычисляемых контрольных сумм. Первая контрольная сумма вычисляется с помощью кода CRC согласно стандарту на протокол CAN, а вторая контрольная сумма вычисляется согласно новому методу.

Затем, начиная с шага 306, принимаются биты сообщения, следующие за битом начала кадра (SOF) и начинающиеся полем арбитража. Если передать сообщение хотят несколько абонентов шины, они при этом соревнуются между собой по методу, известному из стандарта на протокол CAN, за получение доступа к шине. Представленный блок 306 характеризует прием всех битов до приема первой метки, или установления наличия первого условия переключения. В приведенных примерах наличие первого условия переключения устанавливается на основании поля арбитража, например бита SRR или бита IDE, или на основании поля управления, например находящегося в нем зарезервированного бита (см. фиг. 1). Затем в блоке 308 могут приниматься и другие биты сообщения, пока с определенного бита сообщения в зависимости от установленного первого условия переключения процесс приема не пойдет иным образом. Это разветвление процесса на различные методы обеспечивается соответствующим запросом или разветвлением 310, как это для примера показано ниже.

Если при разветвлении 310, например после приема первых двух битов поля управления, имеется информация о том, что согласно первому условию переключения связь осуществляется по стандарту на протокол CAN (ветвь "1" на фиг. 3), на шаге 312 считываются дальнейшие биты поля управления. На основании этих битов согласно стандарту на протокол CAN анализируется код длины данных и затем на шаге 316 принимается соответствующий объем данных, максимум 8 байт, соответственно полю данных. Затем на шаге 320 принимается поле CRC, содержащее 15 битов. Если при разветвлении 324 имеется информация о том, что контрольная сумма CRC, которая была отправлена передатчиком, совпадает с контрольной суммой CRC, определенной самим приемником, в блоке 328 посылается доминантный бит подтверждения. Следует иметь в виду, что в этом случае сравниваются контрольные суммы CRC, вычисляемые по стандарту, поскольку связь осуществляется по стандарту на протокол CAN. Если совпадения контрольных сумм не установлено, бит подтверждения посылается рецессивным (блок 330). Затем следуют разделитель подтверждения (разделитель ACK) и биты конца кадра (EOF), см. фиг. 1б, на фиг. 3 не показано.

Если же при разветвлении 310, например после приема первых двух битов поля управления, имеется информация о том, что согласно первому условию переключения использованию подлежит модифицированный соответствии с изобретением способ связи (ветвь "2" на фиг. 3), в блоке 314 считываются дальнейшие биты поля управления. По результату считывания определяется код длины данных, анализируемый в соответствии с новой интерпретацией, приведенной для некоторых примеров в виде таблицы на фиг. 2. В блоке 318 принимается соответствующий объем данных, т.е. до 15 байт данных для приведенного в таблице на фиг. 2 примера DLC 1, до 16 байт данных для примера DLC 2 и до 64 байт данных для примера DLC 3. В блоке 322 принимается поле CRC, которое в соответствии с изобретением отличается от предусмотренного стандартом, в частности является более длинным. Если при разветвлении 324 имеется информация о том, что контрольная сумма CRC, отправленная передатчиком, и контрольная сумма CRC, определенная самим приемником, совпадают, причем в этом случае сравнение контрольных сумм CRC основано на методе их вычисления, который в соответствии с изобретением отличается от предусмотренного стандартом, в блоке 328 посылается доминантный бит подтверждения. В противном случае (блок 330) бит подтверждения посылается рецессивным. Затем на шаге 332 (для одной ветви алгоритма) и 334 (для другой ветви алгоритма) следуют разделитель ACK и биты конца кадра (EOF). На этом процесс приема сообщения завершается.

На фиг. 3 отражен случай, в котором третье условие переключения, определяющее подлежащий использованию код CRC, совпадает с первым условием переключения, относящимся к размеру поля данных и интерпретации кода длины данных. Это значит, что перед приемом 320 (для одной ветви алгоритма) и 322 (для другой ветви алгоритма) контрольных сумм CRC отдельный запрос того, какая контрольная сумма CRC подлежит приему согласно третьему условию переключения и анализу для принятия решения при разветвлении 324, не выполняется. Путем простой модификации алгоритма, блок-схема которого приведена на фиг. 3, этот дополнительный запрос можно включить в процесс приема, как это показано на фиг. 4.

При осуществлении модифицированного таким образом процесса приема, показанного на фиг. 4, после приема поля данных с числом байтов, ожидаемым согласно информации, содержащейся в коде длины данных, в блоке 316 (для одной ветви алгоритма) и 318 (для другой ветви алгоритма) при запросе или в разветвлении 410 определяется, какое значение имеет третье условие переключения. Как описано выше, эта информация может быть определена, например, по соответствующей третьей метке или из содержимого кода длины данных. В представленном примере имеется три различных значения третьего условия переключения, а именно значения A, B и C. Затем в зависимости от значения условия переключения в блоках 420, 422 и 424 считывается различное число битов поля CRC, например 15 битов для значения A, 17 битов для значения B и 19 битов для значения C. Затем при разветвлении 324 проверяется, аналогично представленному на фиг. 3 алгоритму, совпадают ли контрольная сумма CRC, отправленная передатчиком, и контрольная сумма CRC, определенная самим приемником, и дальнейшие действия выполняются в зависимости от результата проверки.

На фиг. 5 для других вариантов осуществления предлагаемого в изобретении способа передачи данных еще раз показана структура сообщений в двух возможных вариантах, соответствующих основному и расширенному форматам сообщений. Для обоих вариантов на фиг. 5 обозначены области, в которых выполняется переключение между двумя состояниями, называемыми здесь состоянием арбитража в быстром режиме CAN и состоянием передачи данных в быстром режиме CAN. Это переключение между двумя состояниями ведет в данном примере к тому, что после завершения арбитража для части сообщения, в частности для поля данных и поля CRC, значения длительности бита уменьшаются, чем достигается более быстрая передача отдельных битов по шине. Благодаря этому можно сократить время передачи сообщения по сравнению со способом, соответствующим стандарту. Соответствующее чередование значений длительности бита может быть реализовано в процессе работы ("на лету"), например, путем использования по меньшей мере двух различных коэффициентов масштабирования для установки шинной единицы времени по отношению к наименьшей единице времени или к такту опорного генератора. Переключение длительности бита, а также соответствующее изменение коэффициента масштабирования также представлены для примера на фиг. 5.

Переход между состояниями арбитража в быстром режиме CAN и передачи данных в быстром режиме CAN может происходить в зависимости от дополнительного условия переключения, корреспондирующего с меткой сообщений, сигнализирующей участвующим в передаче данных абонентам о применении сокращенной длительности бита. В представленном здесь варианте осуществления изобретения выбранным положением этой метки является зарезервированный бит r0, передаваемый перед кодом длины данных. Таким образом, это положение соответствует возможному положению первой метки, корреспондирующей первому условию переключения и обозначающей возможное использование более длинных полей данных и измененной интерпретации кода длины данных, а также положению третьей метки, корреспондирующей измененному вычислению контрольной суммы CRC.

Другая возможность обозначения соответствующих изобретению сообщений с сокращенной длительностью бита представлена на фиг. 7. Здесь сообщения с потенциально более длинными полями данных (обозначены первой меткой) и измененным вычислением контрольной суммы CRC (обозначено третьей меткой) отмечены рецессивным битом-маркером увеличенной длины данных (EDL), который находится на месте бита, передаваемого доминантным в сообщениях, соответствующих стандарту на протокол CAN, и замещает этот бит или сдвигает его назад на одно положение, или на один разряд. В случае основной адресации бит EDL помещается во второе положение в поле управления и сдвигает находящийся там бит r0, всегда доминантный, на одно положение. В случае расширенной адресации бит EDL в показанном примере помещается в первое положение поля управления и замещает находящийся там зарезервированный бит rl, который по стандарту на протокол CAN всегда передается доминантным.

Другая, или четвертая, метка, указывающая на применение сокращенной длительности бита, реализована вставкой дополнительного рецессивного бита переключения битовой скорости (BRS - сокр. от "Bit Rate Switch") в поле управления соответствующих изобретению сообщений, помеченных битом EDL. В представленном здесь варианте осуществления изобретения бит BRS занимает четвертое (при основной адресации) или третье (при расширенной адресации) положение в поле управления.

Сообщения обозначены как кадры данных CAN, модифицированные под быстрый режим ("CAN FD Fast"). Для двух возможных вариантов адресации сообщений: основного формата и расширенного формата, на фиг. 7 указаны области, в которых выполняется переключение между двумя состояниями, называемыми состоянием арбитража в быстром режиме CAN и состоянием передачи данных в быстром режиме CAN. Как было отмечено выше, это переключение между двумя состояниями обеспечивает то, что для соответствующей части сообщения значения длительности бита уменьшаются, чем достигается более быстрая передача отдельных битов по шине. Благодаря этому можно сократить время передачи сообщения по сравнению со способом, соответствующим стандарту. Переход между состояниями арбитража в быстром режиме CAN и передачи данных в быстром режиме CAN происходит в сообщениях, имеющих первую или третью метку EDL, в зависимости от другой метки BRS, сигнализирующей участвующим в передаче данных абонентам о применении сокращенной длительности бита.

В представленном случае, т.е. когда за первой меткой EDL следует вторая метка BRS, в соответствии с предлагаемым в изобретении способом передачи данных передаются сообщения, длительность бита в которых заметно сокращена, размер поля данных которых может быть растянут до значений, превышающих 8 байт, и у которых код CRC адаптирован к большему полю данных, т.е. согласован с ним. Таким образом достигается значительное увеличение пропускной способности шинной системы при одновременно повышенной надежности передачи данных.

Ускоренная передача начинается в представленном примере сразу после отправки соответствующей метки и завершается сразу после достижения бита, заданного в качестве указателя обратного переключения, или в случае, когда обнаружена причина для отправки кадра ошибки.

На фиг. 8 показан процесс приема, модифицированный по сравнению с показанным на фиг. 3, в котором дополнительно, в зависимости от второй метки BRS, осуществляется переключение между состояниями арбитража в быстром режиме CAN и передачи данных в быстром режиме CAN. Если при разветвлении 310, например, после приема второго бита поля управления в виде рецессивного бита EDL, имеется информация о том, что использованию подлежит модифицированный соответствии с изобретением способ связи, в блоке 408 считываются следующие биты поля управления. Если служащий в качестве второй метки бит, например четвертый бит BRS расширенного в соответствии с изобретением поля управления, принимается с предусмотренным значением, например рецессивным, то выполняется, например в точке выборки этого бита, переход в состояние передачи данных в быстром режиме CAN, т.е. переключение на сокращенную длительность бита (ветвь "C"). Если соответствующий бит имеет противоположное значение, т.е. в данном примере является доминантным, то сокращения длительности бита не происходит (ветвь "B"). В блоках 412 (для одной ветви алгоритма) и 414 (для другой ветви алгоритма) осуществляется прием оставшихся битов поля управления, в том числе кода длины данных, и прием поля данных согласно информации о размере последнего, полученной из кода длины данных. В блоке 412 прием ведется с нормальной длительностью бита, а в блоке 414 - с сокращенной длительностью бита. В блоках 416 (для одной ветви алгоритма) и 418 (для другой ветви алгоритма) считывается поле CRC, которое в соответствии с изобретением отличается от предусмотренного стандартом, в частности является более длинным. На последнем бите поля CRC, представляющем собой разделитель CRC, в блоке 418 снова осуществляется переключение в состояние арбитража в быстром режиме CAN с обычной скоростью передачи данных. Затем при разветвлении 324 проверяется, аналогично представленному на фиг. 3 алгоритму, совпадают ли контрольная сумма CRC, отправленная передатчиком, и контрольная сумма CRC, определенная самим приемником, и дальнейшие действия выполняются в зависимости от результата проверки, как уже было показано на фиг. 3.

Ускоренная передача начинается, например, сразу после отправки соответствующей метки и завершается сразу после достижения бита, заданного в качестве указателя обратного переключения, или в случае, когда обнаружена причина для отправки кадра ошибки.

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

Кроме того, предлагаемый в изобретении способ может применяться в промышленной автоматике, например для передачи управляющей информации между распределенными, соединенными друг с другом шиной блоками управления, которые управляют выполнением промышленного технологического процесса. В этой среде также могут использоваться линии шины очень большой протяженности, и потому может быть особенно целесообразным эксплуатировать шинную систему так, чтобы в фазе арбитража она работала при относительно большой длительности бита, например 16, 32 или 64 микросекунды, что позволяло бы сигналам на шине распространяться в процессе арбитража требуемым образом по всей шинной системе. Тогда впоследствии для части сообщения можно переключаться, как было описано, на меньшие значения длительности бита, чтобы не давать средней скорости передачи стать слишком малой.

В целом предлагаемый в изобретении способ представляет собой способ передачи данных, который отличается тем, что контроллер, поддерживающий обычный режим CAN, требует внесения лишь минимальных изменений для того, чтобы он мог работать в соответствии с изобретением. Предлагаемый в изобретении коммуникационный контроллер, способный работать также в обычном режиме CAN, лишь незначительно больше обычного контроллера, поддерживающего обычный режим CAN. Соответствующую прикладную программу изменять не требуется, и даже тогда достигаются преимущества в скорости передачи данных. Благодаря использованию увеличенного размера поля данных и относящихся к нему кода длины данных (DLC) и циклического избыточного кода (CRC) можно еще более увеличить скорость передачи данных, а изменения, предпринимаемые в прикладном программном обеспечении для его адаптации, минимальны. Могут использоваться обширные части теста соответствия CAN (ISO 16845). Кроме того, предлагаемый в изобретении способ передачи данных может комбинироваться с дополнениями, предусмотренными протоколом TTCAN (ISO 11898-4).

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

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

Соответственно этому в системах, в которых передача данных осуществляется согласно стандарту на протокол CAN, прикладное программное обеспечение и поля данных сообщений CAN обмениваются через запоминающие устройства для сообщений и буферные запоминающие устройства, как правило - многочисленные, пакетами данных размером не более восьми байт. Если прикладное программное обеспечение остается неизменным, то и для запоминающих устройств для сообщений и буферных запоминающих устройств можно сохранить заданный размер, составляющий, например, восемь байт, чтобы излишне не увеличивать размер, или площадь кристалла, предлагаемого в изобретении коммуникационного контроллера. Если же размер поля данных соответствующего изобретению сообщения (например, 16 байт) отличается от размера используемого буферного запоминающего устройства (например, восемь байт), то протокольный контроллер коммуникационного контроллера необходимо адаптировать соответственно разнице в размерах между полем данных и буферным запоминающим устройством.

Поэтому еще один вариант осуществления предлагаемого в изобретении способа, приведенный на примере сообщения в основном формате с полем данных размером 16 байт передачи данных и иллюстрируемый схемой на фиг. 6, предусматривает, что в отношении последовательной передачи битов по шине в полном объеме реализуется функциональность предлагаемого способа, но в поле данных передается лишь восемь байт значимых полезных данных. Таким образом, хотя при наличии соответствующего условия переключения по шине передается, например, сообщение с полем данных размером 16 байт и относящейся к этому полю меткой, и это сообщение проверяется на предмет правильности передачи с помощью соответственно адаптированного полинома CRC, в прикладное программное обеспечение 640 через буферное запоминающее устройство 620 и, например, запоминающее устройство 630 для сообщений в предлагаемом в изобретении коммуникационном контроллере передается лишь восемь байт полезных данных. В случае отправки сообщения прикладным программным обеспечением 640 записывается в буферное запоминающее устройство 620, например, через другое или то же самое запоминающее устройство 630 для сообщений, восемь байт полезных данных, которые вносятся по заданному или задаваемому методу в поле данных подлежащего отправке сообщения, например поле данных размером 16 байт. Естественно, предлагаемый способ может быть ограничен и иным, нежели восемь байт, размером буферного запоминающего устройства, например, шестью или четырьмя байтами. Это прежде всего имеет смысл в случае, если прикладное программное обеспечение также предусматривает это ограничение. Выбор 16-байтового поля данных также следует понимать как приведенный лишь в качестве примера, так что поле данных может содержать, например, значения 24, 32 или 64 байт. Множество других возможностей следует, например, из таблицы на фиг. 2. Существует определенное соотношение между объемом (количеством) данных, передаваемых из сообщения прикладному программному обеспечению и, соответственно, выдаваемых прикладным программным обеспечением для записи в поле данных сообщения, и размером буферного запоминающего устройства 620.

В данном варианте осуществления изобретения протокольный контроллер коммуникационного контроллера, условно показанный на фиг. 6 двусторонней стрелкой 600, при преобразовании подлежащих передаче данных в последовательную форму помещает, например, упомянутые выше восемь байт полезных данных из буферного запоминающего устройства 620 в первые восемь последовательных разрядов поля данных, а дальнейшие разряды поля данных заполняет, как показано на фиг. 6 стрелкой 610, заданными, задаваемыми или же произвольно формируемыми заполняющими данными, например, определенной битовой комбинацией. При этом целесообразно использовать такую битовую последовательность, которая по правилам стандарта ISO 11898-1 на протокол CAN не ведет к вставке дополняющих битов (бит-стаффинг), так как в противном случае поле данных излишне увеличится. Так, например, для каждого неиспользованного байта поля данных в последнее можно вставлять битовую последовательность 0b00110011 или 0b1001100.

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

Принимающие абоненты шины читают сообщение согласно предлагаемому в изобретении способу, выполняют проверку данных, например проверку с помощью кода CRC, и подтверждают правильный прием путем отправки подтверждения. Протокольный контроллер в коммуникационном контроллере принимающих абонентов шины преобразует последовательно принимаемые биты сообщения и при этом извлекает из поля данных, например поля данных размером 16 байт, восемь байт полезных данных, которые записываются в буферное запоминающее устройство 620. Это также условно показано на фиг. 6 двусторонней стрелкой 600. Остальные заполняющие данные отбрасываются. Таким образом, прикладному программному обеспечению 640 передается через буферное запоминающее устройство 620 и, например, запоминающее устройство 630 для сообщений лишь восемь байт полезных данных. Само прикладное программное обеспечение 640 не устанавливает никакого отличия данной процедуры по сравнению с использованием соответствующего стандарту способа передачи данных.

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

Благодаря соответствующим регистрам состояния, в стандарте на протокол CAN гарантируется, например, что состояние ошибки (предупреждение об ошибке, пассивная отработка ошибок, отключение от шины), наступающее при соответствующем накоплении ошибок в передаче данных, может считываться, например, микроконтроллером или прикладным программным обеспечением. Кроме того, об успешных посылках и приемах сигнализируют флаги (TxOK, RxOK), и в готовности находится информация о последнем на данный момент событии на шине (код последней ошибки - LEC, сокр. от "Last Error Code"). Некоторые или все эти виды информации могут храниться в предлагаемых в изобретении коммуникационных контроллерах, а именно в предусмотренных для этого областях памяти, в нескольких экземплярах, вследствие чего, например, соответствующий микроконтроллер или выполняющееся в нем прикладное программное обеспечение может отдельно регистрировать и сохранять соответствующий вид информации в зависимости от исполняемого в данном случае способа передачи данных. Это позволяет устанавливать, встречается ли в случае способа передачи данных, модифицированного по сравнению со стандартом на протокол CAN, например способа с более длинным полем данных или с меньшей длительностью бита в областях сообщения, определенная картина ошибок чаще, чем при осуществлении способа передачи данных, соответствующего стандарту на протокол CAN.

Может быть введено дополнительное состояние ошибки, сигнализируемое битом состояния, который при накоплении ошибок в модифицированном режиме передачи переключает передачу данных обратно в режим постоянного осуществления способа передачи данных, соответствующего стандарту на протокол CAN. Данные TxOK, RxOK и LEC могут регистрироваться для различных способов передачи данных в отдельности. В другом случае для кода последней ошибки (LEC) дополнительно может сохраняться информация о режиме передачи, в котором возникла ошибка.

Кроме того, для принимаемых сообщений может быть целесообразным фиксировать то, согласно какому способу и с которой из возможных меток они были приняты, а для посылаемых сообщений - индивидуально задавать, согласно какому способу и с какой меткой они должны передаваться. В этом отношении определенные или все приемные запоминающие устройства для сообщений и/или приемные буферные запоминающие устройства могут быть дополнены определенным числом дополнительных битов (разрядов), соответствующих возможным меткам. Кроме того, в других предусмотренных для этого битах (разрядах) отдельно может сохраняться информация о том, в каком состоянии или при котором условии переключения соответствующее сообщение было принято. Аналогичным образом, определенные или все передающие запоминающие устройства для сообщений и/или передающие буферные запоминающие устройства могут быть снабжены дополнительными битами (разрядами), в которые вносится информация о том, что соответствующее сообщение должно быть отправлено согласно модифицированному способу передачи и/или с соответствующей меткой.

Наконец, может быть целесообразным выполнить предлагаемый в изобретении коммуникационный контроллер таким образом, чтобы путем соответствующей перестройки его конфигурации его можно было переключать между режимом совместимости с прикладным программным обеспечением, который предполагает ограничение объема данных, передаваемого между полем данных сообщения и прикладным программным обеспечением, например ограничение 8 байтами, и режимом оптимизации передачи данных, который предполагает использование полного размера поля данных при задействовании буферного запоминающего устройства, выполненного с соответственно большим размером. Хотя в этом случае соответствующее уменьшение размера или площади кристалла за счет применения соответственно меньших буферных запоминающих устройств и/или запоминающих устройств для сообщений и не достигается, коммуникационный контроллер сможет применяться с очень высокой степенью гибкости как в абонентах шины, в которых продолжает использоваться существующее прикладное программное обеспечение, так и в абонентах шины, для которых разработано новое, оптимизированное в отношении передачи данных программное обеспечение.

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

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

Группа изобретений относится к области передачи данных и может быть использована для последовательной передачи данных в шинной системе, включающей в себя, по меньшей мере, два устройства обработки данных, являющихся абонентами шины и обменивающихся по шине сообщениями, причем посылаемые сообщения имеют логическую структуру, соответствующую стандарту ISO 11898-1 на протокол CAN. Техническим результатом является увеличение объема и скорости передаваемых данных. Поле данных в сообщениях может содержать, в отличие от стандарта ISO 11898-1 на протокол CAN, более восьми байт, причем для установления размера поля данных значения кода длины данных интерпретируют, по меньшей мере частично, иначе по сравнению со стандартом ISO 11898-1 на протокол CAN. Для передачи данных между полем данных и прикладным программным обеспечением предусмотрено, по меньшей мере, одно буферное запоминающее устройство, и передаваемый объем данных по меньшей мере в случае, если размер поля данных отличается от размера используемого буферного запоминающего устройства, адаптируют соответственно разнице в размерах между полем данных и используемым буферным запоминающим устройством. 4 н. и 19 з.п. ф-лы, 9 ил.

1. Способ последовательной передачи данных в шинной системе, включающей в себя по меньшей мере два устройства обработки данных, являющихся абонентами шины и обменивающихся по шине сообщениями, причем:
- посылаемые сообщения имеют логическую структуру, соответствующую стандарту ISO 11898-1 на протокол CAN,
- указанная логическая структура включает в себя бит начала кадра, поле арбитража, поле управления, поле данных, поле циклического избыточного кода (CRC), поле подтверждения и последовательность конца кадра,
- поле управления включает в себя код длины данных, содержащий информацию о длине поля данных,
отличающийся тем, что поле данных в передаваемых сообщениях может содержать, в отличие от стандарта ISO 11898-1 на протокол CAN, более восьми байт, причем:
- для установления размера поля данных значения кода длины данных интерпретируют, по меньшей мере частично, иначе по сравнению со стандартом ISO 11898-1 на протокол CAN,
- для передачи данных между полем данных и прикладным программным обеспечением (640) предусмотрено по меньшей мере одно буферное запоминающее устройство (620), и передаваемый объем данных по меньшей мере в случае, если размер поля данных отличается от размера используемого буферного запоминающего устройства (620), адаптируют соответственно разнице в размерах между полем данных и используемым буферным запоминающим устройством (620).

2. Способ по п. 1, отличающийся тем, что если размер поля данных превышает размер используемого буферного запоминающего устройства, то из поля данных принятого по шине сообщения выбирают, по заданному или задаваемому методу выбора, соответствующий размеру буферного запоминающего устройства объем данных и передают его в буферное запоминающее устройство.

3. Способ по п. 1, отличающийся тем, что если размер поля данных превышает размер используемого буферного запоминающего устройства, то в поле данных посылаемого по шине сообщения вносят содержимое буферного запоминающего устройства, помещая это содержимое по меньшей мере в одну заданную или задаваемую область поля данных сообщения, а оставшуюся область или оставшиеся области поля данных заполняют по заданному или задаваемому методу.

4. Способ по п. 1, отличающийся тем, что при размере поля данных принятого по шине сообщения, составляющем более восьми байт, через по меньшей мере одно буферное запоминающее устройство прикладному программному обеспечению передают восемь заданных или задаваемых байт поля данных.

5. Способ по п. 1, отличающийся тем, что при размере поля данных посылаемого по шине сообщения, составляющем более восьми байт, оставшиеся биты поля данных заполняют заданными или задаваемыми значениями.

6. Способ по одному из пп. 3-5, отличающийся тем, что заполняемые области поля данных посылаемого по шине сообщения заполняют битами так, чтобы в эти области не нужно было вставлять дополняющие биты согласно правилам стандарта ISO 11898-1 на протокол CAN.

7. Способ по п. 1, отличающийся тем, что каждая из возможных комбинаций значений битов кода длины данных соотнесена с одним из допустимых размеров поля данных.

8. Способ по п. 1, отличающийся тем, что в зависимости от кода длины данных, интерпретируемого, по меньшей мере частично, иначе по сравнению со стандартом ISO 11898-1 на протокол CAN, адаптируют процесс приема сообщения к размеру поля данных.

9. Способ по п. 1, отличающийся тем, что поле CRC в сообщениях может иметь по меньшей мере два различных числа битов, причем по меньшей мере одно из действительных чисел битов в поле CRC отличается от числа битов, предусмотренного стандартом ISO 11898-1 на протокол CAN, и для задания содержимого такого поля CRC, которое имеет отличное от предусмотренного стандартом число битов, используют порождающий полином, отличающийся от используемого в случае стандарта ISO 11898-1 на протокол CAN.

10. Способ по п. 1, отличающийся тем, что длительность бита внутри сообщения может принимать по меньшей мере два различных значения, причем по меньшей мере для одной первой задаваемой области в пределах сообщения длительность бита больше или равна заданному минимальному значению, составляющему около микросекунды, а по меньшей мере в одной второй задаваемой области в пределах сообщения длительность бита имеет значение, уменьшенное по сравнению с первой областью.

11. Способ по п. 10, отличающийся тем, что по меньшей мере два различных значения длительности бита внутри сообщения реализуют в процессе работы путем использования по меньшей мере двух различных коэффициентов масштабирования для установки шинной единицы времени по отношению к наименьшей единице времени или к такту опорного генератора.

12. Способ по п. 10 или 11, отличающийся тем, что сообщения, в которых длительность бита внутри сообщения может принимать по меньшей мере два различных значения, распознают по метке, находящейся в поле управления.

13. Способ по п. 1, отличающийся тем, что предусмотрен по меньшей мере один дополнительный бит состояния, посредством которого прикладному программному обеспечению предоставляется информация, относящаяся к способу передачи данных, отличному от предусмотренного стандартом ISO 11898-1 на протокол CAN.

14. Способ по п. 13, отличающийся тем, что по меньшей мере один дополнительный бит состояния включает в себя бит состояния для уведомления об успешной посылке, и/или бит состояния для уведомления об успешном приеме. и/или один или несколько битов состояния для уведомления о виде последней возникшей ошибки.

15. Способ по п. 13 или 14, отличающийся тем, что в зависимости от частоты появления ошибок при использовании способа передачи данных, отличного от предусмотренного стандартом ISO 11898-1 на протокол CAN, переключаются обратно на способ передачи данных по стандарту ISO 11898-1 на протокол CAN, а для уведомления о выполненном обратном переключении предусмотрен по меньшей мере один бит состояния.

16. Способ по п. 1, отличающийся тем, что в по меньшей мере одном буферном запоминающем устройстве и/или по меньшей мере одном связанном с ним запоминающем устройстве для сообщений предусмотрен по меньшей мере один дополнительный бит сообщения, обозначающий способ передачи данных, который использован или подлежит использованию для соответствующего сообщения.

17. Устройство для последовательной передачи данных в шинной системе, включающей в себя по меньшей мере два устройства обработки данных, являющихся абонентами шины и обменивающихся по шине сообщениями, причем:
- посылаемые сообщения имеют логическую структуру, соответствующую стандарту ISO 11898-1 на протокол CAN,
- указанная логическая структура включает в себя бит начала кадра, поле арбитража, поле управления, поле данных, поле циклического избыточного кода (CRC), поле подтверждения и последовательность конца кадра,
- поле управления включает в себя код длины данных, содержащий информацию о длине поля данных,
отличающееся тем, что поле данных в передаваемых сообщениях может содержать, в отличие от стандарта ISO 11898-1 на протокол CAN, более восьми байт, причем:
- для установления размера поля данных значения кода длины данных интерпретируются, по меньшей мере частично, иначе по сравнению со стандартом ISO 11898-1 на протокол CAN,
- для передачи данных между полем данных и прикладным программным обеспечением предусмотрено по меньшей мере одно буферное запоминающее устройство, и передаваемый объем данных по меньшей мере в случае, если размер поля данных отличается от размера используемого буферного запоминающего устройства, адаптируется соответственно разнице в размерах между полем данных и используемым буферным запоминающим устройством.

18. Устройство по п. 17, отличающееся тем, что оно оборудовано средствами, подходящими для осуществления по меньшей мере одного из способов передачи данных по пп. 2-15.

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

20. Устройство по п. 18, отличающееся тем, что подходящие средства включают в себя по меньшей мере один дополнительный или расширенный регистр состояния, содержимое которого характеризует вид, и/или успех, и/или результат применения используемого или использовавшегося в соответствующем случае способа передачи данных.

21. Устройство по одному из пп. 18-20, отличающееся тем, что подходящие средства включают в себя по меньшей мере одно дополнительное или расширенное запоминающее устройство для сообщений и/или буферное запоминающее устройство, в котором по меньшей мере один дополнительный бит сообщения обозначает способ передачи данных, использованный или подлежащий использованию для соответствующего сообщения.

22. Применение способа по одному из пп. 1-16 при нормальной эксплуатации транспортного средства или промышленной установки для передачи данных между по меньшей мере двумя блоками управления транспортного средства или промышленной установки, соединенными подходящей шиной данных.

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