Basic MilCAN B Specification. Data Link Layer

Size: px

Start display at page:

Download "Basic MilCAN B Specification. Data Link Layer"

Carol Robbins
6 years ago
Views:

1 Basic MilCAN B Specification Data Link Layer IHSDB-APP-GEN-D-034 IHSDB-APP-GEN-D-034 Cover + iv + 9 pages May 2002 D Carlson Rev. 1

2 Record of changes Issue Date Detail of Changes 1.0 May 2002 First issue To request clarification of any information contained in this specification or to report any errors please contact : D Carlson Bofors Defence AB SE Karlskoga, Sweden Tel: +46 (586) Fax: +46 (586) dan.t.carlson@boforsdefence.se Rev. 1 Page ii

3 List of contents Record of changes List of contents ii iii 1 Introduction Scope Related Documents 2 2 Media Access Control Priority based bus access arbitration compulsory immediate Framing compulsory immediate Link layer acknowledgement compulsory immediate Link layer communication error detection compulsory immediate Link layer communication error signaling system specific Fault confinement compulsory immediate 3 3 Logical Link Control Frame format compulsory immediate Link layer communication error reporting optional enhancement Network interface error detection and reporting optional enhancement Addressing system compulsory immediate Message types compulsory immediate Bus access timing manager compulsory immediate Message acceptance filtering system specific Link layer flow control compulsory immediate Link layer re-transmission on error compulsory immediate Remote frame request compulsory immediate Transport Layer functions 6 4 References 7 Distribution list 9 Rev. 1 Page iii

4 This page is intentionally blank Rev. 1 Page iv

5 1 Introduction 1.1 Scope The aim of the MilCAN B specification is to define and ratify an open standard interface to the CAN databus technology that supports implementation in all military vehicle application areas, where the performance requirements of specific implementations are commensurate with that of CANbus. To this end, the Basic MilCAN B Interface is intended to provide an initial interconnect specification that can be used in the near term by system and equipment developers, whilst being compatible with the additional elements that will be included in the full MilCAN B specification. As with all such initiatives, MilCAN B will be subject to change to keep pace with experience and technical advances. MilCAN B is compatible with CANopen and will define a specification for the superimposition of the MilCAN B communication architecture on top of CANopen, using a system developed by BOFORS Defence as the foundation. This specification will include CANopen device profiles for military devices using MilCAN B messages based upon MilCAN A. MilCAN B is intended to be easily bridgeable to other CAN based protocols, specifically MilCAN A, SAE J1939 and CANopen. Indeed, it should be possible to mix CANopen devices with MilCAN B devices on the same bus. J1939 devices must be segmented via a bridge. The philosophy of this document is to make reference to ISO11898, see ref 2, wherever possible, detailing only the specific deviations or additions required for MilCAN B to satisfy the requirements of its military vehicle application. Also, the software elements of the data link layer, those elements outside the jurisdiction of the ISO11898 standard, are based on the CANopen specification. The structure of this document follows the structure of the MilCAN A specification. The consequence of this is that some paragraphs will no longer contain any information. At this stage MilCAN B can only be an advisory document, beginning the process of guiding the military equipment community in the same direction. To this end each requirement has a classification marked against it; these are defined as follows: Compulsory: Compulsory in the long term, to gain accreditation as MilCAN B compliant, but in the near term may be considered as part of a migration path towards compliance. Rev. 1 Page 1 of 9

6 Compulsory immediate: Compulsory now, to facilitate fundamental interconnect compatibility between MilCAN B devices. Optional enhancement: Optional enhancement upon the basic MilCAN B interface, which need not be implemented if not required. However if implemented, the implementation should follow the MilCAN B specification. System specific: System specific item that is not constrained by MilCAN B and is left to the system developer to optimise for any specific system. However MilCAN B preferred practice may be presented as an option. 1.2 Related Documents This document should be read in conjunction with the following documents Basic MilCAN B Physical Layer Specification IHSDB-APP-GEN-D-033 Basic MilCAN B Application Layer Specification IHSDB-APP-GEN-D-035 Rev. 1 Page 2 of 9

7 2 Media Access Control 2.1 Priority based bus access arbitration compulsory immediate As ISO Framing compulsory immediate As ISO11898, 11bit identifier format, and CAN Specification 2.0 Part B Passive. 2.3 Link layer acknowledgement compulsory immediate As ISO11898 Acknowledgement of message receipt is not necessary at link layer level because any disruption of a message will be detected by the transmitting device (with a very high degree of probability as specified in the Bosch CAN specification, see ref 4. Therefore it can be assumed that if the receiving device(s) is operating correctly then it will have received the message 2.4 Link layer communication error detection compulsory immediate As ISO Link layer communication error signaling system specific Reporting of link layer communication errors from the CAN controller IC is optional and device/system specific. Corrective procedures appropriate for the system application may then be executed by the device application software 2.6 Fault confinement compulsory immediate As ISO11898 Rev. 1 Page 3 of 9

8 3 Logical Link Control 3.1 Frame format compulsory immediate As for CANopen 11 bit frame identifier, see Ref Link layer communication error reporting optional enhancement As specified in Ref Network interface error detection and reporting optional enhancement As specified in Ref Addressing system compulsory immediate MilCAN B is optimised for logical/function-based addressing for operational messages. Logical addressing is based solely on the function type conveyed in the message identifier. 3.5 Message types compulsory immediate Sync message compulsory immediate The transmission of messages by synchronous devices is coordinated by the sync message as described in the application layer specification. It is transmitted by the sync generator device, of which there is only one per bus segment. The sync message is a special status/command message, with a unique function type identifier as in CANopen, see Ref 5. The data payload of the sync message carries the sync counter, that repeatedly cycles and is incremented for every sync message. Octet 0 of the sync message payload carries the least significant byte of the sync counter and octet 1 carries the most significant byte. The trigger frequency of the sync message is system specific. The default tolerance of the sync period trigger timing should be +/-1%. Rev. 1 Page 4 of 9

9 3.6 Bus access timing manager compulsory immediate Devices operating synchronous to the bus Synchronous devices should incorporate a mechanism that reports the arrival of sync messages and the value of the sync counter to higher layers within the device. Synchronous devices that are capable of operating as sync generator should incorporate a mechanism that triggers the generation of sync messages for transmission onto the bus and signals successful transmission to the upper layers within the device. The operation of the synchronous message trigger system is described in the application layer specification Devices operating asynchronous to the bus Devices are not allowed to operate asynchronous on the bus, except emergency messages. 3.7 Message acceptance filtering system specific Devices should utilise message acceptance filtering wherever possible to reduce the load on the device processor. 3.8 Link layer flow control compulsory immediate The overload frame of the ISO11898 CAN standard should never be invoked by the LLC sub-layer of a device s CAN controller. CAN controllers should be selected such that they can accommodate the maximum level of bus activity. 3.9 Link layer re-transmission on error compulsory immediate The LLC sub-layer of the ISO11898 CAN standard includes amongst its functions the retransmission of frames that have been disrupted by errors during transmission. This process can result in an unpredictable number of retransmissions of the same frame in the event of errors. Some CAN controllers provide a facility to disable retransmission of frames in the event of errors. It is recommended that this facility is utilised wherever possible, relying on the device s upper layers to invoke appropriate corrective procedures Remote frame request compulsory immediate This function of the ISO11898 CAN standard is not to be used. Rev. 1 Page 5 of 9

10 3.11 Transport Layer functions Multi-frame messages-system specific Defined by the system designer Transparent data streams Not defined in Basic MilCAN B Rev. 1 Page 6 of 9

11 4 References 1. CUP protocol (Message Handling + Interface definitions), WTD41 Coblenz, Germany, April 2000, Doc. No.: ISO Road vehicles Interchange of digital information Controller area network (CAN) for high-speed communication, First Edition 1993 (Amended 1995), International Organisation for Standardisation, Geneva, Switzerland, ISO, ISO 11898:1993(E) 3. Data Link Layer SAE J1939/21, 1994, Society of Automotive Engineers, Warrendale, USA, SAE, J1939/21 4. CAN Specification, Version 2.0, 1991, Bosch GmbH, R, Stuttgart, Germany 5. CAN OPEN Communication Profile, CIA DS-301 V. 3.0, October Rev. 1 Page 7 of 9

12 List of abbreviations CUP BWB CAN SAE ISO EM CAN Utilities Protocol Bundesamt für Wehrtechnik und Beschaffung Controller Area Network Soceity of Automotive Engineers International Standards Organisation Electromagnetic Rev. 1 Page 8 of 9

13 Distribution list Name M Green D Carlson M Paul H J Maas A Köller S Majoewsky R M Connor R Chesney T Sundelin R Sembtner C Davies B Andersson J C P Bol T White D Barclay Company Alvis Vehicles Ltd, UK Bofors Defence, Sweden BWB WTD41, Germany BWB, Germany CCI Gmbh, Gemany Delco Defence, USA DERA, UK DRES, Canada Hägglunds Vehicle, Sweden Moog GmbH, Germany RadstoneTechnology, UK Saab Tech Vetronics TNO-FEL, Netherlands Ultra Electronics, UK Vickers Defence Systems, UK Rev. 1 Page 9 of 9

14 This page is intentionally blank

MilCAN A. Data Link Layer Specification IHSDB-APP-GEN-D-031. Revision 4

MilCAN A. Data Link Layer Specification IHSDB-APP-GEN-D-031. Revision 4 MilCAN A Data Link Layer Specification IHSDB-APP-GEN-D-031 Revision 4 Cover + viii + 19 pages March 2003 This document may be downloaded from http://www.milcan.org Rev. 4 To request clarification of any