Basic MilCAN Specification System Management Layer · to participate in the sync election process and other modules require knowledge of the sync period to detect the loss of sync

CANbus Working Group

Doc No. IHSDB-APP-GEN-D-036Rev. 1

System MSp

IHSDB-

R

C

This docum

htt

MilCAN A

anagement Layerecification

APP-GEN-D-036

evision 1

3

s

ent

p:/

May 200

over + vi + 13 page

Date: May 2003

may be downloaded from

/www.milcan.org

http://www.milcan.org/


Doc Rev.

To request clarification of any information contained in this specification or toreport any errors please contact:

Robert ChesneyDefence R&D Canada – SuffieldBox 4000Medicine Hat, ABCANADA T1B 3C1

Tel: +1 403 544 4764Fax: +1 403 544 4704

[email protected]

No. IHSDB-APP-GEN-D-036 Date: May 2003 1 Page ii


Doc No. IHSDB-APP-GEN-D-036 Date: May 2003Rev. 1 Page iii

Record of changes

Issue Date Detail of Changes

1.0 First Issue


Doc No. IHSDB-APP-GEN-D-036 Date: May 2003Rev. 1 Page iv

List of contents

Record of changes iii

List of contents iv

List of Figures vi

List of Tables vii

1 Introduction 11.1 Related documents 1

2 System Startup 22.1 Sync Timing 22.2 SyncPeriod – Optional Enhancement 2

3 Module Query and Dynamic Address Assignment 33.1 ReqModuleInfo – Optional Enhancement 43.2 ReplyModuleInfo – Optional Enhancement 53.3 UpdateAddress – Optional Enhancement 53.4 ReqModuleConfig – Optional Enhancement 63.5 ReplyModuleConfig – Optional Enhancement 6

4 Parameter Mapping – Optional Enhancement 74.1 MsgTiming – Optional Enhancement 84.2 ParamAssoc – Optional Enhancement 94.3 ParamDefine – Optional Enhancement 94.4 ParamDefineLong – Optional Enhancement 9

5 Reading Module Parameters 105.1 EnqParam – Optional Enhancement 105.2 ReplyParam – Optional Enhancement 105.3 ReplyParamLong – Optional Enhancement 11

6 Error Behaviour 11


Doc No. IHSDB-APP-GEN-D-036 Date: May 2003Rev. 1 Page v

6.1 ConfigError – Optional Enhancement 12


Doc No. IHSDB-APP-GEN-D-036 Date: May 2003Rev. 1 Page vi

List of Figures

Figure 1: Timing for configuration poll with no address conflict 4Figure 2: Timing for configuration poll with address conflict 4


Doc No. IHSDB-APP-GEN-D-036 Date: May 2003Rev. 1 Page vii

List of Tables

Table 1: SyncPeriod Message Definition 2Table 2: ReqModuleInfo Message Definition 4Table 3: ReplyModuleInfo Message Definition 5Table 4: UpdateAddress Message Definition 6Table 5: ReqModuleConfig Message Definition 6Table 6: ReplyModuleConfig Message 6Table 7: Example Parameter List (Navigation System) 7Table 8: MsgTiming Message Definition 8Table 9: ParamAssoc Message Definition 9Table 10: ParamDefine Message Definition 9Table 11: ParamDefineLong Message Definition 10Table 12: EnqParam Message Definition 10Table 13: ReplyParam Message Definition 11Table 14: ReplyParamLong Message Definition 11Table 15: ConfigError Message Definition 12


Doc No. IHSDB-APP-GEN-D-036 Date: May 2003Rev. 1 Page viii

This page is intentionally blank


Doc No. IHSDB-APP-GEN-D-036 Date: May 2003Rev. 1 Page 1 of 13

1 Introduction

This specification expands upon the network behaviour expected in a MilCAN network;including the modes of operation, options for ordered start sequences, and defines theoptional system management functions that can be implemented.

System management (or configuration) messages are included to provide astandardised method for the system integrator to query and alter the state of themodules installed in the system. They may be used “offline” with a MilCAN moduleconnected to diagnostic equipment, or they may be used “online” with diagnosticequipment added to an installed network. They may also be used through diagnosticfunctionality built into a module on an installed network.

System management functions addressed include:a. address conflict detection and dynamic address re-assignment for modules added

to a network;b. defining associations between parameters (produced or consumed by a node on

the network) and the message identifiers that contains those parameters; and,c. configuring a module that has non-volatile configuration parameters that affect the

behaviour of the unit (for example: threshold limits, etc).

Configuration messages are only valid and shall only be acted upon by modules whenthe module or network has been placed in configuration mode. The messages to place amodule, or network, in configuration mode are described in the application layerspecification. All configuration messages are transmitted with the priority field set tozero, however, this will not affect system operation in configuration mode.No specific capability is provided to prevent malicious or unintentional alterations ofsystem behaviour while in configuration mode. Where this is considered an issue, themodule designer must incorporate appropriate authorisation checks. This can readily beimplemented utilising the messages defined within this specification, however, theprecise manner of implementation is left to the discretion of the module designer.

1.1 Related documents

This document should be read in conjunction with the following documents• MilCAN A Physical Layer Specification – IHSDB-APP-GEN-D-030• MilCAN A Data Link Layer Specification – IHSDB-APP-GEN-D-031• MilCAN A Application Layer Specification – IHSDB-APP-GEN-D-032



2 System Startup

MilCAN modules have three modes of operation while powered on, as follows:• pre-operational;• operational, and;• configuration.

Details of the operational modes and the start up sequence are provided in theapplication layer specification.

It should be noted that MilCAN start-up behaviour is expected to be very rapid. In normaloperation, the first node capable of generating sync frames (a potential sync master)should commence issuing sync frames as soon as it completes its power up sequenceand detects that no other sync generator is present. This will trigger all other readynodes to go to their operational state. As any remaining nodes complete their power upsequence they will transition directly to the operational state as they see sync frames.Potential sync masters that power up later than the original sync master will participatein the sync master election process and either assume the role of sync master or merelytransition to operational mode.

2.1 Sync Timing

MilCAN is a deterministic protocol with many, if not all, of the messages synchronised tothe arrival of a sync message. All modules must be aware of the sync interval chosen bythe system designer at integration time. Potential sync masters require the sync periodto participate in the sync election process and other modules require knowledge of thesync period to detect the loss of sync on the network. A system management messageis defined to adjust the sync period for modules that implement system managementfunctionality.

2.2 SyncPeriod – Optional Enhancement

The SyncPeriod message contains a parameter to define the sync period that allmodules on the network should use. This message is a broadcast message, valid only inconfiguration mode. The parameter specifies the nominal time between sync frames inmicroseconds. The sync period for the module must be stored in non-volatile memory toallow the module to operate correctly on power-up.

Primary-Type: 0x32 Sub-Type: 0x00 Prio: 0x0Byte Bits Content

0 - sync time, lower order byte of 16 bit unsigned int (microseconds)1 - sync time, higher order byte of 16 bit unsigned int (microseconds)

Table 1: SyncPeriod Message Definition



3 Module Query and Dynamic Address Assignment

The module query mechanism is intended to be invoked only in instances where thesystem has been subjected to maintenance and one or more modules have beenreplaced. The query mechanism is designed to cope with instances in which areplacement module has been installed that is improperly configured for the vehicle it isnow installed within, or where it is being reconfigured to operate in a different vehicle.

Module replacement can result in a number of issues, not all of which can be addressedby the system management functions alone. The most notable of these issues is thecase where several identical modules are installed in a vehicle which control functionsthat have an association with the position the module is installed in. An example of thismight be a light control module. The system management functionality included canresolve address conflicts; however it can not identify where a module is physicallyinstalled. This will need to be addressed by the system designer in another manner,either through a location specific input that the module can monitor or through aninteraction sequence with the operator during configuration.

Address conflict is resolved through the configuration controller polling all possibleaddresses in the system in sequence. Modules with the address being polled reply witha module configuration parameter. The reply is issued after a pseudo-random delayduring which the module being polled monitors the bus for other modules responding tothe same poll. If a module detects another module replying to the same address itdelays for ten milliseconds to allow the configuration controller an opportunity to changethe address of the unit that responded first. It then restarts the delay sequence andtransmits its configuration string. This sequence continues until no module hasresponded for more than the maximum delay for the random response and for theaddress change. To ensure that module addresses can be changed for only the desiredmodule, address change commands are only honoured for a short period of time directlyfollowing successful transmission of a modules configuration parameter. The sequencewhere one module replies is illustrated in Figure 1. The sequence where two modulesreply is illustrated in Figure 2.



Figure 1: Timing for configuration poll with no address conflict

Two request / reply message sets are defined; one to request hardware identificationand a second to request a software configuration. Address conflict detection isassociated with only the first, hardware identification, request sequence.

Figure 2: Timing for configuration poll with address conflictWhile MilCAN is a broadcast protocol, device addresses play a role in distinguishingmessage headers when two (or more) devices transmit the same message. They arealso required to support the remainder of the system management functions. Addressassignment is at the discretion of the system integrator, however, it is recommendedthat address 255 (0xFF) be reserved for configuration tools.

3.1 ReqModuleInfo – Optional Enhancement

This message is transmitted twice, once to request the information and a second time tosynchronise the reply. After transmission of the second message the configurationcontroller should listen for replies for a minimum of 50 mS. In the event that more thanone reply is received, the monitoring time should be extended by 30 mS for eachadditional reply received.


0 - address of module required to act on message

Table 2: ReqModuleInfo Message Definition



3.2 ReplyModuleInfo – Optional Enhancement

Message payload includes a five byte module identifier field. The first component is avendor identification field. The vendor identification field is chosen by the vendor toidentify all of the modules that it produces. The field is registered with the MilCANorganisation (ref: http://www.milcan.org) to ensure the each vendor ID is unique. Thesecond component is a module identifier assigned by the vendor. The last component isa module hardware revision identifier assigned by the vendor.


0 - vendor identification lower order byte, 16 bit unsigned integer1 - vendor identification higher order byte2 - vendor assigned hardware ID lower order byte3 - vendor assigned hardware ID higher order byte4 - vendor assigned hardware revision level

Table 3: ReplyModuleInfo Message DefinitionThe timing of this response message is managed to allow detection of address conflicts.As illustrated in Figure 1, the ReplyModuleInfo message should be generated after apseudo-random delay from the receipt of the second ReqModuleInfo message. Thedelay should have a range of 0 to 20 mS. During the delay the module should monitorthe bus for a response by another module. In the event that another module is detectedresponding to the address poll, the module must await completion of the messagegenerated by the other module, generate another random delay and transmit itsidentification string when the delay timer lapses. In this instance the delay range shouldbe within the range of 10 to 30 mS. The minimum delay of 10 mS gives the configurationcontroller an opportunity to change the address of a module replying unexpectedly to anaddress. In the event that yet another module responds during the delay the moduleshould repeat the sequence until it is able to transmit its module identifier string. Delaytimes must be effectively random to ensure that multiple modules with the samesoftware can be distinguished.

The configuration controller must keep track of replies and immediately initiate anaddress change sequence for any modules that reply unexpectedly at a given address.

A module that detects an address conflict during the configuration poll must receive anUpdateAddress message within 10 mS of transmitting its ReplyModuleInfo message, orit will retain its original address.

It is recognised that some module implementations may not be able to monitor bustraffic with sufficient resolution to prevent issuing a reply when the delay times of two(ormore) modules are very similar. The configuration controller must monitor for the receiptof multiple configuration replies in this instance. If multiple configuration replies aredetected, the configuration controller should re-attempt the address poll once itsmonitoring period has completed.

3.3 UpdateAddress – Optional Enhancement



The UpdateAddress message provides a mechanism for the configuration controller tochange the address of a module during initial configuration or after detecting an addressconflict. To ensure that only one module acts on the command, the command is onlyvalid for 10 mS following the transmission of a ReplyModuleInfo message by themodule. This command has immediate effect.

The address should be stored in non-volatile memory.

Primary-Type: 0x32 Sub-Type 0x03 Prio: 0x0Byte Bits Content

0 - address of module required to act on message1 - new address for module

Table 4: UpdateAddress Message Definition3.4 ReqModuleConfig – Optional Enhancement

The ReqModuleConfig message is issued by the configuration controller to request areply detailing the software configuration of the module being addressed.


0 - address of module required to act on message

Table 5: ReqModuleConfig Message Definition3.5 ReplyModuleConfig – Optional Enhancement

Message includes two fields; one to reflect the software revision level and one to reflectthe current non-volatile parameter configuration.


0 - software revision, year of issue, lower order byte of 16 bit unsigned int1 - software revision, year of issue, higher order byte2 - software revision, day of issue, lower order byte of 16 bit (range 1-366)3 - software revision, day of issue, higher order byte4 - CRC code for non-volatile memory area of module (LSB of 32 bit int)5 - CRC code for non-volatile memory area of module6 - CRC code for non-volatile memory area of module7 - CRC code for non-volatile memory area of module (MSB)

Table 6: ReplyModuleConfig MessageIt should be noted that the CRC code used to “summarise” the current state of the non-volatile memory area may not be unique in all cases. In such instances the systemintegrator may wish to insert a dummy parameter to alter the CRC generated, or usesome other method to distinguish configurations.



4 Parameter Mapping – Optional Enhancement

An important component of the system management functionality is to allow the systemintegrator to assign parameters to messages based upon the most efficient design for aparticular vehicle. The system management messages are based on the use of aparameter list for each module that describes:

i) the input parameters that the module can react to or interpret;ii) the output parameters that the module can generate; and,iii) the configuration parameters that can be modified to alter the behaviour of themodule.

A parameter list is essentially a data sheet for the module, describing the parameters,the data length and interpretation associated with the parameters, and constraints uponthe use of the parameters (such as maximum, meaningful data rates, or the like). Anexample parameter list is included as Table 7. It should be noted that an actualparameter list would need to contain definitive descriptions of the parameters range,scaling and potential error values in the manner of any interface control document.

Index ParameterDescription

Type DataLength

MaxCyclic

Remarks

1 heading (format 1) out 16 bit 100 Hz range, scaling, etc2 heading (format 2) out 24 bit 100 Hz3 roll (format 1) out 16 bit 100 Hz4 roll (format 2) out 24 bit 100 Hz5 pitch (format 1) out 16 bit 100 Hz6 pitch (format 2) out 24 bit 100 Hz7 magnetometer x in 16 bit range, scaling, etc8 magnetometer y in 16 bit9 magnetometer z in 16 bit

10 roll alarm out 2 bit event11 Roll alarm

thresholdvalue 16 bit

Table 7: Example Parameter List (Navigation System)Parameters can be multiply defined. For example a sensed input, such as a pressurevalue might have several parameter listings based on multiple output scalings or unitssystems. This would allow the same module to be employed in several systems despitediffering conventions on units, limits and ranges of parameters.

The parameter mapping system management messages provide for a mechanism tochange the association between parameters that a module reads from, or writes to thebus, and the messages that carry the data. By using parameter mapping, the systemintegrator can define an efficient message set, unique to a particular application, whileusing standard modules. The system management messages defined herein, provide astandardised method to establish or alter the parameter association for a module toallow it to operate in differing applications.



In a broadcast network there will be instances that a module will not need to read allelements of a message. Further, to cope with legacy systems, there may be instanceswhere a module must transmit a message that is padded to make parameters appear atthe correct position in the message. Such a message will have no data in certainpositions of the message. Wherever an association is not explicitly made the moduleshould treat the message contents as a “don’t care”. When a message is formed foroutput, all elements of the message that are not explicitly specified should default to apattern of ones.

Module parameters that are identified in the module parameter list may also be alteredthrough system management messages. Two messages are defined to facilitate thesechanges; one for parameters that are five bytes or less in length, and a second (multi-frame message) for parameters that are longer or which are of variable length.

4.1 MsgTiming – Optional Enhancement

The message timing command sets all aspects of the timing for the generation of amessage. It shall be issued by the configuration manager for all messages that amodule is expected to process, either as inputs or outputs. Modules may discard timingdata for input messages, or may use the timing data to implement error checkingbehaviour, if desired. The MsgTiming message must precede any other message thatmake parameter associations to the referenced message ID.


0 - address of module required to act on message1 - primary ID of message being defined2 - secondary ID of message being defined

0-2 priority of message being defined3 input / output flag (message is input if flag is 1)4 sync / async flag (message is synchronous if flag is 1)5 multi-frame message flag (multi-frame if flag is 1)6 multi-instance message flag (multi-instance if flag is 1)

3

7 Reserved4 - bits 0-7 of async lockout (minimum async msg interval)

0,1 bits 8,9 of async lockout2,3 Reserved

5

4-7 sync divisor (expressed as a power of 2 – range is 0-10, resulting in async divisor of between 1 and 1024)

6 - bits 0-7 of sync offset0,1 bits 8,9 of sync offset2,3 Reserved

7

4-7 payload length for message being defined – range is 0-8

Table 8: MsgTiming Message DefinitionSome elements of the message will only have meaning for either synchronous orasynchronous messages, however the entire message should still be sent. Where



message fragments are either reserved, or are not relevant to the interpretation of themessage they shall be sent as a pattern of “ones”.

4.2 ParamAssoc – Optional Enhancement

Once a message identifier has been established at a module through the MsgTimingcommand, a sequence of ParamAssoc messages can be sent to the module to definehow module parameters should be associated with that message. Parameter length isdefined by the parameter list specification.Primary-Type: 0x32 Sub-Type: 0x07 Prio: 0x0Byte Bits Content

0 - address of module required to act on message1 - primary ID of message being defined2 - Secondary ID of message being defined3 - Parameter index, lower order byte of 16 bit unsigned int4 - Parameter index, higher order byte of 16 bit unsigned int5 0-2 start byte for parameter location

3-5 start bit for parameter location6,7 Reserved

Table 9: ParamAssoc Message Definition

As for other messages reserved bits should be transmitted as ones.

4.3 ParamDefine – Optional Enhancement

The ParamDefine message is used to update values for parameters that are defined inthe parameter list. This message supports parameters that are 5 bytes in length or less,i.e. those that may be passed in a single frame.

The module behaviour with regard to when the parameter update is committed to non-volatile memory is not specified.


0 - address of module required to act on message1 - parameter index, lower order byte of 16 bit unsigned int2 - parameter index, higher order byte of 16 bit unsigned int

3-n - parameter data. Data length is determined by the data size specified inthe parameter list. Data is to be transmitted using a least significantbyte first order. Data elements of less than one byte should betransmitted in the least significant bits of the byte.

Table 10: ParamDefine Message Definition4.4 ParamDefineLong – Optional Enhancement

The ParamDefineLong message is used to update values for parameters that aredefined in the parameter list. This message supports parameters that are more than 5bytes in length or which are of variable length (for example, strings). The message



structure and sequencing is based on the multi-frame message defined in the data linklayer.

The module behaviour with regard to when the parameter update is committed to non-volatile memory is not specified.


0 - address of module required to act on message1 - parameter index, lower order byte of 16 bit unsigned int2 - parameter index, higher order byte of 16 bit unsigned int3 - frame index (0 to start sequence, 1 through 249 – wrapping to 1 during

sequence, 250 for last frame – data length code determines length oflast frame). Note: a data length code of less than 8, occurring in frameindex 0 may occur for short sequences of variable length data. In thisinstance, only the single message will be sent.

4-n - parameter data. Data is to be transmitted using a least significant bytefirst order.

Table 11: ParamDefineLong Message Definition

5 Reading Module Parameters

In addition to the messages defined to configure the parameters within a module, threeadditional messages are defined to allow parameters to be read from the module todetermine the detailed module configuration, if required. These messages are intendedto provide a mechanism to read configuration values (static non-volatile configurationdata); their behaviour when the referenced parameter is an input or an output parameteris not defined and is at the discretion of the module designer.

5.1 EnqParam – Optional Enhancement

The EnqParam command requests a reply with a subsequent message. The reply maytake the form of a ReplyParam or ReplyParamLong message depending on the lengthof the parameters data. ReplyParamLong responses will be used for variable lengthparameters or parameters that are greater than 6 bytes in length.

Primary-Type: 0x32 Sub-Type: 0x0A Prio: 0x0Byte Bits Content

0 - address of module required to act on message1 - parameter index, lower order byte of 16 bit unsigned int2 - parameter index, higher order byte of 16 bit unsigned int

Table 12: EnqParam Message Definition5.2 ReplyParam – Optional Enhancement



The ReplyParam Message is generated by a module in response to a request by theconfiguration controller. It is used to reply when the data length of the parameterrequested is 6 bytes or less.

Primary-Type: 0x32 Sub-Type: 0x0B Prio: 0x0Byte Bits Content

0 - parameter index, lower order byte of 16 bit unsigned int1 - parameter index, higher order byte of 16 bit unsigned int

2-n - parameter data. Data is to be transmitted using a least significant bytefirst order. Data elements of less than one byte should be transmittedin the least significant bits of the byte.

Table 13: ReplyParam Message Definition

5.3 ReplyParamLong – Optional Enhancement

The ReplyParamLong Message is generated by a module in response to a request bythe configuration controller. It is used to reply when the data length of the parameterrequested is longer than 6 bytes or is variable in length.

Primary-Type: 0x32 Sub-Type: 0x0C Prio: 0x0Byte Bits Content

0 - parameter index, lower order byte of 16 bit unsigned int1 - parameter index, higher order byte of 16 bit unsigned int2 - frame index (0 to start sequence, 1 through 249 – wrapping to 1 during

sequence, 250 for last frame – data length code determines length oflast frame). Note: a data length code of less than 8, occurring in frameindex 0 may occur for short sequences of variable length data. In thisinstance, only the single message will be sent.

3-n - parameter data. Data is to be transmitted using a least significant bytefirst order.

Table 14: ReplyParamLong Message Definition

6 Error Behaviour

System management and configuration messages are expected to be well defined bythe system integrator prior to use. However, there may remain instances in which asystem management message is issued that is inappropriate for the module beingaddressed. Some method of signalling an error is required to allow detection of thisevent. A ConfigError message is defined to allow modules to reply to commands forwhich the command is in appropriate or outside the capabilities of the modules.Examples of this might include command to map or define non-existent parameters, orto generate output data streams at higher rates than can be generated by the module.

No payload is defined for this message within the MilCAN protocol, however, moduledevelopers may chose to add payloads to define the specific error. Such payloads would



be module specific and would have to be interpreted in the context of the moduleidentifier string.

6.1 ConfigError – Optional Enhancement

Primary-Type: 0x32 Sub-Type: 0x0D Prio: 0x0Byte Bits Content0-7 - Optional module specific payload

Table 15: ConfigError Message Definition



This page is intentionally blank

Documents

Basic MilCAN Specification System Management Layer · to participate in the sync election process and other modules require knowledge of the sync period to detect the loss of sync