CAN-based higher layer protocols
Adding Identity Protection to EAP-TLS Smartcards
Adding Identity Protection to EAP-TLS SmartcardsMohamad BadraLIMOS Laboratory UMR 6158, CNRS France badra@isima.frPascal UrienÉcole Nationale Supérieure des Télécommunications, ENSTParis, Franceurien@enst.frAbstract—Wireless and IP networks requires extensible, fast and flexible authentication and key-exchange protocols, addressing wireless environment constraints, such as scarce radio resources and limited computational power on the client. Many mobile and wireless communities have agreed to adopt security protocols originally designed for wired networks, as authentication methods for their entities and for IP-Wireless inter-working. Nowadays, TLS is the most frequently deployed protocol in security exchanges and the de facto standard for the authentication in wireless networks; especially WLAN and 3GPP. However, missing from the protocol is a way to provide privacy and identity protection, which are increasingly required in IP architectures and are essential in wireless infrastructures. In this paper, we extend TLS with a new mechanism to guaranty identity protection, to enhance user's privacy and to make exchanges untraceable to eavesdroppers. We analyze and discuss results obtained with an original experimental platform, dealing with EAP-TLS smartcards that increase the level of trust.Key words—Transport Layer Security (TLS), Public Key Infrastructures, Wireless LAN, Smartcards, and identity protection.I.I NTRODUCTIONOver the last few years, many security protocols have been proposed and normalized in order to protect data exchanged between two ends over unsecured networks such as Internet. Research has been focused on the development of security protocols at each layer of the ISO protocol stacks; especially at the Application (Secure Shell [7]), Transport (Transport Layer Security [1]) and the Networks (IP Security [8]). Even though these protocols have answered some security requirements, they remain efficient in a specific context related to the assumptions and the restrictive requirements, which have been emitted at the time of their design. Moreover, these protocols suffer from the lack of interoperability between their different versions and at the same time, there is no one protocol satisfying all security needs.The common security services provided by these protocols are the mutual authentication, the data confidentiality and integrity, and the entity protection against some attacks such as replay or man-in-the-middle. Mutual authentication is usually established using certificates or shared keys. In the certificate case, entities share a common certification authority (CA) or a trusted third party and use certificates and asymmetric encryption/decryption to mutually authenticate [14]. In the shared key case, each entity will often generate a random value, in which it will be symmetrically encrypted or signed by the other entity using the shared secret, to prove its shared secret ownership. In both case, the sender and the receiver will next share a session key to protect their exchanges and therefore to provide data confidentiality and integrity.During the authentication and security association phase, almost all security protocols exchange identity related data in clear text and without any encryption. Therefore, security parameters flowing in the network could potentially be logged, archived, and searched. Basically, certificates are issued by trusted third party, linking the identity of the certificate owner to his public key whereas the shared secret is managed through its identifier. Certificate or shared key identifiers are usually sent in clear text and consequently, entities cannot protect their identities from eavesdropping. Thus, an intruder can learn who is reaching the network, when, and from where, and hence from correlating client identity to connection location.Privacy and identity protection are increasingly required in wired and wireless networks like WLAN and 4G. On the one hand, research is being carried out to adapt security protocols originally specified for wired networks to be deployed in wireless networks. On the other hand, security developers did not consider use within wireless networks as a criterion when they initially designed security protocols and consequently, these protocols insufficiently meet wireless networks requirements and needs; particularly identity protection.In this paper, we focus on TLS, which provides connection security with peer entity authentication, data confidentiality and integrity, key generation and distribution, and security parameters negotiation. Its native integration in browsers and Web servers makes TLS the most frequently deployed protocol. It is the de facto standard for the authentication in wireless networks; especially WLAN [16], 3GPP [15] and WiMax [17]. However, missing from the protocol is a way to provide identity protection during the session establishment.To avoid sending identity information in clear text during the TLS session, we extend TLS with an enhanced mechanism completely backwards compatible with the existing TLS implementation. Because keys caching is a critical security issue, we use EAP-TLS smartcards [13], which securely store all cryptographic credentials, and compute the TLS protocol in a highly trusted environment.This paper is constructed as follows. Section 2 describes TLS and its integration to different contexts, such as wireless networks. Next in section 3, we present our solution to add identity protection to TLS. In section 4, we analyze our protocol and we discuss results obtained with an original experimental platform, dealing with EAP-TLS smartcards. Finally, we give some concluding remarks.II.TLS P ROTOCOLTLS is a transaction security standard that provides connection security with the following basic properties: mutual authentication, integrity-protected parameter negotiation and key exchange between two entities. This protocol consists of several sub-protocols, specially the Record and the Handshake protocol. The Record protocol provides basic connection security for various higher layer protocols through encapsulation. The Handshake protocol is used to allow peers to agree upon security parameters for the Record layer, authenticate themselves, instantiate negotiated security parameters, and report error conditions to each other. This protocol is used to negotiate the security attributes of a session. Once a transport connection is authenticated and a secret shared key is established with the TLS Handshake protocol, data exchanged by application protocols can be protected with cryptographic methods by the Record layer using the keyingmaterial derived from the shared secret.Figure 1. The TLS Handshake phaseWe illustrate TLS Handshake in three phases (Fig. 1): the hello phase, the client authentication phase, and the finished and server authentication phase. During the hello phase, the client and the server negotiate the cryptographic option (asymmetric and symmetric encryption algorithm, hash function, key exchange method, etc.) and exchange two random values that will be used by the key computation process. The second phase consists of exchanging certificates and of proving the identity and the validity of these certificates. During this phase, the client generates a secret called pre_master_secret, which is sent encrypted using the server public key and applies its signature on handshake massages to prove its certificate ownership. During the third phase, the client and the server exchange the change cipher spec and the finished messages. The “change cipher spec” message is sent by both the client and the server to notify the receiving party that subsequent records will be protected under the newly negotiated cipher spec and keys. The finished message is immediately sent after the change cipher spec message to verify that the key exchange and authentication processes were successful. The finished message is the first message that is protected using the negotiated algorithms by the Record sub-protocol. When the client receives the server finished message, it will implicitly authenticate the server. In fact, the finished message is signed and encrypted using keys derived from the master secret, which is computed using the pre_master_secret. This latter is sent encrypted using the server public key, in which only the server is able to retrieve it in clear text.A.TLS deployment in different contextsTLS is being integrated in many infrastructures and environments due to its simplicity, extensibility and its security robustness. Originally, TLS has been designed to run over a reliable transport such as TCP. Due to the increasingly number of applications that are designed to operate over unreliable link such as UDP, Datagram TLS [9] has been developed and is actually under normalization by IETF. DTLS is designed to be as similar to TLS as possible; both to minimize new security invention and to maximize the amount of code and infrastructure reuse [9].Actually, TLS is the most widely deployed protocol for authenticating WLAN entities. WLAN and 802.11 networks use EAP (Extensible Authentication Protocol) [18], which is a powerful umbrella that shelters multiple authentication methods and use PPP (Point to Point Protocol) [4] for transporting multi-protocol datagrams. However, WLAN and 802.11 do not indicate how EAP should be implemented within WLAN authentication frameworks. Consequently, many security protocols over EAP has been specified by IETF, in which majority of them are based on TLS; especially EAP-TLS [2], EAP-TTLS [10] and PEAP [11].On the other hand, mobile communications are usually authenticated using mechanism based on the use of pre-shared keys (PSK). Nowadays, mobile and telecommunication communities are extremely interested in the use of shared secrets within TLS; particularly 3GPP2, which has agreed to adopt the TLS shared key concept as one of the authentication methods for 3GPP2-WLAN inter-working. Consequently, we introduced the TLS-PSK standard protocol [3] and TLS Express [12] that support authentication based on PSK. This is because the use of PSK instead of certificate based-authentication could be an alternative when TLS is used in performance-constrained environments where limited CPU and bandwidth are the bottleneck.However, the use of TLS in wireless LAN and 4G must not break the client’s privacy, which is an elementary service for these architectures. Unfortunately, actual TLS specifications exchange certificate in clear text and then do not provide the ability for a client to negotiate identity protection without being renegotiate the security parameters in an existing connection. Consequently, an eavesdropper is able to identify the communicating parties, since secret identifiers or certificates are sent in clear text. Thus, we propose to add identity protection to TLS, emphasizing interoperability, re-use and backward-compatibility with the existing TLS implementation.III.R ELATED W ORKSThis section discusses other works related to identity protection integration to TLS. Current TLS specifications provide anonymous key exchange, allowing two entities to perform data encryption. In this case, the entities will not exchange their certificates and therefore, authentication or indication of the entity's identity will not be possible. Consequently, an intruder can easily perform a man-in-the-middle attack, intercepting the session exchanges and sends its public key instead of the server or the client ones. In fact, the attacker sniffs packets conveying entity public key, and then replaces it with its public key before sending the modified packets to the receiver. According to TLS, the client generates a pre_master_secret, which will be encrypted with the unauthenticated public key of the intruder. This latter will retrieve the pre_master_secret in clear text since it has the corresponding private key. Next, the intruder encrypts thepre_master_secret using the server public key.Figure 2. Man-in-the-middle attackRescorla [5] proposed to resolve such attack by initiating anew TLS session once the anonymous TLS session has beenestablished. The main idea of that approach is to re-handshakea TLS session with mutual authentication based on the use ofcertificates. All the messages of the second session, includingcertificates, are then encrypted using keys derived from thefirst session. Even though this solution provides anonymousexchanges, it increases latency and reduce throughput. In fact,asymmetric encryption/decryption operations are repeatedduring the re-handshake and that the re-handshake messagesare symmetrically encrypted, which significantly increase theprocessing time on both client and server. Moreover, thenumber of re-handshake messages requires several round trips.Note that anonymous key exchange methods require thegeneration of ephemeral keys. Such a generation is tooexpensive to do; especially when entities repeat it for eachsession. Note also that this solution is similar to the case whenthe client and the server renegotiate their security parameters inan existing connection.The third solution is proposed at the IETF-TLS WorkingGroup meeting in Pittsburgh and discussed on the TLS mailinglist [19]. It consists of changing the order of the TLS messagesin a way the client sends the “change cipher spec” messagebefore its “certificate” message. The “change cipher spec” issent by the client to notify the receiving party that subsequentmessages will be protected under the derived keys. That waythe certificate is sent protected. However, TLS WG rejectedthis solution because it requires the definition of new versionfor TLS and it clutters up the TLS state-machine.IV.I DENTITY P ROTECTION WITH TLSWe propose to elaborate an enhanced way to avoid sendingcertificates or secret identifiers in clear text during the TLShandshake phase. It is based on TLS extensions standard [20],which describes ways to add functionality to TLS. “TLSExtensions” provides generic extension mechanisms for theTLS handshake client and server hellos and specifies someextensions using these mechanisms. It specifies extensionsusing the following generic mechanism represented in theeXternal Data Representation (XDR) format:struct {ExtensionType extension_type;opaque extension_data <0 .. 2^16-1>;} Extension;The extension_data field contains information specific tothe particular extension type (identified in the extension_typefield).A.The “ identity_protection” extensionThe extension defined below is sent by the client to indicateto the server that the client certificate will be sent encryptedusing a symmetric algorithm negotiated through that extension.The symmetric algorithm uses a key derived from the randomvalues and from the master_secret.struct {SymmetricAlgorithm symmetric_alg_list<0..2^16-1>;} IdentityProtection;enum { rc4(0), (255) } SymmetricAlgorithm;The defined extension is of type “identity_protection”. The“extension_data” field of this extension shall contain thesymmetric algorithms supported by the client. In other words,when the client decides to negotiate such extension, itinitializes it with the supported symmetric encryptionalgorithms in order of its preference (favorite choice first).B.The “ identity_protection” handshakeBased on the TLS Extensions, a client and a server can inan ordinary TLS handshake, negotiate the future use of identityprotection extension. If the client does attempt to initiate a TLSconnection using identity protection extension with a serverthat does not support it, it will be automatically alerted. Forservers aware of identity protection extension but not wishingto use it, it will gracefully revert to an ordinary TLS handshakeor stop the negotiation.The negotiation starts usually with the client determiningwhether the server is capable of and willing to use identityprotection extension or not. The client includes the identityprotection extension in its extended client hello. This extensionconveys a set of symmetric encryption algorithms supported bythe client, in which RC4 is a mandatory algorithm and must besupported by entities wishing to use identity protectionextension.Upon receiving the extended client hello message, the server checks if it supports such an extension type. If not, then it can abort the handshake with an “unsupported extension” alert. Afterwards, the server verifies if there is at least one acceptable symmetric algorithm. If then the server will reply with the same extension type conveying the selected symmetric algorithm. If not, then the server can either send the “unsupported algorithm” alert and aborts the session, or falls back on an ordinary TLS handshake.encrypted message using symmetric algorithmwith key derived from the master_secret{M}EK M is encrypted using the key EKFigure 3. TLS Handshake using the identity protection extensionOnce the hello phase of the TLS session has been completed, the client generates the pre_master_secret and encrypts it using the server public key. Afterwards, the client computes the master_secret and derives an encryption key (of 16-bytes in the case of RC4) by applying the PRF (Pseudo Random Function) [1] on the computed master_secret and on the concatenation of both the server and the client random values, as defined in (1). The client will then symmetrically encrypt its certificate using the selected symmetric algorithm and the generated key. The result is then transmitted to the server using the “certificate” message.encryption_key =PRF(master_secret, “encryption_key”,ServerHello.random + ClientHello.random) (1)Upon receiving the “client key exchange” message, the server decrypts it using its private key to retrieve the pre_master_secret. Next, the server computes the master_secret, and then it derives the encryption key in the same way as defined in (1). Afterwards, the server decrypts the “certificate” message and verifies the validity of the client certificate. Next, the client and the server continue their session as it is obviously described in section II.V.D ISCUSSION AND R ESULTSThe identity protection extension design is completely backwards compatible with the existing TLS implementation since it does not require any changes to the TLS machine-state. In fact, TLS clients and servers can negotiate the identity protection extension using extended client and server hello messages [20]. Thus, TLS clients that support the extension can communicate with TLS servers that do not, and vice versa. However, both client and server must recover gracefully when configurations change; falling back on the ordinary TLS handshake protocol or stopping the negotiation.TLS defines a set of key exchange methods based on RSA and DH (Diffie-Hellman) algorithms [1]. When using a static DH based key exchange method (DH_DSS or DH_RSA), the identity protection extension must not be used. In this case, the client certificate conveys the client DH parameters that will allow the client and the server to agree upon the same pre_master_secret. This latter will be used to compute the same symmetric encryption key. Consequently, if the client certificate is encrypted, the server will not be able to recover the client DH public key. It should be noted that this is not a major problem, since client certificates containing DH public keys are extremely rare used.A.Experimental platform.As a proof of concept, we implement and deploy our extension in a Wi-Fi infrastructure, whose security architecture is built according to the well-known IEEE 802.1x standard [25]. In a typical use case, a network user (called the supplicant) is authenticated by a RADIUS [26] server. EAP [18] precisely introduces and describes authentication messages transported either by wireless LAN frames, or via RADIUS packets. EAP acts as a flexible umbrella that shuttles multiple authentication scenari, called methods. As an illustration, the EAP-TLS [2] method is a quite transparent encapsulation of the TLS protocol, which introduces three main services:•the mandatory use of mutual authentication between the supplicant and the authentication server.Consequently each client is equipped with a RSAprivate key and an X509 certificate acting as itselectronic identity,•TLS messages delimitation in EAP packets,•TLS messages segmentation and reassembly rules.This is required because the size of some TLSmessages sent in a single round may exceed themaximum of the Ethernet of Wi-Fi frame size.Therefore, EAP-TLS introduces a segmentationprocess that splits TLS messages in smaller blocks,acknowledged by the recipient.As we previously mentioned it, identity protection is a critical privacy issue in WLAN environment. Although it is widely use in today Wi-Fi networks, EAP-TLS does not support identity protection features, and therefore a malicious hacker can initiate an authentication session, and remotely collect users’ identities. This attack is illustrated by figure 4, a set of four EAP unprotected requests (1, 3, 5, and 7) is sufficient to collect a clear form of the client’s Certificate message.B. EAP-TLS smartcardsSmartcards [24] are tamper resistant devices that include CPU, RAM and ROM resources and non-volatile memories (E 2PROM or FLASH). Most of them run a Java Virtual Machine and securely execute applications written for Javacards ([22], [23]), thanks to a subset of the well-known java programming language. EAP-TLS smartcards implement EAP clients or servers entities, and have been more precisely introduced in [13] and [27]. They fully and autonomously process EAP messages; EAP client (left part of figure 4) processes EAP requests and returns EAP responses; EAP server (right part of figure 4) receives EAP responses and produces EAP requests.On a Windows platform, a dedicated software component called “EAP provider” acts as a bridge (see figure 4) that transparently conveys EAP messages between WLAN interface and EAP smartcard.We have designed a specific RADIUS server which forwards EAP contents to EAP servers and analyses, checks and builds RADIUS packets (see [21] for more details). Each smartcard holds a unique certificate and autonomously performs a TLS authentication session. Although smartcards performances are modest (we observe a computing time of about 5 seconds with commercial devices), this architecture is scalable because hundreds of devices may be plugged to the RADIUS server via USB hubs.The two main security benefits of EAP-TLS smartcards are the following:• all RSA calculations are securely performed in a trusted computing platform,•all certificates are stored, parsed and checked in a secure environment.As an illustration, an EAP client module will abort an authentication session if it detects a wrong server certificate. C. Identity protection benefitsWhen EAP-TLS client supports the identity protection, we get the insurance that the client’s certificate will never leave the smartcard in a clear form. Its bearer may use an electronic identity without knowing its content.With a couple of smartcards, we obtain a new privacy property; the EAP server authenticates a remote client without disclosing its identity. However, it is still possible to recover this identity, from a previous record of authentication session, by executing the following operations: • pre-master-secret decryption, with the RSA private key of the EAP-Server, • calculation of the encryption key, •decryption of the client’s certificate.D. PerformancesWe introduced in [28] a method for performance analysis of EAP smartcards. The computing time is split in three categories.Access-Request -153BEAP-TLS.request (Start) -6BAccess-Challenge –Access-Request -226B Access-Challenge - 1388BAccess-Request -Access-Challenge - 234BAccess-Request - 1118BEAP-TLS.request (ServerHello frag#1) - 1296B EAP-TLS.request (ServerHello frag#2) - 150BEAP-TLS.response (ClientCertificate) - 946B NASEAP-TLS.request (Start)EAP-TLS.request (ServerHello frag#1) EAP-TLS.request (ServerHello frag#2) EAP-Identity.requestEAP-Identity.response EAP-TLSCLIENTEAP-TLS.response (ClientHello) - 60BEAP-TLS.response (ACK)EAP-TLS.response (ClientCertificate)5WLAN FramesRADIUS EAP ProviderSUPPLICANT...14EAP-TLS.request (ServerFinished) -53BEAP-TLS.response (ACK)EAP-TLS.request (ServerFinished)EAP-Success - 4BGET-MSK-KeyT Computing = T Transfer + T Crypto + T Other (2) where:•T Transfer is the time spent in Input/Output operations,e.g. the amount of time needed to transfer databetween host and smartcard non-volatile memory. Itis the sum of various parameters such as smartcardreader crossing, operating system delays andmemories accesses. The best observed value is about50 Kbit/s•T Crypto represents the time consumed by cryptographic operations (RSA, MD5, SHA1, etc.),which are securely handled by the smartcard OS andinvoked by the (javacard) APIs functions.•T Other indicates the time required by all other software operations, e.g. certificates parsing orprocessing of EAP-TLS or TLS protocols.Because EAP server and EAP client operations are very similar (sign, verify, encrypt, decrypt, key calculation, etc.), we notice closed performances for these dual devices:T EAP-Server ~T EAP-Client (3) As an illustration, we obtain the following repartition for EAP-TLS server (see Table 1). The time consumes by EAP module is around 5.3s. Identity protection adds an extra cost of about 1.0s, which is induced by two additional cryptographic operations: the calculation of a 128 bits encryption key using the PRF function, and the encryption/decryption of the supplicant certificate (about 600 bytes) by an RC4 algorithm.TABLE I. EAP-TLS R EPARTITION OF C OMPUTING T IMES Operation T Transfer T Crypto T OtherTime (%) 0.4s (8%) 1.9s (35%) 3.0s (57%)VI.C ONCLUSION“Privacy is the right to informational self-determination, i.e., individuals must be able to determine for themselves when, how, to what extent and for what purpose information about them is communicated to others” [6]. Actually, developers of authentication standards based on TLS are extremely interested in the privacy and identity protection. In particular, the IETF-EAP and IEEE 802.11 wireless LAN working groups recommend authentication methods providing identity hiding.In this paper, we extended the famous TLS protocol with a new mechanism to protect user's privacy and to make exchanges untraceable to eavesdroppers. Based on our experimental results, we demonstrated that although the smartcards are restricted by their memory size and CPU capacity, the extra time required by our extension in comparison to a traditional TLS session does not exceed 1 second. However, this extra time can be improved by incorporating digest functions and symmetric algorithms (e.g. RC4) in the smartcards cryptographic co-processor. Consequently, related operations will have inconsiderable influence on the global performance of TLS.VII.R EFERENCES[1]T Dierks and C Allen, “The TLS Protocol Version 1.0”, RFC 2246,January 1999.[2] B Aboba and D Simon, “PPP EAP TLS Authentication Protocol”,RFC 2716, October 1999.[3]P Eronen, Editor, et. al., “Pre-Shared Key Ciphersuites for TransportLayer Security (TLS)”, RFC 4279, December 2005.[4]W Simpson, Editor, “The Point-to-Point Protocol (PPP)”, STD 51,RFC 1661, July 1994[5] E Rescorla, “SSL and TLS: Designing and Building Secure Systems”,Addison-Wesley, March 2001.[6]S Kent and L Millet, “Who goes there? Authentication through thelens of privacy”, The National Academies Press, Washington, D.C.,2003.[7] C Lonvick, “SSH Protocol Architecture”, IETF Internet Draft, March2005.[8] C Kaufman, “Internet Key Exchange (IKEv2) Protocol”, IETFInternet Draft (work in progress), August 2004.[9] E Rescorla and N Modadugu, “Datagram Transport Layer Security”,IETF Internet Draft, June 2004.[10]P Funk, et. al., “EAP Tunneled TLS Authentication Protocol (EAP-TTLS)”, IETF Internet draft (work in progress), August 2004.[11]S Josefsson, et. al., “Protected EAP Protocol (PEAP)”, IETF Internetdraft (work in progress), October 2005.[12]M Badra, et. al., “TLS Express”, IETF Internet Draft, February 2005.[13]P Urien, M Badra and M Dandjinou, “EAP-TLS Smartcards, fromDream to Reality”, Proc. IEEE Workshop Applications and Servicesin Wireless Networks (ASWN), IEEE Press, 2004, pp. 39-45.[14]R Housley, W Polk and D Solo, “Internet X509 PKI, Certificate andCRL Profile”, RFC 2459, January 1999.[15]Third-Generation Partnership Program (3GPP) TechnicalStandardization Groups-System and Architecture (TSG-SA) workinggroup 3 (Security) meeting, “3GPP2 Security—Report to 3GPP”, S3-040588, July 2004.[16]IEEE, IEEE Std. 802.11, Information TechnologyTelecommunications Information Exchange between Systems Localand Metropolitan Area Network Specific Requirements - Part 11:Wireless LAN Media Access Control (MAC) and Physical Layer(PHY) Specifications, 1999.[17]WiMAX Home Page, .[18] B Aboba, et. al., “PPP Extensible Authentication Protocol (EAP)”,RFC 3748, June 2004.[19]IETF TLS Mailing List, /html.charters/tls-charter.html.[20]S Blake-Wilson, et. al., “Transport Layer Security (TLS) Extensions”,RFC 3546, June 2003.[21]P Urien and M Dandjinou, “Introducing smartcard enabled RADIUSserver”, 2006 International Symposium on Collaborative Technologies and Systems (CTS 2006), Las Vegas, Nevada, USA,May 14-17, 2006[22]Java Card Home Page, /products/javacard.[23]Z Chen, “Java Card Technology for Smart Cards: Architecture andProgrammer's Guide”, Addison-Wesley Professional; 2000[24]ISO 7816, “Cards Identification - Integrated Circuit Cards withContacts”.[25]Institute of Electrical and Electronics Engineers, “Local andMetropolitan Area Networks: Port-Based Network Access Control”,IEEE Standard 802.1X, September 2001.[26]RFC 3559, “RADIUS (Remote Authentication Dial In User Service)Support For Extensible Authentication Protocol (EAP)”, September2003[27]Internet draft, “EAP-Support in Smartcard”, draft-eap-smartcard-11.txt, October 2006.[28]P Urien and M Dandjinou, “Designing smartcards for emergingwireless networks”, Seventh Smart Card Research and AdvancedApplication IFIP Conference, CARDIS 2006, Tarragona-Catalonia,April 19-21 2006.。
CAN总线理论知识(英文版)
AN713 Controller Area Network (CAN) BasicsINTRODUCTIONController Area Network (CAN) was initially created by German automotive system supplier Robert Bosch in the mid-1980s for automotive applications as a method for enabling robust serial communication. The goal was to make automobiles more reliable, safe and fuel-effi-cient while decreasing wiring harness weight and com-plexity. Since its inception, the CAN protocol has gained widespread popularity in industrial automation and automotive/truck applications. Other markets where networked solutions can bring attractive benefits like medical equipment, test equipment and mobile machines are also starting to utilize the benefits of CAN. The goal of this application note is to explain some of the basics of CAN and show the benefits of choosing CAN for embedded systems networked applications. CAN OVERVIEWMost network applications follow a layered approach to system implementation. This systematic approach enables interoperability between products from differ-ent manufacturers. A standard was created by the International Standards Organization (ISO) as a tem-plate to follow for this layered approach. It is called the ISO Open Systems Interconnection (OSI) Network Layering Reference Model and is shown in Figure 1 for reference.The CAN protocol itself implements most of the lower two layers of this reference model. The communication medium portion of the model was purposely left out of the Bosch CAN specification to enable system design-ers to adapt and optimize the communication protocol on multiple media for maximum flexibility (twisted pair, single wire, optically isolated, RF, IR, etc.). With this flexibility, however, comes the possibility of interopera-bility concerns.T o ease some of these concerns, the International Stan-dards Organization and Society of Automotive Engi-neers (SAE) have defined some protocols based on CAN that include the Media Dependant Interface defini-tion such that all of the lower two layers are specified. ISO11898 is a standard for high-speed applications, ISO11519 is a standard for low-speed applications, and J1939 (from SAE) is targeted for truck and bus applica-tions. All three of these protocols specify a 5V differen-tial electrical bus as the physical interface.The rest of the layers of the ISO/OSI protocol stack are left to be implemented by the system software developer. Higher Layer Protocols (HLPs) are generally used to imple-ment the upper five layers of the OSI Reference Model.HLPs are used to:1) standardize startup procedures including bit ratesused,2) distribute addresses among participating nodesor types of messages,3) determine the structure of the messages, and4) provide system-level error handling routines.This is by no means a full list of the functions HLPs perform, however it does describe some of their basic functionality. CAN PROTOCOL BASICSCarrier Sense Multiple Access with Collision Detection (CSMA/CD)The CAN communication protocol is a CSMA/CD proto-col. The CSMA stands for Carrier Sense Multiple Access. What this means is that every node on the net-work must monitor the bus for a period of no activity before trying to send a message on the bus (Carrier Sense). Also, once this period of no activity occurs, every node on the bus has an equal opportunity to transmit a message (Multiple Access). The CD stands for Collision Detection. If two nodes on the network start transmitting at the same time, the nodes will detect the ‘collision’ and take the appropriate action. In CAN protocol, a non-destructive bitwise arbitration method is utilized. This means that messages remain intact after arbitration is completed even if collisions are detected. All of this arbi-tration takes place without corruption or delay of the higher priority message.There are a couple of things that are required to sup-port non-destructive bitwise arbitration. First, logic states need to be defined as dominant or recessive. Second, the transmitting node must monitor the state of the bus to see if the logic state it is trying to send actu-ally appears on the bus. CAN defines a logic bit 0 as a dominant bit and a logic bit 1 as a recessive bit.Author:Keith PazulMicrochip Technology Inc.© 1999 Microchip Technology Inc.Preliminary DS00713A-page 1AN713DS00713A-page 2Preliminary© 1999 Microchip Technology Inc.A dominant bit state will always win arbitration over a recessive bit state, therefore the lower the value in the Message Identifier (the field used in the message arbitra-tion process), the higher the priority of the message. As an example, suppose two nodes are trying to transmit a mes-sage at the same time. Each node will monitor the bus to make sure the bit that it is trying to send actually appears on the bus. The lower priority message will at some point try to send a recessive bit and the monitored state on the bus will be a dominant. At that point this node loses arbi-tration and immediately stops transmitting. The higher pri-ority message will continue until completion and the node that lost arbitration will wait for the next period of no activity on the bus and try to transmit its message again.Message-Based CommunicationCAN protocol is a message-based protocol, not an address based protocol. This means that messages are not transmitted from one node to another node based on addresses. Embedded in the CAN message itself is the priority and the contents of the data being transmitted. All nodes in the system receive every message transmitted on the bus (and will acknowledge if the message was prop-erly received). It is up to each node in the system to decide whether the message received should be immediately dis-carded or kept to be processed. A single message can be destined for one particular node to receive, or many nodes based on the way the network and system are designed. For example, an automotive airbag sensor can be con-nected via CAN to a safety system router node only.This router node takes in other safety system informa-tion and routes it to all other nodes on the safety system network. Then all the other nodes on the safety system network can receive the latest airbag sensor informa-tion from the router at the same time, acknowledge if the message was received properly, and decide whether to utilize this information or discard it.Another useful feature built into the CAN protocol is the ability for a node to request information from other nodes. This is called a Remote T ransmit Request (RTR). This is different from the example in the previ-ous paragraph because instead of waiting for informa-tion to be sent by a particular node, this node specifically requests data to be sent to it.For example, a safety system in a car gets frequent updates from critical sensors like the airbags, but it may not receive frequent updates from other sensors like the oil pressure sensor or the low battery sensor to make sure they are functioning properly. Periodically, the safety system can request data from these other sensors and perform a thorough safety system check. The system designer can utilize this feature to minimize network traf-fic while still maintaining the integrity of the network.One additional benefit of this message-based protocol is that additional nodes can be added to the system without the necessity to reprogram all other nodes to recognize this addition. This new node will start receiv-ing messages from the network and, based on the message ID, decide whether to process or discard the received information.CAN Message Frame DescriptionCAN protocol defines four different types of messages (or Frames). The first and most common type of frame is a Data Frame. This is used when a node transmits information to any or all other nodes in the system. Sec-ond is a Remote Frame, which is basically a Data Frame with the RTR bit set to signify it is a Remote Transmit Request (see Figure 2 and Figure 3 for details on Data Frames). The other two frame types are for handling errors. One is called an Error Frame and one is called an Overload Frame. Error Frames are gener-ated by nodes that detect any one of the many protocol errors defined by CAN. Overload errors are generated by nodes that require more time to process messages already received.Data Frames consist of fields that provide additional information about the message as defined by the CAN specification. Embedded in the Data Frames are Arbi-tration Fields, Control Fields, Data Fields, CRC Fields,a 2-bit Acknowledge Field and an End of Frame. The Arbitration Field is used to prioritize messages on the bus. Since the CAN protocol defines a logical 0 as the dominant state, the lower the number in the arbitration field, the higher priority the message has on the bus. The arbitration field consists of 12-bits (11 identifier bits and one RTR bit) or 32-bits (29 identifier bits, 1-bit to define the message as an extended data frame, an SRR bit which is unused, and an RTR bit), depending on whether Standard Frames or Extended Frames are being utilized. The cur-rent version of the CAN specification, version 2.0B,defines 29-bit identifiers and calls them Extended Frames.Previous versions of the CAN specification defined 11-bit identifiers which are called Standard Frames.As described in the preceding section, the Remote T ransmit Request (RTR) is used by a node when it requires information to be sent to it from another node.T o accomplish an RTR, a Remote Frame is sent with the identifier of the required Data Frame. The RTR bit in the Arbitration Field is utilized to differentiate between a Remote Frame and a Data Frame. If the RTR bit is recessive, then the message is a Remote Frame. If the RTR bit is dominant, the message is a Data Frame.The Control Field consists of six bits. The MSB is the IDE bit (signifies Extended Frame) which should be dominant for Standard Data Frames. This bit deter-mines if the message is a Standard or Extended Frame.In Extended Frames, this bit is RB1 and it is reserved.The next bit is RB0 and it is also reserved. The four LSBs are the Data Length Code (DLC) bits. The Data Length Code bits determine how many data bytes are included in the message. It should be noted that a Remote Frame has no data field, regardless of the value of the DLC bits.The Data Field consists of the number of data bytes described in the Data Length Code of the Control Field. The CRC Field consists of a 15-bit CRC field and a CRC delimiter, and is used by receiving nodes to deter-mine if transmission errors have occurred.AN713The Acknowledge Field is utilized to indicate if the mes-sage was received correctly. Any node that has cor-rectly received the message, regardless of whether the node processes or discards the data, puts a dominant bit on the bus in the ACK Slot bit time (see Figure 2 or Figure 3 for the location of the ACK Slot bit time).The last two message types are Error Frames and Overload Frames. When a node detects one of the many types of errors defined by the CAN protocol, an Error Frame occurs. Overload Frames tell the network that the node sending the Overload Frame is not ready to receive additional messages at this time, or that intermission has been violated. These errors will be discussed in more detail in the next section.Fast, Robust CommunicationBecause CAN was initially designed for use in automo-biles, a protocol that efficiently handled errors was crit-ical if it was to gain market acceptance. With the release of version 2.0B of the CAN specification, the maximum communication rate was increased 8x over the version 1.0 specification to 1Mbit/sec. At this rate, even the most time-critical parameters can be transmit-ted serially without latency concerns. In addition to this, the CAN protocol has a comprehensive list of errors it can detect that ensures the integrity of messages. CAN nodes have the ability to determine fault condi-tions and transition to different modes based on the severity of problems being encountered. They also have the ability to detect short disturbances from per-manent failures and modify their functionality accord-ingly. CAN nodes can transition from functioning like a normal node (being able to transmit and receive mes-sages normally), to shutting down completely (bus-off) based on the severity of the errors detected. This fea-ture is called Fault Confinement. No faulty CAN node or nodes will be able to monopolize all of the bandwidth on the network because faults will be confined to the faulty nodes and these faulty nodes will shut off before bring-ing the network down. This is very powerful because Fault Confinement guarantees bandwidth for critical system information.As discussed previously, there are five error conditions that are defined in the CAN protocol and three error states that a node can be in, based upon the type and number of error conditions detected. The following sec-tion describes each one in more detail.Errors DetectedCRC ErrorA 15-bit Cyclic Redundancy Check (CRC) value is cal-culated by the transmitting node and this 15-bit value is transmitted in the CRC field. All nodes on the network receive this message, calculate a CRC and verify that the CRC values match. If the values do not match, a CRC error occurs and an Error Frame is generated. Since at least one node did not properly receive the message, it is then resent after a proper intermission time.Acknowledge ErrorIn the Acknowledge Field of a message, the transmit-ting node checks if the Acknowledge Slot (which it has sent as a recessive bit) contains a dominant bit. This dominant bit would acknowledge that at least one node correctly received the message. If this bit is recessive, then no node received the message prop-erly. An Acknowledge Error has occurred. An Error Frame is then generated and the original message will be repeated after a proper intermission time.Form ErrorIf any node detects a dominant bit in one of the fol-lowing four segments of the message: End of Frame, Interframe Space, Acknowledge Delimiter or CRC Delimiter, the CAN protocol defines this to be a form violation and a Form Error is generated. The original message is then resent after a proper intermission time. (see Figure 2 and/or Figure 3 for where these segments lie in a CAN message).Bit ErrorA Bit Error occurs if a transmitter sends a dominant bit and detects a recessive bit, or if it sends a reces-sive bit and detects a dominant bit when monitoring the actual bus level and comparing it to the bit that it has just sent. In the case where the transmitter sends a recessive bit and a dominant bit is detected during the Arbitration Field or Acknowledge Slot, no Bit Error is generated because normal arbitration or acknowledgment is occurring. If a Bit Error is detected, an Error Frame is generated and the origi-nal message is resent after a proper intermission time.Stuff ErrorCAN protocol uses a Non-Return–to-Zero (NRZ) transmission method. This means that the bit level is placed on the bus for the entire bit time. CAN is also asynchronous, and bit stuffing is used to allow receiving nodes to synchronize by recovering clock information from the data stream. Receiving nodes synchronize on recessive to dominant transitions. If there are more than five bits of the same polarity in a row, CAN will automatically stuff an opposite polarity bit in the data stream. The receiving node(s) will use it for synchronization, but will ignore the stuff bit for data purposes. If, between the Start of Frame and the CRC Delimiter, six consecutive bits with the same polarity are detected, then the bit stuffing rule has been violated. A Stuff Error then occurs, an Error Frame is sent, and the message is repeated.© 1999 Microchip Technology Inc.Preliminary DS00713A-page 3AN713DS00713A-page 4Preliminary© 1999 Microchip Technology Inc.Error StatesDetected errors are made public to all other nodes via Error Frames or Error Flags. The transmission of an erroneous message is aborted and the frame is repeated as soon as the message can again win arbi-tration on the network. Also, each node is in one of three error states, Error-Active, Error-Passive or Bus-Off.Error-ActiveAn Error-Active node can actively take part in bus communication, including sending an active error flag,which consists of six consecutive dominant bits. The Error Flag actively violates the bit stuffing rule and causes all other nodes to send an Error Flag, called the Error Echo Flag, in response. An Active Error Flag,and the subsequent Error Echo Flag may cause as many as twelve consecutive dominant bits on the bus;six from the Active Error Flag, and zero up to six more from the Error Echo Flag depending upon when each node detects an error on the bus. A node is Error-Active when both the T ransmit Error Counter (TEC)and the Receive Error Counter (REC) are below 128.Error-Active is the normal operational mode, allowing the node to transmit and receive without restrictions. Error-PassiveA node becomes Error-Passive when either the Transmit Error Counter or Receive Error Counter exceeds 127. Error-Passive nodes are not permitted to transmit Active Error Flags on the bus, but instead,transmit Passive Error Flags which consist of six recessive bits. If the Error-Passive node is currently the only transmitter on the bus then the passive error flag will violate the bit stuffing rule and the receiving node(s) will respond with Error Flags of their own (either active or passive depending upon their own error state). If the Error-Passive node in question is not the only transmitter (i.e. during arbitration) or is a receiver, then the Passive Error Flag will have no effect on the bus due to the recessive nature of the error flag. When an Error-Passive node transmits a Passive Error Flag and detects a dominant bit, it must see the bus as being idle for eight additional bit times after an intermission before recognizing the bus as available. After this time, it will attempt to retransmit. Bus-OffA node goes into the Bus-Off state when the Trans-mit Error Counter is greater than 255 (receive errors can not cause a node to go Bus-Off). In this mode,the node can not send or receive messages,acknowledge messages, or transmit Error Frames of any kind. This is how Fault Confinement is achieved.There is a bus recovery sequence that is defined by the CAN protocol that allows a node that is Bus-Off to recover, return to Error-Active, and begin transmit-ting again if the fault condition is removed.CONCLUSIONThe CAN protocol was optimized for systems that need to transmit and receive relatively small amounts of information (as compared to Ethernet or USB, which are designed to move much larger blocks of data) reli-ably to any or all other nodes on the network. CSMA/CD allows every node to have an equal chance to gain access to the bus, and allows for smooth handling of collisions.Since the protocol is message-based, not address based, all messages on the bus receive every message and acknowledge every message, regardless of whether in needs the data or not. This allows the bus to operate in node-to-node or multicast messaging for-mats without having to send different types of mes-sages.Fast, robust message transmission with fault confine-ment is also a big plus for CAN because faulty nodes will automatically drop off the bus not allowing any one node from bringing a network down. This effectively guarantees that bandwidth will always be available for critical messages to be transmitted. With all of these benefits built into the CAN protocol and its momentum in the automotive world, other markets will begin to see and implement CAN into their systems.© 1999 Microchip Technology Inc.PreliminaryDS00713A-page 5AN713FIGURE 1:ISO/OSI Reference ModelApplication Presentation Session T ransport Network Data Link Layer Physical LayerLogical Link Control (LLC)•Acceptance Filtering •Overload Notification •Recovery ManagementMedium Access Control (MAC)•Data Encapsulation/Decapsulation •Frame Coding (Stuffing/Destuffing)]•Error Detection/Signalling •Serialization/DeserializationPhysical Signaling (PLS)•Bit Encoding/Decoding •Bit Timing/SynchronizationPhysical Medium Attachment (PMA)•Driver/Receiver CharacteristicsMedium Dependent Interface (MDI)•ConnectorsISO/OSI Reference ModelOSI Reference LayersAN713DS00713A-page 6Preliminary© 1999 Microchip Technology Inc.FIGURE 2:Standard Data Frame1111111111111111111111110I N TS u s p e n d T r a n s m i tB u s I d l e A n y F r a m e I n t e r -F r a m e S p a c eS t a r t o f F r a m eD a t a F r a m e o r R e m o t e F r a m e38000111111111S t a r t o f F r a m eD a t a F r a m e (n u m b e r o f b i t s = 44 + 8N )12A r b i t r a t i o n F i e l dI D 1011I D 3I D 0I d e n t i f i e r M e s s a g e F i l t e r i n g S t o r e d i n B u f f e r sR T R I D E R B 0D L C 3D L C 064C o n t r o l F i e l d D a t a L e n g t h C o d eR e s e r v e d B i t8N (0≤N ≤8)D a t a F i e l d 88S t o r e d i n T r a n s m i t /R e c e i v e B u f f e r s B i t S t u f f i n g 16C R C F i e l d15C R C7E n d o fF r a m eC R CD e l A c k S l o t B i t A C K D e l 1111111111111111111111110I N T S u s p e n d T r a n s m i t B u s I d l eA n y F r a m e I n t e r -F r a m e S p a c eS t a r t o f F r a m eD a t a F r a m e o r R e m o t e F r a m e38© 1999 Microchip Technology Inc.PreliminaryDS00713A-page 7AN713FIGURE 3:Extended Data Frame111110B u s I d l eS t a r t o f F r a m eD a t a F r a m e o r R e m o t e F r a m e110001S t a r t o f F r a m eA r b i t r a t i o n F i e l d3211I D 10I D 3I D 0I D E I d e n t i f i e rM e s s a g e F i l t e r i n gS t o r e d i n B u f f e r sS R R E I D 17E I D 0R T R R B 1R B 0D L C 318D L C 06C o n t r o l F i e l d 4R e s e r v e d b i t sD a t a L e n g t h C o d eS t o r e d i n T r a n s m i t /R e c e i v e B u f f e r s88D a t a F r a m e (n u m b e r o f b i t s = 64 + 8N )8N (0≤N ≤8)D a t a F i e l d 1111111116C R C F i e l d 15C R CC R CD e l A c k S l o t B i t A C K D e lE n d o fF r a m e7B i t S t u f f i n g1111111111111111111111110I N T S u s p e n d T r a n s m i t B u s I d l eA n y F r a m e I n t e r -F r a m e S p a c eS t a r t o f F r a m eD a t a F r a m e o r R e m o t e F r a m e38E x t e n d e d I d e n t i f i e r2002 Microchip Technology Inc.Information contained in this publication regarding device applications and the like is intended through suggestion only and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. No representation or warranty is given and no liability is assumed by Microchip Technology Incorporated with respect to the accuracy or use of such information, or infringement of patents or other intellectual property rights arising from such use or otherwise. Use of Microchip’s products as critical com-ponents in life support systems is not authorized except with express written approval by Microchip. No licenses are con-veyed, implicitly or otherwise, under any intellectual property rights.TrademarksThe Microchip name and logo, the Microchip logo, FilterLab, K EE L OQ, microID, MPLAB, PIC, PICmicro, PICMASTER, PICSTART, PRO MATE, SEEVAL and The Embedded Control Solutions Company are registered trademarks of Microchip T ech-nology Incorporated in the U.S.A. and other countries.dsPIC, ECONOMONITOR, FanSense, FlexROM, fuzzyLAB, In-Circuit Serial Programming, ICSP, ICEPIC, microPort, Migratable Memory, MPASM, MPLIB, MPLINK, MPSIM, MXDEV, PICC, PICDEM, , rfPIC, Select Mode and Total Endurance are trademarks of Microchip Technology Incorporated in the U.S.A.Serialized Quick Turn Programming (SQTP) is a service mark of Microchip Technology Incorporated in the U.S.A.All other trademarks mentioned herein are property of their respective companies.© 2002, Microchip Technology Incorporated, Printed in the U.S.A., All Rights Reserved.Printed on recycled paper.Microchip received QS-9000 quality systemcertification for its worldwide headquarters,design and wafer fabrication facilities inChandler and Tempe, Arizona in July 1999. TheCompany’s quality system processes andprocedures are QS-9000 compliant for itsPICmicro®8-bit MCUs, K EE L OQ®code hoppingdevices, Serial EEPROMs and microperipheralproducts. In addition, Microchip’s qualitysystem for the design and manufacture ofdevelopment systems is ISO 9001 certified.Note the following details of the code protection feature on PICmicro® MCUs.•The PICmicro family meets the specifications contained in the Microchip Data Sheet.•Microchip believes that its family of PICmicro microcontrollers is one of the most secure products of its kind on the market today, when used in the intended manner and under normal conditions.•There are dishonest and possibly illegal methods used to breach the code protection feature. All of these methods, to our knowl-edge, require using the PICmicro microcontroller in a manner outside the operating specifications contained in the data sheet.The person doing so may be engaged in theft of intellectual property.•Microchip is willing to work with the customer who is concerned about the integrity of their code.•Neither Microchip nor any other semiconductor manufacturer can guarantee the security of their code. Code protection does not mean that we are guaranteeing the product as “unbreakable”.•Code protection is constantly evolving. We at Microchip are committed to continuously improving the code protection features of our product.If you have any further questions about this matter, please contact the local sales office nearest to you.MAMERICASCorporate Office2355 West Chandler Blvd.Chandler, AZ 85224-6199Tel: 480-792-7200 Fax: 480-792-7277 Technical Support: 480-792-7627Web Address: Rocky Mountain2355 West Chandler Blvd.Chandler, AZ 85224-6199Tel: 480-792-7966 Fax: 480-792-7456 Atlanta500 Sugar Mill Road, Suite 200B Atlanta, GA 30350Tel: 770-640-0034 Fax: 770-640-0307 Boston2 Lan Drive, Suite 120Westford, MA 01886Tel: 978-692-3848 Fax: 978-692-3821 Chicago333 Pierce Road, Suite 180Itasca, IL 60143Tel: 630-285-0071 Fax: 630-285-0075 Dallas4570 Westgrove Drive, Suite 160 Addison, TX 75001Tel: 972-818-7423 Fax: 972-818-2924 DetroitTri-Atria Office Building32255 Northwestern Highway, Suite 190 Farmington Hills, MI 48334Tel: 248-538-2250 Fax: 248-538-2260 Kokomo2767 S. Albright RoadKokomo, Indiana 46902Tel: 765-864-8360 Fax: 765-864-8387 Los Angeles18201 Von Karman, Suite 1090 Irvine, CA 92612Tel: 949-263-1888 Fax: 949-263-1338 New York150 Motor Parkway, Suite 202 Hauppauge, NY 11788Tel: 631-273-5305 Fax: 631-273-5335 San JoseMicrochip Technology Inc.2107 North First Street, Suite 590San Jose, CA 95131Tel: 408-436-7950 Fax: 408-436-7955 Toronto6285 Northam Drive, Suite 108 Mississauga, Ontario L4V 1X5, Canada Tel: 905-673-0699 Fax: 905-673-6509ASIA/PACIFICAustraliaMicrochip Technology Australia Pty LtdSuite 22, 41 Rawson StreetEpping 2121, NSWAustraliaTel: 61-2-9868-6733 Fax: 61-2-9868-6755China - BeijingMicrochip Technology Consulting (Shanghai)Co., Ltd., Beijing Liaison OfficeUnit 915Bei Hai Wan Tai Bldg.No. 6 Chaoyangmen BeidajieBeijing, 100027, No. ChinaTel: 86-10-85282100 Fax: 86-10-85282104China - ChengduMicrochip Technology Consulting (Shanghai)Co., Ltd., Chengdu Liaison OfficeRm. 2401, 24th Floor,Ming Xing Financial TowerNo. 88 TIDU StreetChengdu 610016, ChinaTel: 86-28-6766200 Fax: 86-28-6766599China - FuzhouMicrochip Technology Consulting (Shanghai)Co., Ltd., Fuzhou Liaison OfficeUnit 28F, World Trade PlazaNo. 71 Wusi RoadFuzhou 350001, ChinaTel: 86-591-7503506 Fax: 86-591-7503521China - ShanghaiMicrochip Technology Consulting (Shanghai)Co., Ltd.Room 701, Bldg. BFar East International PlazaNo. 317 Xian Xia RoadShanghai, 200051Tel: 86-21-6275-5700 Fax: 86-21-6275-5060China - ShenzhenMicrochip Technology Consulting (Shanghai)Co., Ltd., Shenzhen Liaison OfficeRm. 1315, 13/F, Shenzhen Kerry Centre,Renminnan LuShenzhen 518001, ChinaTel: 86-755-2350361 Fax: 86-755-2366086Hong KongMicrochip Technology Hongkong Ltd.Unit 901-6, Tower 2, Metroplaza223 Hing Fong RoadKwai Fong, N.T., Hong KongTel: 852-2401-1200 Fax: 852-2401-3431IndiaMicrochip Technology Inc.India Liaison OfficeDivyasree Chambers1 Floor, Wing A (A3/A4)No. 11, O’Shaugnessey RoadBangalore, 560 025, IndiaTel: 91-80-2290061 Fax: 91-80-2290062JapanMicrochip Technology Japan K.K.Benex S-1 6F3-18-20, ShinyokohamaKohoku-Ku, Yokohama-shiKanagawa, 222-0033, JapanTel: 81-45-471- 6166 Fax: 81-45-471-6122KoreaMicrochip Technology Korea168-1, Youngbo Bldg. 3 FloorSamsung-Dong, Kangnam-KuSeoul, Korea 135-882Tel: 82-2-554-7200 Fax: 82-2-558-5934SingaporeMicrochip Technology Singapore Pte Ltd.200 Middle Road#07-02 Prime CentreSingapore, 188980Tel: 65-334-8870 Fax: 65-334-8850TaiwanMicrochip Technology Taiwan11F-3, No. 207Tung Hua North RoadTaipei, 105, TaiwanTel: 886-2-2717-7175 Fax: 886-2-2545-0139EUROPEDenmarkMicrochip Technology Nordic ApSRegus Business CentreLautrup hoj 1-3Ballerup DK-2750 DenmarkTel: 45 4420 9895 Fax: 45 4420 9910FranceMicrochip Technology SARLParc d’Activite du Moulin de Massy43 Rue du Saule TrapuBatiment A - ler Etage91300 Massy, FranceTel: 33-1-69-53-63-20 Fax: 33-1-69-30-90-79GermanyMicrochip Technology GmbHGustav-Heinemann Ring 125D-81739 Munich, GermanyTel: 49-89-627-144 0 Fax: 49-89-627-144-44ItalyMicrochip Technology SRLCentro Direzionale ColleoniPalazzo Taurus 1 V. Le Colleoni 120041 Agrate BrianzaMilan, ItalyTel: 39-039-65791-1 Fax: 39-039-6899883United KingdomArizona Microchip Technology Ltd.505 Eskdale RoadWinnersh TriangleWokinghamBerkshire, England RG41 5TUTel: 44 118 921 5869Fax: 44-118 921-582001/18/02W ORLDWIDE S ALES AND S ERVICE2002 Microchip Technology Inc.。
Asynchronous transfer mode
Asynchronous transfer mode(ATM)Asynchronous transfer mode (Asynchronous Transfer Mode, the abbreviation for ATM), also called relay information element. Asynchronous transfer mode (ATM) in ATM reference mode consists of a set of protocols. ATM Exchange with connection-oriented, it is in a cell. Each cell length 53 bytes. Which account for 5-byte header. Information element relay (cell relay) of a standard (ITU) implementation of program, this is a fixed-length packet (information) of Exchange technology. Is referred to as asynchronous, because from a user, contains information element to appear is not a cyclical.异步传输模式（缩写为ATM）也叫中继元信息传输，他是由一系列的程序组成的。
异步传输与面向连接传输在一个单元里转换，每个单元有53个字节，其中有5个字节起作用中继元信息传输是以固定长度的数据包技术交换实现的。
它之所以被称为异步传输是因为无论从使用还是信息元素都不在一个周期内。
ATM (Asynchronous Transfer Mode, asynchronous transfer mode a way to pass a comprehensive business information on high speed, high efficiency, control of flexible, innovative information transfer mode, has been ITU-T (International Telecommunication Union T elecommunication Standardization sector) to transfer and exchange of voice. Images, data and multimedia information tools, people's attention, is today one of the hot topics of information exchange. The birth of ATM technology has its inevitability, with the advent of the information society, people on communication needs are far beyond the traditional telephone and telegraph services, data communications, broadband communications, demand is increasing, due to their bandwidth and traffic requirements, the traditional means of communication have been very difficult to achieve. For example, the existing network are designed for a specific business, often do not apply to other business: CNN cannot transfer telephone service, telecom network cannot transmit TV signals. Obviously these networks to support new business capacity is not enough. It is hoped that in future, it is best to only one network exists, it is not dependent on the business, with the flexibility, security, economic and efficient use of all resources, ATM technology is considered implementation of key technologies.ATM（异步传输模式）是一种高速.高效.高灵活度.高创新度的综合信息传输模式，他被国际信联认定为传输声音图像和多媒体的工具，他已经成为一个备受人们关注的热门话题。
CAN 总线协议外文翻译
CAN Bus ProtocolIntroductionController Area Network (CAN) was initially created by German automotive system supplier Robert Bosch in the mid-1980s for automotive applications as a method for enabling robust serial communication. The goal was to make automobiles more reliable, safe and fuel-efficient while decreasing wiring harness weight and complexity. Since its inception, the CAN protocol has gained widespread popularity in industrial automation and automotive/truck applications. Other markets where networked solutions can bring attractive benefits like medical equipment, test equipment and mobile machines are also starting to utilize the benefits of CAN. The goal of this application note is to explain some of the basics of CAN and show the benefits of choosing CAN for embedded systems networked applications.CAN OverviewMost network applications follow a layered approach to system implementation. This system etic approach enables sinter operability between products from different manufacturers. A standard was created by the International Standards Organization (ISO) as a template to follow for this layered approach. It is called the ISO Open Systems Interconnection (OSI) Network Layering Reference Model. The CAN protocol itself implements most of the lower two layers of this reference model. The communication medium portion of the model was purposely left out of the Bosch CAN specification to enable system designers to adapt and optimize the communication protocol on multiple media for maximum flexibility (twisted pair, single wire, optically isolated, RF, IR, etc.). With this flexibility, however, comes the possibility of interoperability concerns. To ease some of these concerns, the International Standards Organization and Society of Automotive Engineers (SAE) have defined some protocols based on CAN that include the Media Dependents Interface definition such that all of the lower two layers are specified.ISO11898 is a standard for high-speed applications, ISO11519 is a standard forlow-speed applications, and J1939 (from SAE) is targeted for truck and bus applications. All three of these protocols specify a 5V differential electrical bus as the physical interface. The rest of the layers of the ISO/OSI protocol stack are left to be implemented by the system software developer. Higher Layer Protocols (HLPs) are generally used to implement the upper five layers of the OSI Reference Model.HLPs are used to:1) Standardize startup procedures including bit rates used,2) Distribute addresses among participating nodes or types of messages,3) Determine the structure of the messages, and4) Provide system-level error handling routines. This is by no means a full list of the functions HLPs perform; however it does describe some of their basic functionality.CAN Protocol BasicsCarrier Sense Multiple Access with Collision Detection (CSMA/CD)The CAN communication protocol is a CSMA/CD protocol. The CSMA stands for Carrier Sense Multiple Access. What this means is that every node on the network must monitor the bus for a period of no activity before trying to send a message on the bus (Carrier Sense). Also, once this period of no activity occurs, every node on the bus has an equal opportunity to transmit a message (Multiple Access). The CD stands for Collision Detection. If two nodes on the network start transmitting at the same time, the nodes will detect the ‘collision’ and take the appropriate action. In CAN protocol, a nondestructive bitwise arbitration method is utilized. This means that messages remain intact after arbitration is completed even if collisions are detected. All of this arbitration takes place without corruption or delay of the higher priority message.There are a couple of things that are required to support non-destructive bitwise arbitration. First, logic states need to be defined as dominant or recessive. Second, the transmitting node must monitor the state of the bus to see if the logic state it is trying to send actually appears on the bus. CAN define a logic bit 0 as a dominant bit and a logic bit 1 as a recessive bit.A dominant bit state will always win arbitration over a recessive bit state, therefore thelower the value in the Message Identifier (the field used in the message arbitration process), the higher the priority of the message. As an example, suppose two nodes are trying to transmit a message at the same time. Each node will monitor the bus to make sure the bit that it is trying to send actually appears on the bus. The lower priority message will at some point try to send a recessive bit and the monitored state on the bus will be a dominant. At that point this node loses arbitration and immediately stops transmitting. The higher priority message will continue until completion and the node that lost arbitration will wait for the next period of no activity on the bus and try to transmit its message again.Message-Based CommunicationCAN protocol is a message-based protocol, not an address based protocol. This means that messages are not transmitted from one node to another node based on addresses. Embedded in the CAN message itself is the priority and the contents of the data being transmitted. All nodes in the system receive every message transmitted on the bus (and will acknowledge if the message was properly received). It is up to each node in the system to decide whether the message received should be immediately discarded or kept to be processed.A single message can be destined for one particular node to receive, or many nodes based on the way the network and system are designed. For example, an automotive airbag sensor can be connected via CAN to a safety system router node only. This router node takes in other safety system information and routes it to all other nodes on the safety system network. Then all the other nodes on the safety system network can receive the latest airbag sensor information from the router at the same time, acknowledge if the message was received properly, and decide whether to utilize this information or discard it.Another useful feature built into the CAN protocol is the ability for a node to request information from other nodes. This is called a Remote Transmit Request(RTR). This is different from the example in the previous paragraph because instead of waiting for information to be sent by a particular node, this node specifically requests data to be sent to it.One additional benefit of this message-based protocol is that additional nodes can be added to the system without the necessity to reprogram all other nodes to recognize this addition. This new node will start receiving messages from the network and, based on themessage ID, decide whether to process or discard the received information.CAN Message Frame DescriptionCAN protocol define four different types of messages (or Frames). The first and most common type of frame is a Data Frame. This is used when a node transmits information to any or all other nodes in the system. Second is a Remote Frame, which is basically a Data Frame with the RTR bit set to signify it is a Remote Transmit Request. The other two frame types are for handling errors. One is called an Error Frame and one is called an Overload Frame. Error Frames are generated by nodes that detect any one of the many protocol errors defined by CAN. Overload errors are generated by nodes that require more time to process messages already received.Data Frames consist of fields that provide additional information about the message as defined by the CAN specification. Embedded in the Data Frames are Arbitration Fields, Control Fields, Data Fields, CRC Fields, a 2-bit Acknowledge Field and an End of Frame.The Arbitration Field is used to prioritize messages on the bus. Since the CAN protocol defines a logical 0 as the dominant state, the lower the number in the arbitration field, the higher priority the message has on the bus. The arbitration field consists of 12-bits (11 identifier bits and one RTR bit) or 32-bits (29 identifier bits, 1-bit to define the message as an extended data frame, an SRR bit which isunused, and an RTR bit), depending on whether Standard Frames or Extended Frames are being utilized. The current version of the CAN specification, version 2.0B,defines 29-bit identifiers and calls them Extended Frames. Previous versions of the CAN specification defined 11-bitidentifiers which are called Standard Frames.As described in the preceding section, the Remote Transmit Request (RTR) is used by a node when it requires information to be sent to it from another node. To accomplish an RTR, a Remote Frame is sent with the identifier of the required Data Frame. The RTR bit in the Arbitration Field is utilized to differentiate between a Remote Frame and a Data Frame. If the RTR bit is recessive, then the message is a Remote Frame. If the RTR bit is dominant, the message is a Data Frame.The Control Field consists of six bits. The MSB is the IDE bit (signifies Extended Frame)which should be dominant for Standard Data Frames. This bit determines if the message is a Standard or Extended Frame. In Extended Frames, this bit is RB1 and it is reserved.The next bit is RB0 and it is also reserved. The four LSBs are the Data Length Code (DLC) bits. The Data Length Code bits determine how many data bytes are included in the message. It should be noted that a Remote Frame has no data field, regardless of the value of the DLC bits. The Data Field consists of the number of data bytes described in the Data Length Code of the Control Field. The CRC Field consists of a 15-bit CRC field and a CRC delimiter, and is used by receiving nodes to determine if transmission errors have occurred.The Acknowledge Field is utilized to indicate if the message was received correctly. Any node that has correctly received the message, regardless of whether the node processes or discards the data, puts a dominant bit on the bus in the ACK Slot bit timeThe last two message types are Error Frames and Overload Frames. When a node detects one of the many types of errors defined by the CAN protocol, an Error Frame occurs. Overload Frames tell the network that the node sending the Overload Frame is not ready to receive additional messages at this time, or that intermission has been violated. These errors will be discussed in more detail in the next section.Fast, Robust CommunicationBecause CAN was initially designed for use in auto mobiles, a protocol that efficiently handled errors was critical if it was to gain market acceptance. With the release of version 2.0B of the CAN specification, the maximum communication rate was increased 8x over the version 1.0 specification to 1Mbit/sec. At this rate, even the most time-critical parameters can be transmitted serially without latency concerns. In addition to this, the CAN protocol has a comprehensive list of errors it can detect that ensures the integrity of messages.CAN nodes have the ability to determine fault conditions and transition to different modes based on the severity of problems being encountered. They also have the ability to detect short disturbances from permanent failures and modify their functionality accordingly. CAN nodes can transition from functioning like a normal node (being able to transmit and receive messages normally), to shutting down completely (bus-off) based on the severity of the errors detected. This feature is called Fault Confinement. No faulty CAN node or nodeswill be able to monopolize all of the bandwidth on the network because faults will be confined to the faulty nodes and these faulty nodes will shut off before bringing the network down. This is very powerful because Fault Confinement guarantees bandwidth for critical system information.ConclusionThe CAN protocol was optimized for systems that need to transmit and receive relatively small amounts of information (as compared to Ethernet or USB, which are designed to move much larger blocks of data) reliably to any or all other nodes on the network. CSMA/CD allows every node to have an equal chance to gain access to the bus, and allows for smooth handling of collisions. Since the protocol is message-based, not address based, all messages on the bus receive every message and acknowledge every message, regardless of whether in needs the data or not. This allows the bus to operate in node-to-node or multicast messaging formats without having to send different types of messages.Fast, robust message transmission with fault confinement is also a big plus for CAN because faulty nodes will automatically drop off the bus not allowing any one node from bringing a network down. This effectively guarantees that bandwidth will always be available for critical messages to be transmitted. With all of these benefits built into the CAN protocol and its momentum in the automotive world, other markets will begin to see and implement CAN into their systems.CAN 总线协议简介控制器区域网络（CAN）的最初创建者是80年代中期的德国汽车系统供应商罗伯特博世，作为汽车应用启用强大的串行通信的方法。
通信工程专业英语课文翻译
Technology of Modern CommunicationText A: BluetoothBluetooth wireless technology is a short-range communications technology intended to replace the cables connecting portable（轻便的）and fixed devices while maintaining high levels of security.The key features of Bluetooth technology are robustness（稳健）, low power, and low cost .The Bluetooth specification defines a uniform structure for a wide range of devices to connect and communicate with each other.蓝牙无线技术是一种小范围无线通信技术，旨在保持高安全级的基础上，在便携式设备与固定设备之间实现无线连接。
蓝牙技术的主要特点是稳健，低功耗和低成本。
蓝牙规范定义了一个统一的结构，适用范围广的设备连接并相互沟通。
Bluetooth technology has achieved global acceptance such that any Bluetooth enable device, almost everywhere in the world, can connect to other Bluetooth enabled devices in proximity. Bluetooth enabled electronic devices connect and communicate wirelessly through short-range, ad hoc（特别）networks known as piconets Each device can simultaneously communicate with up to seven other devices within a single piconet. Each device can also belong to several piconets simultaneously. Piconets are established dynamically and automatically as Bluetooth enabled devices enter and leave radio proximity.蓝牙技术已取得全球认可，使得任何支持蓝牙的设备，几乎在世界各地，可以连接到其他支持蓝牙的邻近装置。
can通信协议解析与实现 英文
can通信协议解析与实现英文Analysis and Implementation of CAN Communication ProtocolI. IntroductionCAN (Controller Area Network) is a communication protocol used in automotive and other industrial applications. It provides a way of reliable data transmission and enables real-time communication between multiple nodes. This article analyzes the CAN communication protocol and explores its implementation.II. CAN Protocol Analysis1. Physical LayerThe physical layer of CAN defines the transmission of signals, including voltage, current and transmission rate. CAN bus uses differential signal transmission, which can effectively resist external interference and ensure reliable data transmission.2. Data Link LayerThe data link layer is the core of the CAN communication protocol, which defines the rules and mechanisms of data transmission. The CAN bus uses a master-slave structured communication method. The nodes compete for the right to use the bus. When a node obtains the right, it sends a data frame containing identifier, data and check code. Other nodes receive the frame and judge whether to receive it based on the identifier.3. Application LayerThe application layer is the highest layer of the CAN protocol, which defines the specific content and format of data frames. According to different application scenarios, the CAN bus supports multiple application layer protocols, such as CANopen, SAE J1939, etc. These protocols define specific formats and contents of data frames, as well as the communication rules and interactions between nodes.III. CAN Protocol Implementation1. Hardware ImplementationThe hardware implementation of the CAN protocol requires the use of dedicated CAN controllers and transceivers. The CAN controller is responsible for packing/unpacking data and controlling the transmission process. The transceiver is responsible for transmitting data from the CAN controller onto the bus or receiving it from the bus and passing it to the controller. The key is to select appropriate CAN controllers and transceivers and connect them correctly to the bus.2. Software ImplementationSoftware implementation is an important part of enabling CAN communication. The drivers need to be written to control the CAN controller and transceiver. The drivers interact with the operating system to accomplish sending and receiving data. Application programs are also needed to utilize CAN communication, e.g. to enable communication between nodes by sending and receiving data frames.IV. ConclusionThis article analyzes the CAN communication protocol and discusses its implementation. CAN communication features high reliability, real-timecapability and flexibility, making it suitable for automotive and industrial applications. By thoroughly understanding the CAN principles and implementation, we can better apply it to solve real-world communication problems.一、引言CAN（Controller Area Network）是一种用于汽车和其他工业领域的通信协议。
局域网控制器
局域网控制器(CAN)CAN 的全称是Controller Area Network，即局域网控制器，CAN总线是从80年代初为解决现代汽车中众多的控制与测试仪器之间的数据交换而开发的一种串行总线系统。
1993年ISO正式颁布了国际标准ISO11898-1并且包含了ISO/OSI开放式互联系统参考模型7层中的数据链路层。
CAN总线已经应用到40个半导体硬件生产厂商，它提供两种通讯服务：报文发送（传输数据帧）和报文发送请求（远程发送请求，RTR）。
其他所有服务，例如错误信号检测、自动重发错误帧都是透明使用，这就意味着CAN控制器芯片能自动执行这些服务。
CAN协议与人类交流所使用的拉丁字母具有相同的意义，这也意味着CAN控制器与打印机或打字机具有可比性。
CAN的使用者也可以通过子定义语言/语法以及单词/词组来进行通讯。
CAN特点多主机局域网：应用于智能控制与自控系统。
CAN节点在错误严重的情况下自动关闭，而使总线上其它节点的操作不受影响。
∙广播通讯机制：发送机将报文发送到总线上的所有设备，所有的接收设备接收所有的报文然后判断是否是相关信息。
这就保证了系统中所有设备所接收数据的完整性并使用相同信息。
∙错误检测与错误报文自动重发机制：这也确保了数据的完整性。
局域网控制器(CAN)-协议CAN协议是一个被定义为ISO11898的国际标准，除了CAN协议本身外，CAN 协议的一致性测试也被定义为ISO16845标准，它描述了CAN芯片的互换性。
数据交换原则CAN是基于广播通讯机制，它依靠报文(Message)的传送机制来实现。
因此CAN 并未定义站及站地址，而仅仅定义了报文。
每一个报文都有一个识别符(identifier)，在整个网络中必须是唯一的，它不但描述了某一报文的内容，而且还定义了报文的优先级。
当很多站都在访问总线时，优先级是非常重要的（总线裁决），因此CAN是通过报文的识别符来确定报文的优先级的。
TRINAMIC 产品指南说明书
TRINAMICTRINAMIC – SMART SOLUTIONS FORMOTION CONTROLTRINAMIC is a fabless semiconductor company and serves the market withself developed integrated circuits for the control of small electrical motors ina wide variety of applications. TRINAMIC’s integrated circuits are manufacturedto the highest standards in the world’s most advanced manufacturing plants.2TRINAMIC PRODUCT GUIDE3TRINAMIC PRODUCT GUIDEWhile the competition often comes from semicon-ductor technology and focuses on it, TRINAMIC is at home in both worlds – the world of motors and the world of IC design.The products – whether they are IC s, modules or the mechatronic systems (PAN drive TM ) – are in use all over the world and are selected because of their superior price/performance ratio.Applications are everywhere, where small motors are deployed and the growth of such small drives is increasing rapidly. In growing markets like biotech, medical, lab automation, semiconductor handling, TRINAMIC IC s control complex devices with dozens of axis.Traditional industries that are undergoing a para- digm change and are replacing complex mechanics by decentralized solutions that are synchronized via bus systems, count on TRINAMIC : Examples are the textile machines and furniture manufac-turing equipment.Close to the market, TRINAMIC continuously develops new products with innovative features, driven by the customers need for a higher degree of miniaturization, higher efficiency, diagnostics, and protection to enable the reliability of the complete system.TRINAMIC customers benefit from our encompass-ing knowledge about motor physics and from the extensive library of application knowledge which the company has built over the years. For custom-ers, TRINAMIC s application driven approach means that they do not need an indepth knowledgeabout motors, DSPs, or control circuitry in general. Consequently, the design phase saves the labor and costs.TRINAMIC also offers complete modules, includinghardware and software for specific motor control requirements. The modules combine TRINAMIC ’s dedicated stepper control and driver IC s with extensive experience in designing custom and off-the-shelf motion control solutions.TRINAMIC makes the difference!TRINAMICsensOstep TM sensOstep TM is based on a magnetic angularposition encoder system with low to mediumresolution for PAN drive TM mechatronic solutions. Itconsists of a small magnet positioned at the backend of a stepper motor axis and a Hall-sensor ICwith integrated digital signal processing (e.g. forautomatic gain control, temperature compensationetc.) placed above the magnet on the back side of a motor mounted printed circuit board. Startingat resolutions of 8 bit (256 steps) per revolution – which is completely sufficient for detecting step losses with standard 1.8° stepper motors – it is currently available with up-to 12bit (4096 steps). This increased resolution is sufficient for regaining position after step-loss for many applications with-out requiring any additional reference procedure.stallGuard TM TRINAMIC’s patented sensorless stall detectionstallGuard TM enables customers to detect mechani-cal overload conditions and stall conditions with-out external sensors, by measuring the load at apredefined point where a step loss has not yetoccurred. Thus, eliminates the need for reference or end switches. This reduces cost and complex-ity of applications, where a reference point is required. When compared to pure mechanical referencing, stress on the mechanic and noise is reduced.chopSync TM The patented chopSync TM feature allows veryhigh velocity operation of stepper motors usingthe standard TRINAMIC [stepper motor] driversTMC236, TMC239, TMC246 and TMC249. This isachieved by reducing resonances occurring when operating the motor at velocities where the EMF voltage exceeds the level of the supply voltage. With chopSync TM, motor velocities of several 1000 RPM can be reached.TMCL TM TMCL TM – the TRINAMIC Motion Control Language – is a programming language dedicated to motioncontrol applications. The software includes com-mands for moving one or more motor axes atcertain velocities or to certain positions and forsetting all relevant parameters of the motion con-troller. It is possible to access additional general purpose digital and analog inputs and outputs. TMCL TM is available on most TRINAM IC modules with integrated motion controller. Program de-velopment is supported by the TMCL-IDE – a PC based integrated development environment which is available free of charge.stallGuard2TM Improved version of the successfull stallGuard™feature. stallGuard2™ is the world’s first sensor-less high resolution load detection implementedin a standard stepper motor driver. This gives theuser easy and cost effective real time feedback of his application. It enables to scan the motion system without additional sensors. This can help to find the right motor and mechanics during development phase or to detect abrasion or mechanical stiffnesscoolStep TM Sensorless load dependent current control usingthe stallGuard2™ feature. First time coolStep™enables to drive a stepper motor in a energy ef-ficient way. Up to now stepper motors are drivenwith constant current. The new TMC260, TMC261and TMC262 stepper motor driver series detects the actual load of the motor and adjusts the current accordingly. This eliminates the security current margin and allow also to boost the motor avoiding stall and step loss to improve the reli-ability of the entire system.spreadCycle New patent pending constant Toff chopperscheme. Using the spreadCycle chopper the µStepcurrent sine wave is always well formed witha smooth zero crossing. Due to this effect the stepper motor can be driven very fast without resonance effects. All the coolStep™ drivers are using this new technology.hallFX TM hall FX TM generates back EMF based hallsensor like signals for the sensorless commutation of BLDC(also two phase motor when using 2 TMC603 asgate driver) motors. hall FX TM can be easily integrat-ed into your drive, since it directly emulates hall sensors and does not require complex software components to be added to your controller.5TRINAMIC PRODUCT GUIDE6TRINAMIC PRODUCT GUIDELONG LIFE AVAILABILIT YTRINAMIC offers lifecycles of up to 10years for almost all of our products, which reduces costs of re-designing, re-qualification and re-certifying for our customers. This does not only save valuable resources but reduces time-to-market.QUALIT YToday TRINAMIC has strategic allianceswith partners to ensure access to the latest technologies and processes.TRINAMIC is ISO 9001:2000 certified by Ger-manischer Lloyd and EN ISO 13485 certified for “Medical Components” by Medcert.The EtherCAT Technology Group is a global organization in which OEM, End Users and Technology Providers join in order to support and promote the tech-nology development. EtherCAT sets new standards for real-time performance and topology flexibility, whilst meeting or undercutting field bus cost levels.Our engineering team and customer service offers: f High-level specification, -jointly with customer f Technical specification and system architecture f IC s and PCB in-house design f Software development f Fast prototypingf Testing and qualification f Logistic warehousef After sales & technical supportf Online support forum: /ttdg f RMA repairTRINAMIC MEMBERSHIPSTRINAMICs ambitions are to commence different innovation platforms, where various industries and leading suppliers join forces to support, promote and advance the technology.TRINAMIC is member of the following organizations:RESPONSIBILITY –PROVIDED BY TRINAMIC7TRINAMIC PRODUCT GUIDECiA is the international users’ andmanufacturers’ group that develops and supports CANopen and other CAN-based higher-layer protocols. The nonprofit group was founded in 1992 to provide CAN-based technical, product and market-ing information.www.can-cia.de INNOMAG is an innovate platform for Magnetic Microsystems that combines the interests and potentials of manufacturers, service providers and users in a network. The target is to develop applications of magnetic Microsystems and nanotech-nologies in Germany. TRINAMIC GREENWe refer to the Directive 2002/95/EC of the European Parliament and the Council on the Restriction of the use of certain Hazardous Substances in electrical and electronic equipment. That means, all electrical and electronic equipment put on the market by TRINAMIC does not contain lead, mercury,cadmium, hexavalent chromium, polybromiated biphenyls (PBB ) or polybromiated diphenyl ethers (PBDE ) in terms of the RoHS Directive.COOPERATION8TRINAMIC PRODUCT GUIDE* also two phase motor when using 2 TMC60x as gate driverMOTION & INTERFACE CONTROLLERBLDC DRIVER WITH BACK-EMF SUPPORT, PROTECTION AND CURRENT MEASUREMENTINTEGRATED MOTION CONTROLLER AND DRIVER FOR STEPPER MOTORS9TRINAMIC PRODUCT GUIDEPOWER DRIVER FOR STEPPER MOTORSS/D Step/Direction10TRINAMIC PRODUCT GUIDEBL DC MOTOR CONTROLLER/DRIVERPIEZO MOTOR DRIVER11TRINAMIC PRODUCT GUIDESTEPPER MOTOR DRIVERS/D Step/Direction12TRINAMIC PRODUCT GUIDETMCM-1060TMCM-1180STEPPER MOTOR DRIVER + CONTROLLER WITH COOLSTEP™13TRINAMIC PRODUCT GUIDE14TRINAMICPRODUCT GUIDE STEPPER MOTOR CONTROLLER/DRIVERS/D Step/Direction15TRINAMICPRODUCT GUIDE*1) optional with additional TMCM-323*2) General Purpose16TRINAMIC PRODUCT GUIDEPANdrives TM WITH STEPPER MOTORS/D Step/Direction17TRINAMICPRODUCT GUIDEPANdrives TM WITH BLDC MOTORBIPOLAR HYBRID STEPPER MOTORSDisclaimerTRINAMIC reserves the right to make changes in the device or specifications described herein without notice. Information in this document is subject to change without notice.Please refer to the corresponding data sheets available on or on CD for detailed information. Any copying, disclosing or otherwise making use of the information is strictly prohibited.Life Support PolicyTRINAMIC Motion Control GmbH & Co. KG does not authorize or warrant any of its products for use in life support systems, without the specific written consent of TRINAMIC Motion Control GmbH & Co. KG.Copyright 2011Printed in Germany18TRINAMIC PRODUCT GUIDE19TRINAMIC PRODUCT GUIDEBRUSHLESS DC MOTOR WITH INTEGRATED HALL SENSORSVERSION 2.0 2011TRINAMIC Motion Control GmbH & Co. KGWaterloohain 5 • 22769 Hamburg • Germany。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
I/O
CAN
Control IF Configuration IF Diagnostic IF
Process IF
CAN introduction - CAN protocols - CAN physical layer - CAN implementations - Higher-layer protocols - CAN applications
© CiA
CAN
HLP history
◆ 1991: ◆ 1992: ◆ 1994: ◆ 1994: ◆ 1994: ◆ 1995: ◆ 1997: ◆ 1999: ◆ 2001: ◆ 2002: ◆ 2006: CAN Kingdom
HLP = Higher-layer protocol
CAN Application Layer (CiA 20X series) Smart Distributed System (IEC 62026, EN 50325) DeviceNet (IEC 62026, EN 50325) Truck and bus (SAE J1939) CANopen (CiA 301, EN 50325) OSEK-COM/NM (ISO 17356 series) Truck/trailer (ISO 11992-1/-2/-3) Diagnostics on CAN (ISO 15765) ISOBUS (ISO 11783 series) Re-creation vehicle CAN (CiA 501/2)
© CiA
CAN
Device object model
Required Objects
Application Object(s)
Parameter Identity
Assembly
Message Router
I/O Connection
Explicit msg
DeviceNet Object
DeviceNet
CAN introduction - CAN protocols - CAN physical layer - CAN implementations - Higher-layer protocols - CAN applications
© CiA
CAN
CAN standardization
Application Profile Device Profile Application Layer Data Link Layer Physical Layer DeviceNet device profiles CANppen application profiles CANopen device profiles SAE J1939 -based application profiles
SDS DeviceNet CANopen EN 50325-3 EN 50325-2 EN 50325-4 ISO 11898-1 CAN 2.0A (11-bit ID) ISO 11898-1 ISO 11898-1 (11-bit and (29-bit ID) 29-bit ID) ISO 11898-2
CAN-based application layer CAN data link layer CAN physical layer
CAN frame(s) Recessive Recessive
Domion object
CAN introduction - CAN protocols - CAN physical layer - CAN implementations - Higher-layer protocols - CAN applications
© CiA
CAN
CANopen features
◆ Service Data Object (SDO) protocols ◆ Standard SDO protocols ◆ SDO block protocols ◆ Process Data Object (PDO) protocol ◆ Special object protocols: ◆ Synchronization (SYNC) protocol ◆ Time Stamp (TIME) protocol ◆ Emergency (EMCY) protocol ◆ Network Management protocols: ◆ NMT Message protocol ◆ Boot-Up protocol ◆ Error Control protocols - Heartbeat protocol - Node guarding protocol
Trunk line Distance and Baud rate
100m 500m 250m 100m Max. with Thin cable @ 125Kbaud (thick) @ 250Kbaud (thick) @ 500Kbaud (thick)
(4Km with Repeaters)
CAN
CAN-based higher layer protocols
N A C
Reiner Zitzmann
(CAN in Automation)
CAN introduction - CAN protocols - CAN physical layer - CAN implementations - Higher-layer protocols - CAN applications
RS-485
ISO 11898-2 ISO 11898-2
CAN introduction - CAN protocols - CAN physical layer - CAN implementations - Higher-layer protocols - CAN applications
© CiA
ISO layer-1 - Physical ISO layer-0 - Media
{ {
{
{
Application layer Data link layer Physical signaling Transceiver Transmission media
}
}
}
DeviceNet application layer specification
CAN
CANopen device model
Protocol Stack PDO Protocol SDO Protocol Sync Protocol Time Protocol Emergency Protocol NMT Protocol Heartbeat Protocol etc. Object Dictionary Data Types Communication Objects Application Objects Proprietary Objects Application Software Device Profile Implementation Proprietary Software Routines
© CiA
CAN
Protocol layer interactions
Requesting (confirming) device
CAN-based application layer CAN data link layer CAN physical layer
Indicating (responding) device COB
CAN introduction - CAN protocols - CAN physical layer - CAN implementations - Higher-layer protocols - CAN applications
© CiA
CAN
Pre-defined CAN-ID set
CANopen introduction - Basic protocols - Additional protocols - System design - Dev ice profiles - Application profiles