Military Vetronics

The importance of networked tasks carried out on military vehicles anticipates real-time communication between devices, as well as operating lower-priority tasks on the same CANbus. Both sophisticated and simple devices are dynamically being integrated in the system. Critical tasks such as crewstation commands for vehicle control and non-critical tasks such as multimedia operations coincide on the same network. Separate CANbus segments are being used to accommodate devices of different operation nature, avoiding their direct interference with critical segments, and to allow the ability to incorporate more devices.

CAN is a 1Mbit (max) bus network, that allows prioritisation for the transmission of frames, but does not guarantee determinism which is vital for time-critical operations. To support redundancy, fault tolerance, and performance levels and QoS that are required by vetronic systems, MilCAN introduces a number of additions to CAN.

MilCAN

MilCAN is an open standard interface, based on CAN. It is developed by the MilCAN Working Group, spawned by the International High Speed Data Bus Users Group (IHSDB-UG) in 1998, to provide hard real-time capabilities for military environments as an open protocol. MilCAN defines two variants, MilCAN-A and MilCAN-B. MilCAN-A uses 29bit CAN identifiers and is based on SAE J1939 while adding deterministic functionality and supporting synchronous and asynchronous data transfers. MilCAN-B used 11bit identifiers and is compatible with CANopen. In contrast to MilCAN-A, MilCAN-B does not support asynchronous data transfers. From these two versions MilCAN-A is currently the one most commonly used in Military vehicles in the UK.

The MilCAN protocol consists of three parts, the Physical Layer, the Data Link Layer, and the Application Layer. The first specifies the electrical connectivity, the transceiver characteristics, and the transmission bit timings, while the Data Link Layer defines packet framing/types and bus access control. The Application Layer describes the network architecture, scheduling for deterministic communication, and reserved message assignments.

The protocol specification consists of mandatory requirements and optional features that have to be supported by a MilCAN device. This provides flexibility in the development of a MilCAN network by shaping it tighter around the specific application. As MilCAN is used on top of CAN networks without the need for hardware additions or alterations, it can be easily integrated into existing systems to add deterministic and scheduled operation.

A more technical view

As MilCAN is targeted for highly deterministic applications, like military Vetronics or time-critical industrial systems, its design recommendations are focused on fault-tolerance, redundancy, and fault-isolation. Operating on a bus architecture, a MilCAN network has to provide resilience as single node faults could disrupt the whole system bus.

Connection to the CAN bus is recommended to be opto-isolated with devices powered from an independent supply. As internal power feed of military vehicles is highly unstable, noisy, and fluctuating, power supplies for the electronics systems are very expensive. To minimise overall cost, MilCAN supports in-cable power transfer to feed the nodes from a central supply. The sharing of the same cabling of both data signals and power lines forces the assignment of a specific cabling system (both cables and connectors) in the specifications.

Network topologies are also recommended to provide interchangeable Line Replaceable Units by splitting the network into individual units. Two example topologies are shown in figures 1 (linear) and 2 (daisy chain). By segmenting the bus into stackable components, all the nodes remain fundamentally identical. By separating the bus terminators from the devices, future upgrades that require additional cabling do not need reorganisation of the existing network, and duplication of termination is avoided.

Frame format

The MilCAN-A frame format is based upon SAE J1939. It uses 29bit extended identifier format defined in the ISO 11898. Using a Protocol Type bit (bit #25) both J1939 and MilCAN can share the same bus.

As CAN is a broadcast network, MilCAN frame identifiers use bits 0-7 to embed within a message the address of the node that sent it. This Source Address enables more than one node to send the same message while allowing the destination node to identify the originator.

Utilising the arbitration mechanism of CAN, MilCAN reserves the last 3 bits of the identifier to be used for prioritised transmission. Allowing the application to control the operation of the network down to the transmission level is the basis of a deterministic message transmission protocol with guaranteed latencies.

A set of two 8-bit values is used to define the Main and Sub function of a frame. These are bit ranges 16-23 and 9-15 respectively. Some values are reserved by the MilCAN protocol for internal use [6], but the rest are application specific and are ignored by the protocol stack.

The limitation of CAN to a maximum of 8 bytes payload is overcome by either splitting the data to a range of messages, each with unique function identifiers, usually for time or safety critical data, or using a series of linked messages with the same function identifiers, called a multi-frame message. The later can be accomplished by reserving the first byte of the payload as a dedicated handler to pass a code that will indicate the chronology of the data. This allows a maximum of 7 bytes to be used for the data transfer. The handler of the multi-frame message is set to 0 for the first frame, incrementing up to 249 for each of the following. If more than 250 frames are required, the handler will roll over to 1. Regardless of the total number of frames used, the last one must have a value of 250 to indicate the end of the multi-frame message. Values above 250 are not used in order to maintain compatibility with the SAE J1939 that reserves higher values (251-255) for special purposes.

The MilCAN specification provides to the application a scheme of segmented message assignment, along with deterministic scheduling. The 29-bit identifier includes an 8-level Priority (bits 26-28), 256 primary message types (Main Function, bits 16-23), and 256 secondary message sub-types (Sub Function, bits 8-15). These fields are application specific, while the Source Address field (bits 0-7) are reserved and controlled by the MilCAN stack.

It is recommended that the primary and secondary message type identifiers be assigned sequentially starting at zero using even number identifiers, while leaving the odd ones as spares. Messages should be grouped based on their functionality in primary types e.g. Navigation, Power Management, MMI devices, Data acquisition, etc, while individual assignments should use a unique secondary type e.g. Engine #1 / Engine #2, Device Status / Device Control, etc. Using this structured approach it is made relatively simple to have coarse filtering, based on the primary type, or fine filtering, based on both primary and secondary type. In addition, new message types can spawn from current ones (class based inheritance) and be classified as secondary types while maintaining compatibility, or completely new ones added efficiently as primary types without interfering with the old ones.

Device Synchronization

MilCAN as a communication protocol supports both determinism and co-ordination, as required by military Vetronic architectures that are normally distributed real-time sub-systems. This is accomplished by defining a "sync generator claim message" used as part of an arbitration procedure that elects a network sync generator, the Sync Master. A Sync Master broadcasts a "Sync frame" every PTU to synchronize the transmission operations of the network nodes. This frame denotes the beginning of Sync Slot that is valid for one PTU. A collection of 1024 Sync Slots is considered a MilCAN Cycle. For node coordination, within a Sync Frame the Sync Slot number of the current MilCAN Cycle is stored in the first two bytes (0-1023).

To facilitate resilience and redundancy, the Sync Master ability is included into all the nodes of a segment that requires this synchronization. An "election procedure" assigns one of the available nodes as a valid Sync Master. Nodes that loose the election, thus becoming Sync Slaves, monitor the network for proper operation of the active Sync Master. In case of any type of failure that disrupts the Sync process to outside the specification limits, an election is triggered to re-elect a new Sync Master to recover the network. The same tactic is also used for the initial Sync Master election upon bus power up. During the election process all the nodes capable to become sync masters send a Sync message each on the bus. As they individually have unique node addresses, the one with the lowest numerical node address is considered to be the one with the highest priority to become Sync Master. Once detected the other nodes back off and the new Sync Master resumes from the previous Sync Slot.

Deterministic Message Transmission

MilCAN provides a network data flow structure for real-time operation without the overheads of a time-slice transmission scheduling. This makes it possible to have deterministic message transmission using both sophisticated and simple devices, with a prioritised bus access control and traffic shaping. The granularity of the system is defined by the Primary Time Unit (PTU) that for example a 2ms PTU can fit up to a maximum of 15 messages with 8 bytes payload.

To achieve this, MilCAN assigns a set of time unit levels each with a distinct maximum latency guarantee by allowing the nodes to send only one of these messages within their time period. The 8 priorities are divided to 4 groups, the Protocol Messages, the Hard Real Time (HRT), the Soft Real Time (SRT), and the Non Real Time (NRT). Protocol Messages are the highest priority that has to be transmitted immediately, like the Sync Frames. System critical messages where their timing and latency is important are classified as HRT. They are sub-divided into 3 levels with different maximum latencies counted in PTUs. A frame of a specific priority is guaranteed for transmission within that period. The same is applicable for the SRT group with the exception that the absolute latency is not critical. NRT messages do not have any timing constraints and are sent when bandwidth is available.