Patent Application
20200374151
This patent application is a U.S. National Phase of International Patent Application No. PCT/EP2018/071361, filed 7 Aug. 2018, which claims priority to German Patent Application No. 10 2017 213 812.2, filed 8 Aug. 2017, the disclosures of which are incorporated herein by reference in their entireties.
Illustrative embodiments relate to the technical field of serial data transmission between electronic components, in particular, control units, sensors and actuators, which are interconnected via a bus system. Such control units are widely used in transportation vehicles. Networked control units, sensors and actuators are also used in other fields of technology, e.g., in automation technology, process engineering, etc. Illustrative embodiments also relate to a suitably designed bus interface and to a suitably designed computer program.
Exemplary embodiments are shown in the drawings and are explained in more detail in the following by reference to the figures. Shown are:
In modern transportation vehicles, a plurality of control units are installed. A number of control units are used for the powertrain alone, such as the engine control unit, transmission control unit, ESP control unit and others. It is also worth mentioning the category of control units, which are responsible for regulation processes in the area of suspension systems. These are control units for electronic suspension adjustment or control units for driving dynamics control or control units which provide steering assistance, such as speed-sensitive power steering. In addition, there are other control units that are installed in the area of the transportation vehicle bodywork and provide certain comfort functions. Examples of these include the electric door or window control units, air-conditioning control units, seat adjustment control units, airbag control units and similar devices. Then there is also the class of control units associated with the infotainment area, such as a camera control unit for environment monitoring, navigation device, radar or lidar equipment, communication module and entertainment module with TV, radio, video and music function.
There is a trend in the technology towards increasing use of IP communications, such as IPv6 or IPv4, for the transportation vehicle-internal networking of control units. This method works by transmission of IP packets, which can have a length of up to 64 Kbytes. Although the IP packets can be transmitted in segmented form, the use of IP communication still requires a bus technology to be used that can transmit sufficiently large messages.
Typically, the control units of the different categories are each networked with a separate bus appropriately designed for the category of device. Several different bus systems can therefore be used in the transportation vehicle. The different bus systems can be interconnected via gateways to allow a data exchange. In the area of powertrain control units, the CAN bus is typically used, as is also the case in the area of comfort control units. In the infotainment area, other bus systems are also commonly used, such as bus systems based on Ethernet technology, e.g., AVB (Audio Video Bridging), which is based on the standard family according to the IEEE 802.3 standard. Bus systems in which the data transmission takes place via fiber-optic cables can also be used. Examples to be cited are the MOST bus (Media Oriented System Transport) or the D2B bus (Domestic Digital Bus).
The Ethernet bus system dates back to the early days of networking computers and was developed at the Palo Alto Research Center, Xerox PARC in the late 1970s. From as early as 1980 the Institute of Electrical and Electronics Engineers (IEEE) has been responsible for the maintenance and further development of Ethernet. The 802 working group is responsible for Ethernet. The Ethernet-related standards are therefore identified with a prefix 802 (e.g., IEEE 802.1, IEEE 802.2, IEEE 802.3, etc.).
One of the great strengths of Ethernet is that ready-to-use protocols exist for the transport of a variety of user data, such as video/audio data, etc., and that today a wide range of physical media are supported which allow them to be used in transportation vehicles. Since the physical media are independent of the transmission protocol, other transmission techniques can also easily be developed and adapted to the requirements of the automotive industry.
It is required if the IPv6 protocol is to be used, that packets of at least 1280 bytes in size can be transmitted as the MTU (Maximum Transmission Unit), as it is known in the Ethernet standard. However, neither the classical CAN Bus 2.0, standing for Controller Area Network, used in transportation vehicles nor the already extended CAN FD Bus, standing for Controller Area Network Flexible Data Rate, satisfies this requirement since they can only transmit messages with a maximum size of 8 and 64 bytes respectively. This makes the use of the CAN bus unsuitable if it is to support the required IPv6 communication. Further details of the IPv6 protocol can be found in the RFC 2460 Specification from the Internet Engineering Task Force IETF.
Up to now, in the automotive sector IPv6 communication has hardly been used, since it involves high resource consumption. The standard approach to enable IPv6 communication is to use Ethernet technology, which is expensive for the automotive industry, as a networking technology.
For the automotive industry, the options IEEE 100BASE-T1 and IEEE 1000BASE-T1 have been developed. In this case, the transmission of data in the forward and reverse direction can be implemented using only a single twisted pair of wires. There is a Physical Layer Block, which is installed in a control unit (ECU) as a separate module/chip. This block provides the connection between the physical medium (network cable) and the Ethernet Controller Block.
In this Ethernet option, only two nodes are ever connected to one bus line. The only topology available is therefore the point-to-point connection. More than two nodes can be connected by a coupling element. This usually involves the use of a network switch, which as a Layer-2 coupling element allows the connection to multiple physical connections and can forward messages from branch to branch independently. This is one of the biggest drawbacks of the Ethernet bus system in the automotive field, because it increases costs.
In the automotive sector therefore, the use of the CAN bus (Controller Area Network) in accordance with an ISO standard tends to dominate. The CAN bus was developed in the 1980s and standardized in 1994. The corresponding ISO standard has the number ISO 11898. There is a standard for the high-speed range up to 1 Mbit/s, which is the ISO 11898-2 standard. Then there is a standard for the low-speed range up to 125 Kbit/s, which is the ISO 11898-3 standard. The ever-growing volumes of data result in ever higher bus loads on the CAN buses. This led to a further development of the CAN bus. The extended CAN bus is known under the term CAN FD bus. FD stands for flexible data rate. In this option of the CAN bus different data rates are selected. For the arbitration phase, the data rate remains low, as in the classical CAN bus. For the transmission of user data the transmission is switched to a higher data rate. If the user data in a CAN-FD message is transmitted faster, then the period for which the bus is occupied is reduced; and the load on the bus is reduced. If the transmission duration remains in the same time frame as in classical CAN messages, larger amounts of data could be transported with a CAN-FD message. This method was also implemented in CAN FD. Instead of the 8-byte long user data field, in CAN FD a 64-byte user data field is used. In one implementation the data rate for the transmission of the user data field increases, for example, from 500 Kbit/s to 2 Mbit/s.
Disclosed embodiments overcome the described drawbacks in the introduction of IP communications in the automotive sector. Disclosed embodiments enable large Ethernet frames, so-called “jumbo frames”, to be transmitted over the transportation vehicle bus without segmentation. The proven linear bus topology in the transportation vehicle is designed to be supported, where several control units are networked without the use of a switch as a coupling element. This bus structure is optimal with regard to the cabling required and overall cost. On the part of the IEEE organization, an improved 10 Mbit/s Ethernet option will be required to cope with these points. The bus subscribers will be available to split up the 10 Mbit/s of available bandwidth. The new transmission protocol should also be capable of real-time operation. At the same time, it should be able to be administered locally. This means that it may not be necessary to supply all subscribers of the network with an identical configuration. This makes it possible to significantly reduce development costs. A prioritization of the subscribers as well as the data to be transferred must be allowed. A further requirement is that the Ethernet frame format according to IEEE 802.1Q should be supported.
Disclosed embodiments provide a method for transmitting data over a serial communication bus, a correspondingly designed bus interface, and a correspondingly designed computer program.
To achieve this, a method for transmitting data over a serial communication bus is followed, in which the data are transmitted with a modified transmission frame. The modified transmission frame has at least one arbitration field and one data field, wherein the arbitration field is used to control the bus access according to the CSMA-CR method, which stands for Carrier Sense Multiple Access with Collision Resolution, by prioritization of the messages based on an identifier. A low bit rate is set for the arbitration phase and an increased bit rate is set for the transmission of the data in the data field. A start field is provided in the transmission frame and the data are packaged as an Ethernet transmission frame, which in turn is inserted into the data field of the modified transmission frame. The arbitration field and the start field thus replace a preamble and a start frame delimiter of the Ethernet transmission frame. The Ethernet transmission frame could be an Ethernet transmission frame according to the option IEEE 802.1Q.
The great advantage here is that a content-dependent, fine-grained priority-based arbitration is combined with Ethernet to produce a networking technology which is very well suited to the needs of automotive networking. The system can also be administered in a decentralized manner, as is the case today with the CAN bus. This allows a high degree of flexibility in the development process, in that individual control units in the network can be modified and further developed independently of the others. For the bus topology it is also possible to use the linear bus structure, i.e., many stations can communicate with each other at very low system costs.
The increased data rate can be fully utilized, i.e., data rates up to 10 Mbit/s and above can be achieved. Also, it is possible to choose the data rate relatively freely depending on the network size and the communication scenario.
In addition, the existing mechanisms from the CAN FD bus for evaluating the real-time capability, for example, can be adopted. At the same time, due to the maintenance of the Ethernet frame format, device addressing based on the well-known Ethernet MAC addresses can be implemented. Furthermore, on account of the large MTU (Maximum Transmission Unit) which it inherits from the Ethernet standard, the network is ideally suited to transportation vehicle-internal IP communication.
Also, from the point of view of interoperability with other Ethernet networks which will be present in the transportation vehicle in the future, this solution is beneficial. This means that the Ethernet frame can be easily extracted from the modified transmission frame and then fed to a router or network switch for forwarding to other subnets.
A particularly beneficial measure relates to the assignment of the identifiers in the arbitration field for the prioritization of the messages. According to this, the identifier in the arbitration field is divided into the areas of “Message Content” identifier and “Device” identifier. By the appropriate assignment of the device ID, one bus node can be given priority over the other subscribers on the bus. As a result, the network behavior can be planned/predicted and is therefore real-time capable. One constraint is that a unique device identifier is assigned to each device. This measure is particularly useful when multiple similar control units, actuators or sensors are networked via the communication bus.
In a simplified option, all bits of the identifier, for example, 32 bits, are used for the message content identification and prioritization. The device addressing is performed solely by the MAC addresses which are also transmitted in the modified transmission frame.
It is beneficial here if the section with the higher order bits is reserved for the prioritization of the message content and the section with the lower order bits is allocated to the device identification. As a result, as in the CAN bus, during the arbitration phase the bus access makes decisions primarily based on the message contents with different assigned priorities and only uses the device ID as a secondary criterion.
In an alternative design a 32-bit long identifier is sub-divided such that 24 bits are reserved for the prioritization of the message content and 8 bits are provided for the prioritization of the device.
In some disclosed embodiments, the data field has a variable length up to a specified upper limit. The variability of the length of the data field guarantees many application possibilities. This means that no compromise need be made if the particular application requires a high net data rate, or in another case if the real-time capability is more of a priority and low latency times are more important.
Here it is particularly beneficial if a range of 0 to 4096 bytes is specified for the variable length of the data field. This allows a good interoperability with the now widely applicable 1 Gbit Ethernet option. Routing between a part of the transportation vehicle network where the 1 Gbit Ethernet bus option is used would then be possible without segmentation. The use of IP communication then becomes possible in a straightforward way.
It is also beneficial if the length of the arbitration field is set to 32 bits. This measure simplifies the hardware development for the modified bus. Register lengths commonly used today are typically a multiple of one byte, i.e., a multiple of 8 bits.
It is also beneficial if a control field is provided between the arbitration field and data field in the modified transmission frame, in which at least one section is allocated for the length specification in terms of the data field. Here, this section therefore needs to be lengthened to be able to specify the full length of 4096 bytes. This requires 13 bits.
A CRC field can also be specified in the transmission frame, in which at least one section is provided for a CRC check code. The CRC check code is used for error detection in accordance with the well-known cyclic redundancy check algorithm. Here, it is beneficial if a start field is provided in the transmission frame and the CRC code is calculated over the start field, control field, arbitration field and data field.
In this case it is particularly beneficial if the CRC check code provided in the Ethernet transmission frame is replaced by an extended CRC check code and this is inserted into an extended CRC field (CRC) of the modified transmission frame. The extended CRC check code is calculated over the start field (SOF), arbitration field (BA), control field (DL), destination address field (DA), the source address field (SA), optional Q-TAG field (QTAG), type field (ET), data field (PL) and the section of the stuff-bit counter in the CRC field (CRC).
The same applies to the use of a bit-stuffing method, for example, one which was already used in the CAN 2.0 protocol and the CAN FD protocol. A beneficial feature here is that the data transmission takes place asynchronously and to ensure the synchronization of the data transmitting station and data receiving station a resynchronization is performed according to a bit-stuffing rule, the bit-stuffing rule being applied over the fields from the start field up to the end of the data field, and the number of the inserted stuff-bits being entered in a section of the CRC field as a check. The insertion of a stuff-bit forces an edge change on the bus, which is used in the CAN controller for resynchronization of the timer, which sets the sampling rate for the bit recovery when receiving data. A modified bit-stuffing rule is used in this case. The bit-stuffing algorithm (frame encoding) for the new transmission format is modified to the effect that a stuff-bit is inserted only after 10 consecutive bits with the same bus level, and not after 5 bits as in CAN 2.0 and CAN FD. This means fewer overhead bits are needed in the data frame, which increases the efficiency of the data transmission.
It is beneficial if an end field is also provided in the transmission frame and at least one end-of-frame code is entered in the end field, wherein the end-of-frame code has a length of 11 bits. This measure is beneficial due to the modified bit-stuffing rule. Sending the end-of-frame code enforces a violation of the new bit-stuffing rule, so that subscribers that were not synchronized properly detect this fact and can reset the CAN controller so that they can become correctly synchronized again.
In the CRC field the bit-stuffing rule in accordance with the extended protocol is not used. Therefore it is also beneficial if a stuff-bit is forcibly inserted in the CRC field at fixed specified positions. Edge changes are thus also guaranteed in the CRC field and the CAN controllers of the bus subscribers remain synchronized.
In an example, the CRC field begins with a fixed specified stuff-bit and the other fixed stuff-bits are each inserted at an interval of 9 bits of the CRC field. The fixed specified stuff-bit is complementary to its predecessor bit.
For an appropriately designed bus interface for use in the proposed method for the transmission of data over a serial communication bus, the same benefits as those described in relation to the corresponding method operations apply.
The same applies to an appropriately designed computer program, which when processed in a computation unit executes the transmitter-side operations and/or the receiver-side operations of the proposed method for transmitting data. Hardware costs are of course a key factor in the automotive sector, where less powerful microcontrollers are therefore mainly used which are supported by separate CAN controllers, in which the data transfer protocol is implemented by special hardware. In other areas, for example, in the fieldbus sector for automation technology or process engineering, more powerful microcontrollers are also used, for which the software solution then also becomes an option for implementing the extended data transmission protocol.
The following description illustrates the principles of the disclosure. It goes without saying, therefore, that persons skilled in the art will be in a position to design different arrangements which, although not explicitly described here, nevertheless embody the principles of the disclosure and are also intended to fall within its scope of protection.
The control units of the class of control units for the powertrain are networked via the bus 104. The control units connected to this are the engine control unit 121, ESP control unit 122 and transmission control unit 123. Also connected to the bus 104 are the wheel speed sensors 124 to 127. The control units of the class of control units for the suspension area are networked via the bus 106. The control units connected to this are the suspension control unit 131 and the power-assisted steering control unit 122.
To allow the exchange of data between subscribers connected to different communication buses 102, 104, 106, the gateway 140 is provided. This is connected to all three different bus systems 102, 104 and 106. The gateway 140 is designed to convert the data packets that it receives via the one communication bus so that they can be forwarded there in the transmission format of the other communication bus. As shown, as a central device the gateway 140 is connected both to the bus 102, the bus 104 and to the bus 106. It therefore performs all the necessary format conversions when data need to be exchanged between the various bus systems.
As mentioned at the beginning, a communication bus is to be used which also allows larger data packets according to the IPv4 or IPv6 protocol to be transmitted. To achieve this the use of an option of the Ethernet standard family makes sense. Here, ready-to-use transmission protocols are already available, such as IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), TCP (Transmission Control Protocol). The development effort in terms of the transmission protocols is thus kept within limits. The Ethernet network technology corresponds fully to the IEEE standard 802.3. Special variations of this technology have been developed for use in transportation vehicles. Two of these options are the above-mentioned 100BASE-T1 option and the 1000BASE-T1 option of the Ethernet standard family. The automotive industry has specified the physical layer as a communication standard for automotive Ethernet. This standard is published by the IEEE in two variations as 100BASE-T1 and 1000BASE-T1 as part of the specification IEEE P802.3bp.
A twisted-pair cable is used as the physical transmission medium in both options, to which symmetrical differential voltages are applied for the transmission of information. The voltages represent symbols that a transmitter generates (in encoded form) according to the desired bitstream. A receiver then uses the symbol stream generated to recover the bits contained in it (decoding).
A particularly attractive feature of this physical layer is that information can be transmitted on a UTP cable (a cable with a twisted pair of conductors without shielding, known as unshielded twisted pair) at 100 Mbit/s or 1000 Mbit/s. With only two subscribers even full-duplex mode is possible, i.e., two interconnected nodes can send and receive at the same time. This is the case for the Ethernet options 100BASE-T1 and 1000BASE-T1, because due to the use of the network switch only point-to-point connections are possible there. As a transmitter a node adds its own differential voltage on the two conductors, while as a receiver it subtracts its own voltage from the total voltage applied. The result of the subtraction is equal to the voltage that was sent from the counterpart. So that differential voltages can be added or subtracted, the two nodes need to know when a new symbol starts. This means that both nodes must be synchronized to the symbol stream. This is carried out in IEEE 100BASE-T1 by a master and a slave node. The master generates a continuous symbol stream to which the slave synchronizes. The configuration of the PHY as master or slave is carried out by the core software of the microcontroller. If there are more subscribers, it is mandatory for a network switch to be provided.
For the reasons already described above, the communication bus 106 for the suspension area is designed according to the IEEE 1000BASE-T1 option and the other two buses 102 and 104 according to the IEEE 100BASE-T1 option.
The same network cable which is used for the IEEE 100BASE-T1 option of Ethernet can also be used in the CAN bus as the physical transmission medium. But in this case full-duplex operation is no longer possible, because several subscribers are connected to the bus. By using the special bus arbitration procedure in accordance with CSMA/CR (standing for Carrier Sense Multiple Access/Collision Resolution, also known as CSMA/CA, standing for Carrier Sense Multiple Access/Collision Avoidance), data collisions are avoided and exactly one subscriber takes control of the bus, so that a network switch can be dispensed with.
The principle of the networking of electronic components using the communication bus is shown in more detail in
A VLAN tag consists of a Protocol Identifier (TPID) (corresponding to the VLAN identifier) and a Control Information (TCI). The TCI consists of a priority (PCP), a Drop Eligible or Canonical Form Indicator (DEI or CFI) and an identifier (VID). In the automotive industry, Identifier VID and Priority PCP are mainly used. The Identifier VID identifies the respective virtual network for the different areas of application. The priority allows the optimization of propagation times through network switches, so that important information can be forwarded expeditiously.
In the user data area of the Ethernet frame (MAC payload) information with variable length can be transferred. In the tagged MAC frame the payload field has a minimum length of 42 bytes. In accordance with the IEEE 100BASE-T1 specification this field can contain up to 1500 bytes.
A CRC checksum is transferred into the CRC field at the end of the MAC frame. The value it contains is calculated using a standardized algorithm which is implemented identically in the transmitter and the receiver. The calculation is performed with all fields of the Ethernet MAC frame and therefore secures the entire message.
The middle part of
Above it a UDP packet is shown, corresponding to User Datagram Protocol. It has a length of 1460 bytes and fits completely in the User Data field of the IPv6 packet.
The transmission of a complete Ethernet MAC frame does not now take place in accordance with the known Ethernet option IEEE 100BASE-T1. Instead, the distributed multiple bus access method according to CSMA/CR is used. For this purpose, the fields preamble and SFD shown in
The various fields of the new transmission frame formats are shown in
In the Control Field DL the section for the length specification of the data field is extended to a length of 13 bits. There is no need for the ESI bit of the CAN-FD bus at the beginning of the DL field. In the bits DL0 to DL12 the length of the user data field is specified as the number of bytes. As a result, the numerical value in this section indicates exactly the number of bytes in the User Data field. With 13 bits the maximum number of bytes that can be encoded is 8192. But also, any whole number in this range can be encoded with it. The length of the data field should contain up to 4096 bytes, to allow space for another Ethernet jumbo frame of up to this size. The DL field with 13 bits can specify more bytes, but it is fixed at 4096 bytes by specification. Therefore, an arbitrary number of bytes within the specified upper limit of 4096 can be entered in the extended data field PL.
The data field PL itself can have a variable length. Depending on the setting this can be followed by up to a maximum of 4096 bytes. This corresponds to a length of 32768 bits.
The control bits FDF, BRS and the reserved res bit between Control Field DL and Data Field PL are omitted.
The CRC check code field CRC is extended to a length of 51 bits. This is due to the simultaneous extension of the data field. In this case the length of the CRC check code has a value of 32 bits, as before. But special bits are provided for bit-stuffing. The name and position of the individual bits in the CRC field is shown in
The CRC field CF in which the CRC check code is entered is extended to a CRC length of 32 bits. The check code is entered in the bit-fields CRCO to CRC31.
To calculate the CRC check code, e.g., the polynomial G(x)=x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1 is used.
The selected polynomial corresponds to the polynomial which is proposed in the IEEE 802.3 specification for Ethernet.
The CRC checksum is calculated from the SOF bit up to the final bit of the stuff-bit counter (StuffO).
The Stuff Count section in the CRC field is modified compared to CAN FD to a length of 12 bits and relates to the bits Stuff0 to Stuff11. The data entered in the Stuff Count section is the number of stuff-bits inserted in the field from the SOF bit up to the final bit of the Data Field DF. The number of stuff-bits is binary-coded. The use of bit-stuffing is simplified however, compared to the bit-stuffing used in the CAN-FD standard, as described in detail in the following.
The insertion of stuff-bits is used for the purpose of synchronization in asynchronous data transmission. The synchronous operation of the communication partners is established using the signal edge of the start bit SOF of a CAN message changing from recessive to dominant. A resynchronization mechanism in addition to the SOF bit ensures the maintenance of the synchronous operation. The resynchronization mechanism is based on the analysis of signal edges changing from recessive to dominant. For the synchronization to be maintained here, the bit-stuffing mechanism was introduced into the CAN standard. In the ISO standard ISO 11898-1 it is specified that after a maximum of five homogeneous bits a complementary bit must be transmitted, even if a complementary bit would follow after five homogeneous bits anyway. The location of the stuff-bits is known to the receiver due to the rule, and it can ignore the stuff bits.
The bit-stuffing algorithm (frame encoding) for the new transmission format is modified to the effect that a stuff-bit is inserted only after 10 consecutive bits with the same bus level, rather than after 5 bits. This means fewer overhead bits are needed in the data frame, which increases the efficiency of the data transmission.
The variable bit-stuffing is only carried out for the bits from the SOF up to the final bit of the data field PL. From the CRC field on, predefined stuff-bits (FixedStuffx) are used. The FixedStuff bits are always inserted after 9 bits.
These are the bits FixedStuff0, FixedStuff1, FixedStuff2, FixedStuff3, FixedStuff4 and FixedStuff5. The individual stuff-bits in the CRC field are each transmitted with the complementary level of the bit transmitted immediately preceding it.
As a result of these permanently specified stuff-bits FixedStuff0, FixedStuff1, FixedStuff2, FixedStuff3, FixedStuff4 and FixedStuff5, a guaranteed edge change is effected at the desired location during transmission.
The bit FixedStuff0 is transmitted between the last data bit and the bit Stuff11.
The bit FixedStuff1 is transmitted between the bit Stuff3 and bit Stuff2.
The bit FixedStuff2 is transmitted between the bit CRC26 and bit CRC25.
The bit FixedStuff3 is transmitted between the bit CRC17 and bit CRC16.
The bit FixedStuff4 is transmitted between the bit CRC8 and bit CRC7.
The bit FixedStuff5 is transmitted between the bit CRC0 and bit CRCDel.
The CRCDel bit, which acts as a CRC delimiter, remains unchanged and has the same function as in the CAN FD standard.
In the End Field EOF the bits ACK and ACKDel known from the CAN-FD bus are omitted.
In the End Field EF, the section with the EOF identifier is extended to 11 bits. Here, instead of the standard 7 consecutive recessive bits in the CAN bus, 11 recessive bits are therefore transmitted. The extension of the EOF symbol is a consequence of the modification of the stuffing algorithm. Only after 11 consecutive bits of the same bus level is the new stuffing rule violated. This is exploited here.
In the CAN bus and CAN-FD bus a so-called Intermission Field is inserted between two transmitted data frames. Here, 3 consecutive recessive bits IFS2 to IFS0 are again transmitted. From these the CAN controllers detect that the bus has been enabled again. This field can be omitted in the new transmission format proposed here.
As shown in both
The slower bit rate is designated as bit rate Slow.
The faster bit rate is designated as bit rate Fast.
For the Slow bit rate a range between 500 kbps and 1500 kbps is specified. All bit rates in operations of 250 kbps are also supported.
For the Fast bit rate a range between 2000 kbps and 12000 kbps is specified. In this range all bit rates in 1000 kbps operations will be supported.
Higher bit rates for the Slow bit rate and the Fast bit rate can optionally be supported.
The Bus Arbitration field BA is used for bus arbitration, as in the CAN bus. In principle, the definition of the identifiers for the messages is not subject to any restrictions.
Nevertheless, from the perspective of optimizing the bus for the transmission of IP packets, it is helpful to apply an assignment policy with regard to the ID assignment.
The compliance with the assignment policy is particularly beneficial in the field of IP communication.
As in the case of the CAN bus and CAN FD, the identifier is used to implement a prioritization concept. The identifier is used as a basis for deciding which CAN node is prevalent on the bus. The bus access method corresponds to the CSMA-CR method (Carrier Sense Multiple Access with Collision Resolution). The CSMA/CR method ensures that transmit-ready CAN nodes only access the CAN bus when it is free. In the case of simultaneous bus accesses, the method of bitwise bus arbitration which underlies the CSMA/CR method ensures that the CAN node with the highest-priority CAN message will always prevail. In principle, the following applies: the higher the priority of a CAN-message, the sooner it can be transmitted on the CAN bus.
Under an unfavorable system design, low-priority CAN messages even run the risk of not being transmitted at all. Therefore, the assignment of the IDs is very important for the implementation of a deterministic data transfer.
According to the new concept, the 32 bits of the identifier are broken down into two fields [Message Content] and [Device].
The [Message Content] field comprises the higher-value bits of the identifier.
The [Device] field comprises the lower-order bits of the identifier.
The size of the individual fields can be selected in line with requirements, but must be the same for all subscribers within a CAN network. In an exemplary embodiment, 24 bits are reserved for the [Message Content] field and 8 bits for the [Device] field. It is therefore possible to apply a fine differentiation with regard to the priority of messages in the network. If two subscribers want to send a message with the same priority at the same time, then the decision as to which subscriber device receives the priority is made in the [Device] field.
A lower binary number in the [Message Content] or [Device] field corresponds to an actually higher priority. In the arbitration phase the dominant bus level always prevails on the CAN bus. A CAN node which detects that it itself has only sent the recessive bus level, but detects that the dominant level is present, concedes in the arbitration.
By the appropriate assignment of the Device ID, one bus node can be given priority over the other subscribers on the bus. As a result, the network behavior becomes predictable and is therefore real-time capable.
In the upper part of the figure the individual bit positions of the Arbitration Field BA are numbered from 0 through 31. In the [Message Content] field, for each bit the priority associated with the individual bit position is also specified. The bit position ID8 in the [Message Content] field is assigned the lowest priority Priority0 and accordingly, the bit position ID31 is assigned the highest priority Priority23 in the [Message Content] field. Likewise, the bit with the number ID0 in the [Device] field has the lowest priority and the bit with the number ID7 then has the highest priority.
In the middle section of
In the lower section of
In a simplified variation, all 32 bits of the identifier are used for the message content identification and prioritization. The device addressing is performed solely by the MAC addresses which are also transmitted in the modified transmission frame.
The disclosure is not limited to the exemplary embodiments described here. There is scope for various adaptations and modifications, which the person skilled in the art due to his expertise would also consider as belonging to the disclosure.
All examples mentioned herein, as well as conditional formulations, are to be understood as being without limitation to such specifically mentioned examples. Thus, for example, it will be acknowledged by persons skilled in the art that the block diagram shown here represents a conceptual view of an exemplary circuit arrangement.
It should be understood that the proposed method and the associated devices can be implemented in various forms of hardware, software, firmware, special processors or a combination of these.
Special processors can comprise application specific integrated circuits (ASICs), Reduced Instruction Set Computers (RISC) and/or Field Programmable Gate Arrays (FPGAs). Optionally, the proposed method and the device are implemented as a combination of hardware and software. The software may be installed as an application program on a software storage device. Typically, this will be a machine based on a computer platform, which has hardware such as one or more central processing units (CPU), a random access memory (RAM) and one or more of the input/output (I/O) interface(s). In addition, an operating system is typically installed on the computer platform. The various processes and functions which have been described here can either be part of the application program, or executed as part of the operating system.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10 2017 213 812.2 | Aug 2017 | DE | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2018/071361 | 8/7/2018 | WO | 00 |
