MilCAN
MilCANMilCAN is the name given to an open standard interface, based on CANbus technology, that will facilitate the interconnection of subsystems within military vehicles http://www.milcan.org/ .
The latest versions of the MilCan? A and MilCan? B Specifications are available for download at the MilCan? web site.
MilCAN A is designed to be directly compatable with J-1939 networks while MilCAN B is designed to be compatable with CANopen networks.
This is what John Dammeyer <johnd@autoartisans.com> says about MilCan? and determinism:
Because I've been porting MilCAN onto a processor I've now got a little bit of experience with that protocol. It adds a level of determinism to CAN by removing the asynchronous nature of multi-master or masterless system. Let me explain.
In MilCAN a master issues SyncFlags? with 16 bit SyncCounter? value that is incremented (and wraps at 1023). So each SyncFlag? describes a particular point in time. The suggestion for a 250kbps network is to run the SyncFlags? at 64Hz or one every 15 mS or so.
An extension to the basic MilCAN protocol has a set of Messages defined that can be automatically sent based on a power of two. So a message could be sent every SyncFlag? or every 2nd or every 4th or every 8th etc. To avoid having a burst of messages on these intervals the message timing is also structured with an offset into this power of two. So one message would be broadcast every 8 SyncFlags? plus 1 while a different message would be broadcast every 8 SyncFlags? plus 3 while a third message might be configured to broadcast every 16 syncFlags plus 2.
This means that within an acceptable jitter rate a message is promised to be sent within X microseconds after a SyncFlag? and no arbitration will occur because there aren't any other messages programmed to occur in the same slot.
However, MilCAN does allow Asynchronous messages with a minimum repeat interval. That means a message could be sent any old time but never more than every Y SyncFlags?. That prevents an Async message from hogging the bus but it still destroys the determinism built into the Synchronous message reporting. But, Async messages are optional. And because all the messages in an operational bus can be programmed to occur during particular SyncFrames one could state that the implementation is deterministic.
However you don't need CAN to do that sort of protocol. Where CAN works well in MilCAN is for determining who the master is during a discovery process or when a new node comes on line and has a higher priority and wants to be the master. And in a system where certain types of information aren't time sensitive, a number of messages could be programmed to be broadcast every 32 SyncFlags? plus 7. These messages would 'duke it out' with arbitration since they'd all try to send at the same time and we'd see a burst of messages following the SyncFlag?.
Again, the designer of the MilCAN system when deciding which message does what, has to make sure that no more than X messages are sent during any SyncFrame? interval to avoid running into the next SyncFrame?. The SyncFlag? has a really high priority so at worst it could be delayed by one message also causing unacceptable jitter. But there again CAN works well to arbitrate and send the maximum number of messages (100% bus load) during the SyncFrame?.
Now what about error flags and message retries you might ask. The MilCAN spec states that retries aren't allowed although most CAN devices cannot turn that feature off. At the moment that restricts it to a very small number of CAN devices and IMHO, no longer makes it truly a CAN network. But it's the only way to prevent a naughty node with a defective driver chip from bursting the bus with retries. Probably a good thing if the instruction in the message is to fire a machine gun. ;-)
John Dammeyer
John is discussing a hardware requirement, to be able to stop automatic retransmission of a failed CAN message transmission (which is normally a desired feature of standard CAN controllers), either by hardware (supported by the CAN controller or an external switch for the TX pin) or by software (manually stopping the pending TX message following an error).
Development support