CAN总线外文文献及译稿.docx

CAN总线外文文献及译稿.docx

《CAN总线外文文献及译稿.docx》由会员分享，可在线阅读，更多相关《CAN总线外文文献及译稿.docx（11页珍藏版）》请在冰豆网上搜索。

CAN总线外文文献及译稿

CANBusProtocol

Introduction

ControllerAreaNetwork（CAN）wasinitiallycreatedbyGermanautomotivesystemsupplierRobertBoschinthemid-1980sforautomotiveapplicationsasamethodforenablingrobustserialcommunication.Thegoalwastomakeautomobilesmorereliable，safeandfuel-efficientwhiledecreasingwiringharnessweightandcomplexity。

Sinceitsinception，theCANprotocolhasgainedwidespreadpopularityinindustrialautomationandautomotive/truckapplications.Othermarketswherenetworkedsolutionscanbringattractivebenefitslikemedicalequipment,testequipmentandmobilemachinesarealsostartingtoutilizethebenefitsofCAN.ThegoalofthisapplicationnoteistoexplainsomeofthebasicsofCANandshowthebenefitsofchoosingCANforembeddedsystemsnetworkedapplications.

CANOverview

Mostnetworkapplicationsfollowalayeredapproachtosystemimplementation.Thissystemeticapproachenablessinteroperabilitybetweenproductsfromdifferentmanufacturers.AstandardwascreatedbytheInternationalStandardsOrganization（ISO）asatemplatetofollowforthislayeredapproach.ItiscalledtheISOOpenSystemsInterconnection（OSI）NetworkLayeringReferenceModel.TheCANprotocolitselfimplementsmostofthelowertwolayersofthisreferencemodel。

ThecommunicationmediumportionofthemodelwaspurposelyleftoutoftheBoschCANspecificationtoenablesystemdesignerstoadaptandoptimizethecommunicationprotocolonmultiplemediaformaximumflexibility（twistedpair，singlewire，opticallyisolated，RF，IR，etc。

）.Withthisflexibility,however,comesthepossibilityofinteroperabilityconcerns。

Toeasesomeoftheseconcerns，theInternationalStandardsOrganizationandSocietyofAutomotiveEngineers（SAE）havedefinedsomeprotocolsbasedonCANthatincludetheMediaDependentsInterfacedefinitionsuchthatallofthelowertwolayersarespecified。

ISO11898isastandardforhigh—speedapplications,ISO11519isastandardforlow-speedapplications，andJ1939（fromSAE）istargetedfortruckandbusapplications。

Allthreeoftheseprotocolsspecifya5Vdifferentialelectricalbusasthephysicalinterface。

TherestofthelayersoftheISO/OSIprotocolstackarelefttobeimplementedbythesystemsoftwaredeveloper。

HigherLayerProtocols（HLPs）aregenerallyusedtoimplementtheupperfivelayersoftheOSIReferenceModel。

HLPsareusedto：

1）Standardizestartupproceduresincludingbitratesused，

2）Distributeaddressesamongparticipatingnodesortypesofmessages，

3）Determinethestructureofthemessages，and

4）Providesystem—levelerrorhandlingroutines。

ThisisbynomeansafulllistofthefunctionsHLPsperform；howeveritdoesdescribesomeoftheirbasicfunctionality。

CANProtocolBasics

CarrierSenseMultipleAccesswithCollisionDetection（CSMA/CD）

TheCANcommunicationprotocolisaCSMA/CDprotocol。

TheCSMAstandsforCarrierSenseMultipleAccess。

Whatthismeansisthateverynodeonthenetworkmustmonitorthebusforaperiodofnoactivitybeforetryingtosendamessageonthebus（CarrierSense）。

Also，oncethisperiodofnoactivityoccurs，everynodeonthebushasanequalopportunitytotransmitamessage（MultipleAccess）。

TheCDstandsforCollisionDetection。

Iftwonodesonthenetworkstarttransmittingatthesametime,thenodeswilldetectthe‘collision'andtaketheappropriateaction。

InCANprotocol，anondestructivebitwisearbitrationmethodisutilized.Thismeansthatmessagesremainintactafterarbitrationiscompletedevenifcollisionsaredetected。

Allofthisarbitrationtakesplacewithoutcorruptionordelayofthehigherprioritymessage。

Thereareacoupleofthingsthatarerequiredtosupportnon—destructivebitwisearbitration.First，logicstatesneedtobedefinedasdominantorrecessive。

Second，thetransmittingnodemustmonitorthestateofthebustoseeifthelogicstateitistryingtosendactuallyappearsonthebus.CANdefinealogicbit0asadominantbitandalogicbit1asarecessivebit.

Adominantbitstatewillalwayswinarbitrationoverarecessivebitstate，thereforethelowerthevalueintheMessageIdentifier（thefieldusedinthemessagearbitrationprocess），thehigherthepriorityofthemessage。

Asanexample，supposetwonodesaretryingtotransmitamessageatthesametime。

Eachnodewillmonitorthebustomakesurethebitthatitistryingtosendactuallyappearsonthebus。

Thelowerprioritymessagewillatsomepointtrytosendarecessivebitandthemonitoredstateonthebuswillbeadominant.Atthatpointthisnodelosesarbitrationandimmediatelystopstransmitting。

Thehigherprioritymessagewillcontinueuntilcompletionandthenodethatlostarbitrationwillwaitforthenextperiodofnoactivityonthebusandtrytotransmititsmessageagain。

Message—BasedCommunication

CANprotocolisamessage-basedprotocol，notanaddressbasedprotocol。

Thismeansthatmessagesarenottransmittedfromonenodetoanothernodebasedonaddresses。

EmbeddedintheCANmessageitselfisthepriorityandthecontentsofthedatabeingtransmitted。

Allnodesinthesystemreceiveeverymessagetransmittedonthebus（andwillacknowledgeifthemessagewasproperlyreceived）。

Itisuptoeachnodeinthesystemtodecidewhetherthemessagereceivedshouldbeimmediatelydiscardedorkepttobeprocessed。

Asinglemessagecanbedestinedforoneparticularnodetoreceive，ormanynodesbasedonthewaythenetworkandsystemaredesigned.Forexample，anautomotiveairbagsensorcanbeconnectedviaCANtoasafetysystemrouternodeonly。

Thisrouternodetakesinothersafetysysteminformationandroutesittoallothernodesonthesafetysystemnetwork。

Thenalltheothernodesonthesafetysystemnetworkcanreceivethelatestairbagsensorinformationfromtherouteratthesametime,acknowledgeifthemessagewasreceivedproperly，anddecidewhethertoutilizethisinformationordiscardit。

AnotherusefulfeaturebuiltintotheCANprotocolistheabilityforanodetorequestinformationfromothernodes。

ThisiscalledaRemoteTransmitRequest（RTR）。

Thisisdifferentfromtheexampleinthepreviousparagraphbecauseinsteadofwaitingforinformationtobesentbyaparticularnode，thisnodespecificallyrequestsdatatobesenttoit.

Oneadditionalbenefitofthismessage—basedprotocolisthatadditionalnodescanbeaddedtothesystemwithoutthenecessitytoreprogramallothernodestorecognizethisaddition.Thisnewnodewillstartreceivingmessagesfromthenetworkand，basedonthemessageID,decidewhethertoprocessordiscardthereceivedinformation.

CANMessageFrameDescription

CANprotocoldefinefourdifferenttypesofmessages（orFrames）.ThefirstandmostcommontypeofframeisaDataFrame。

Thisisusedwhenanodetransmitsinformationtoanyorallothernodesinthesystem.SecondisaRemoteFrame,whichisbasicallyaDataFramewiththeRTRbitsettosignifyitisaRemoteTransmitRequest。

Theothertwoframetypesareforhandlingerrors.OneiscalledanErrorFrameandoneiscalledanOverloadFrame。

ErrorFramesaregeneratedbynodesthatdetectanyoneofthemanyprotocolerrorsdefinedbyCAN。

Overloaderrorsaregeneratedbynodesthatrequiremoretimetoprocessmessagesalreadyreceived。

DataFramesconsistoffieldsthatprovideadditionalinformationaboutthemessageasdefinedbytheCANspecification。

EmbeddedintheDataFramesareArbitrationFields，ControlFields，DataFields,CRCFields,a2—bitAcknowledgeFieldandanEndofFrame.

TheArbitrationFieldisusedtoprioritizemessagesonthebus.SincetheCANprotocoldefinesalogical0asthedominantstate，thelowerthenumberinthearbitrationfield，thehigherprioritythemessagehasonthebus。

Thearbitrationfieldconsistsof12—bits（11identifierbitsandoneRTRbit）or32-bits（29identifierbits，1-bittodefinethemessageasanextendeddataframe,anSRRbitwhichisunused,andanRTRbit），dependingonwhetherStandardFramesorExtendedFramesarebeingutilized。

ThecurrentversionoftheCANspecification,version2。

0B，defines29-bitidentifiersandcallsthemExtendedFrames。

PreviousversionsoftheCANspecificationdefined11—bitidentifierswhicharecalledStandardFrames。

Asdescribedintheprecedingsection，theRemoteTransmitRequest（RTR）isusedbyanodewhenitrequiresinformationtobesenttoitfromanothernode.ToaccomplishanRTR,aRemoteFrameissentwiththeidentifieroftherequiredDataFrame.TheRTRbitintheArbitrationFieldisutilizedtodifferentiatebetweenaRemoteFrameandaDataFrame.IftheRTRbitisrecessive,thenthemessageisaRemoteFrame.IftheRTRbitisdominant，themessageisaDataFrame.

TheControlFieldconsistsofsixbits。

TheMSBistheIDEbit（signifiesExtendedFrame）whichshouldbedominantforStandardDataFrames。

ThisbitdeterminesifthemessageisaStandardorExtendedFrame。

InExtendedFrames，thisbitisRB1anditisreserved.ThenextbitisRB0anditisalsoreserved.ThefourLSBsaretheDataLengthCode（DLC）bits。

TheDataLengthCodebitsdeterminehowmanydatabytesareincludedinthemessage.ItshouldbenotedthataRemoteFramehasnodatafield，regardlessofthevalueoftheDLCbits.TheDataFieldconsistsofthenumberofdatabytesdescribedintheDataLengthCodeoftheControlField。

TheCRCFieldconsistsofa15-bitCRCfieldandaCRCdelimiter，andisusedbyreceivingnodestodetermineiftransmissionerrorshaveoccurred。

TheAcknowledgeFieldisutilizedtoindicateifthemessagewasreceivedcorrectly。

Anynodethathascorrectlyreceivedthemessage,regardlessofwhetherthenodeprocessesordiscardsthedata，putsadomi