CAN in Automation (CiA)
headquarters@can.cia.org
www.can-cia.org
Switch to the CAN products section CAN and J1939 Product Guide 2011 J1939 product section CAN and J1939 Product Guide 2011
home
Industry groups Product categories Company names Product names

The MilCAN set of profiles for military vehicles

MilCAN (www.milcan.org) is the name given to a set of open standard interfaces, based on CAN. It will facilitate the interconnection of subsystems within military vehicles. MilCAN protocols are derived from the CUP protocol developed by the German Bundeswehr, SAE J1939, and CANopen. Two variants are defined: MilCAN A and MilCAN B. MilCAN A is based on the 29-bit CAN identifier and has many similarities with SAE J1939, the major difference being that MilCAN A has provision for deterministic data transfer and can accommodate both synchronous and asynchronous data. MilCAN B, on the other hand, is based on the 11-bit CAN identifier and has the ability to make use of devices that have been designed for CANopen. MilCAN B specifically excludes the use of asynchronous PDOs. The MilCAN specification is comprised of three documents for each variant: The physical layer specification, the data link layer specification and the application layer specification. The philosophy of MilCAN is to make reference to ISO 11898-1 wherever possible, detailing only the specific deviations or additions required for the protocol to satisfy the requirements of its military vehicle application. Meanwhile the NATO Military Agency for Standardisation (MAS) has ratified CANopen (EN 50325-4) and SAE J1939 as higher-layer protocols in a STANAG (Standards Agreement). It should be possible to mix J1939 devices with MilCAN devices on the same bus. CANopen devices must be segmented via a bridge, but the intention is that MilCAN define a specification that includes CANopen device profiles using the same MilCAN messages.

Physical layer

MilCAN recommends that CAN signals are opto-isolated and that these be driven from an isolated supply. The wide range of both transient and steady state voltage levels that must be tolerated within a military vehicle mean that power supplies are often both complex and expensive. MilCAN recognizes this system-wide cost issue, and goes beyond ISO 11898-2 in supporting the concept of an in-cable power supply in order to efficiently provide power to remote node transceivers from a central supply. This potential to carry power means that although the MilCAN physical layer simply recommends a connector type, gender assignment becomes very important. Thus, regardless of the network topology, any connector that may constitute a power source must be female.

Lower-layer protocols

MilCAN A uses only the 29-bit, extended, identifier format defined in ISO 11898-1. As in any CAN network, data is broadcast, and bits 0 to 7 of the identifier include the physical address of the device that actually transmits a frame, rather than a destination address. This enables multiple remote nodes to determine where a message originated and distinguish between similar messages from different devices. The MilCAN A protocol also defines message type and a priority level using bits 26-28 of the frame identifier in order to allow the application layer the ability to allocate priorities on a message specific basis as part of a latency guarantee within the deterministic message transmission protocol.

If a message's data payload exceeds eight bytes then it will have to be distributed across more than one CAN data frame which, depending upon the nature of the data, can be handled in one of two ways. In order to guarantee delivery performance, time-critical or safety-critical data will normally be transmitted as a group of single frame messages each with unique function identifiers. If, however, the data is not critical, then it can be transmitted by means of a number of linked data frames. This is termed a multi-frame message. A dedicated handler is required in order to manage individual frames within a multi-frame message and issue them to the data link layer. The mechanism makes use of the normal frame format but uses the first data byte of the payload to pass a code used to guarantee the chronology of the data. At the start of a multi-frame message this is set to 0, incrementing up to 249 with each succeeding frame. At 249 the leading data byte value rolls over to 1. A value of 250 is reserved to indicate the end of a multi-frame message regardless of the number of individual frames. Because of this encoding scheme a maximum, of seven data bytes can be transmitted per frame.

MilCAN A does not require frame acknowledgement. That determination is left up to the message's application layer specification. The frame counter is restricted to the range 0 to 250 in order to maintain the convention established in J1939 whereby values above 250 are reserved for special purposes.

Higher-layer protocols

The MilCAN A application layer adopts a segmented message assignment scheme and flexible deterministic protocol in order to accommodate both vehicle- and application-dependent changes.

Bits 28-26 of the 29-bit CAN identifier define the priority of an individual message and therefore the priority of the associated data frame. Bits 23-16 define the 256 message primary types and bits 15-8 the 256 message sub-types for each primary type.

Message primary type identifiers are assigned sequentially starting at zero and with a spare identifier between each assignment. Sub identifiers are also assigned sequentially starting at zero with a spare identifier in between each. Messages are grouped by means of their primary types e.g. navigation, power management, HMI (human machine device) devices, data acquisition etc.

Efficient message allocation is vital, but it is important to recognize that when the initial allocation is made, the number of physical instances of that function cannot be predicted. For example, consider a message designed to control a particular camera function. At the outset it is not known how many cameras will need to be supported, and indeed the number and location may vary from vehicle to vehicle. To support this requirement MilCAN A defines a multi-instance addressing scheme that is independent of message type.

If applicable to a particular system function message, then the MilCAN A physical instance element is carried within one byte of the data payload rather than the source address field.

MilCAN A provides a network data flow structure to accommodate real-time needs without requiring non-time-critical devices to incur the overhead of complicated time-slice transmission. Devices connected to a MilCAN A network will vary greatly in their capabilities, hence support for deterministic message transmission must be provided by both sophisticated and simple devices. MilCAN A uses a prioritized bus access with bounded throughput protocol. This supports determinism for those devices that require it while providing sufficient flexibility for those devices that do not.

Put simply, a number of time unit levels are defined; each has a particular latency guarantee and individual nodes are only allowed to transmit one message within their allocated period.

Assuming the largest possible data field (8 byte) the CAN protocol guarantees the delivery of 15 messages within each Primary Time Unit (PTU). In an extreme case this could equate to 15 Level 1 messages. In practice each PTU is more likely to support some level 1 messages with the remainder of the 15 slots being spare or made up of a combination lower priority Level 2, Level 3 or Level 4 messages.

This bus allocation method achieves a number of goals:

Military vetronic architectures are normally comprised of multiple distributed real-time sub-systems, and as a result the communication protocol employed must support both determinism and co-ordination. The protocol defines a Sync Generator Claim Message and its use as part of an arbitration process in order to elect a network sync generator. It is this Sync Generator, which broadcasts a Sync frame every PTU, in order to provide a means by which nodes can co-ordinate actions.
Resilience is prerequisite to any military communications architecture, and as a result, any node, which requires use of synchronization frames must also monitor the bus for their absence. If a node detects that the Sync message is late, either due to a Sync generator failure or because the network has just powered up, then that node must trigger the claim process in order to elect a new Sync generator. Once triggered the arbitrated claim process only requires two frames to be transmitted, the first is the winning transmission and the second signals loosing nodes to cancel their claim process. The new Sync generator immediately begins transmitting sync frames.

Back