3

   

Structuring of MSRNET DTD

The description of a CAN network is made up of the following parts:
  •  
  •  

    Long and short name of the instance (<long-name> <short-name>)

  •  
  •  

    Project information <project-data>

  •  
  •  

    Administration information <admin-data>

  •  
  •  

    General global description <general-net-spec> General description

  •  
  •  

    Network architecture (<net-architecture>) covering topology, cables, network parameters, driver concept and network EMC design.

  •  
  •  

    Network operation (<net-oper-spec>) covering data traffic, signals, and messages.

  •  
  •  

    Additional specification (<add-spec>)


    Figure 7: Basic structure of MSRNET DTD

    msrnet.eps


    3.1

       

    General description

    General information regarding the network can be given in <general-net-spec>. Described in this are for example, the application for the network (power train, comfort area).

    3.2

       

    Network architecture

    The description of the network architecture (<net-architecture>) comprises the topics "Connection component" <connection-comp-spec-1>, "Topology" (<net-topology-spec>) and "Network interface" <net-interface-spec>. Both predefined as well as arbitrary parameters can be used to specify the network and the network hardware.

    <add-spec> serves to define additional specifications for which no specific structure is given in the DTD.

    3.2.1     Connection components

    The network is physically set up by connection components such as cables. These components are described in <connection-comp-spec-1>FOOTNOTE. A connection (refer to Structure for connection components), similar as in MSRSYS DTD.
    Figure 8: Structure for connection components

    connection-comp-spec-1.eps


    3.2.2     Topology

    The topology type, the nodes as well as the segmentation of the network can be documented within <net-topology-spec> (refer to Structure of the topology). The type (<topology-type>) can express characteristics such as one of "ring", "star", "bus", "bus with single feeder" or even "mixed form" and can be supplemented by a figure.

    In addition to this, network lines (<net-line>), nodes <net-nodes> (Network lines) and segmentation <segmentation> (Description of segmentation) can be described.
    Figure 9: Structure of the topology

    net-topology-spec.eps


    3.2.2.1     Network lines

    The physical layer of the network is established by multiple logicalFOOTNOTE signals (called <net-line> here). An example for this is CAN_LOW, CAN_HIGH, CAN_SHIELD. These wires can be described in topology (<net-lines>). The description comprises as a minimum, a <short-name> and a <long-name>. A detailed presentation (<net-line-desc>) can be given with tables, graphics, etc.

    In the MSRSYS DTD instances, these <net-line>s are assigned to the component signals (compare Description of network connections in MSRSYS DTD, <net-line>). Thus it is possible by this to check the consistencyFOOTNOTE (semantics).

    An explicit assignment of these signals to the lines in the connection-component (e.g. by color code) is not made as the structure of <connection-comp-1> is not detailed enough.

    3.2.2.2     Description of network nodes

    The description of the node comprises:
    <short-name>

    Short name for the node in the network. This can also be a number.

    <long-name>

    Long name for the node in the network.

    <node-type>

    The node type serves to differentiate between participants and auxiliary nodes. Auxiliary nodes do not participate in the network traffic but rather only serve the physical structure or presentation of the topology.

    <net-node-port>s

    The ports for the node are defined here (compare Description of network connections in MSRSYS DTD). This is the only point where the referential consistency to MSRSYS DTD instances must be assured. The <net-node-port> references the component (<part-ref>) as well as the net-port (<net-port-ref>) associated with the component type from the MSRSYS DTD. FOOTNOTE

    <interface-circuit>

    Information on the terminal circuitry. <interface-circuit> can be given here. This information is redundant to MSRSYS DTD. The structure is retained in order to be able to give an autonomous description for a MSRNET instances. The information is optional.

    3.2.2.3     Description of segmentation

    The segmentation can be described by text and graphics (in <segmentation-desc>) as well as by a formal specification (in <segments>).

    The type of cable used as standard for the network can be given in <connection-comp-ref>.

    The formal specification describes all segments (<segment>):
  •  
  •  

    Segments can be given in variant-specific manner (specified by <variant-def-refs>).

  •  
  •  

    Details on the start-nodes and end-nodes (within <segment-end-nodes>), segment lengths (in <segment-length>) as well as cable types for the individual segments. The start and end nodes are defined by referencing one of the <net-node-port>s of the node in question (<net-node-port-ref>).

  •  
  •  

    The <segment-length> is to be given in the SI unit of metersFOOTNOTE.

  •  
  •  

    A segment-specific type of cable can be given (in <connection-comp-ref>) if this deviates from the type of cable used as standard for the network.

    3.2.2.4     Example of a description for the network topology

    The following example corresponds to the example given in Exemplarily scenario:

    <NET-TOPOLOGY-SPEC>
     <TOPOLOGY-TYPE>bus</TOPOLOGY-TYPE>
     <FIGURE ID="ID-of-topology-figure">
      <LONG-NAME></LONG-NAME>
      <GRAPHIC FILENAME="bus05.eps" NOTATION="EPS"></GRAPHIC>
     </FIGURE>
     <NET-LINE-SPEC><NET-LINES>
      <NET-LINE ID="ID-of-CAN1L">
       <LONG-NAME>CAN_L</LONG-NAME><SHORT-NAME>CAN_L</SHORT-NAME></NET-LINE>
      <NET-LINE ID="ID-of-CAN2H">
       <LONG-NAME>CAN_H</LONG-NAME><SHORT-NAME>CAN_H</SHORT-NAME></NET-LINE>
      <NET-LINE ID="ID-of-CAN1S">
       <LONG-NAME>CAN_S</LONG-NAME><SHORT-NAME>CAN_S</SHORT-NAME></NET-LINE>
      </NET-LINES>
    </NET-LINE-SPEC>
    <NET-NODE-SPEC>
     <NET-NODES>
       <NET-NODE ID="ID-of-ECU1">
        <LONG-NAME>control unit 1</LONG-NAME>
        <SHORT-NAME>ECU1</SHORT-NAME>
        <NET-NODE-VARIANTS><NODE-VARIANT>
         <NET-NODE-PORTS>
          <NET-NODE-PORT ID="ID-of-ECUCAN1">
           <LONG-NAME>control unit 1 - CAN</LONG-NAME>
           <SHORT-NAME>ECUCAN1</SHORT-NAME>
           <LABEL>CAN</LABEL>
           <NET-PORT-REF NET-PORT="ID-of-nameloc-ECU1CAN">/engine-mgnt/ECU1/CAN
            </NET-PORT-REF></NET-NODE-PORT></NET-NODE-PORTS>
          <NODE-TYPE>participator</NODE-TYPE></NODE-VARIANT>
          </NET-NODE-VARIANTS></NET-NODE>
       <NET-NODE ID="ID-of-ECU2">
        <LONG-NAME>control unit 2</LONG-NAME>
        <SHORT-NAME>ECU2</SHORT-NAME>
        <NET-NODE-VARIANTS><NODE-VARIANT>
         <NET-NODE-PORTS>
          <NET-NODE-PORT ID="ID-of-ECUFG">
           <LONG-NAME>control unit 2 - FG</LONG-NAME>
           <SHORT-NAME>ECU2FG</SHORT-NAME>
           <LABEL>FG</LABEL>
           <NET-PORT-REF NET-PORT="ID-of-nameloc-ECU2-MSA">/engine-mgnt/ECU2/MBUS/MSA
            </NET-PORT-REF></NET-NODE-PORT>
          <NET-NODE-PORT ID="ID-of-ECUMSA">
           <LONG-NAME>control unit 2 - MSA</LONG-NAME>
           <SHORT-NAME>ECU2MSA</SHORT-NAME>
           <LABEL>MSA</LABEL>
           <NET-PORT-REF NET-PORT="ID-of-nameloc-ECU2-FG">/engine-mgnt/ECU2/MBUS/FG
            </NET-PORT-REF></NET-NODE-PORT></NET-NODE-PORTS>
         <NODE-TYPE>participator</NODE-TYPE></NODE-VARIANT>
         </NET-NODE-VARIANTS></NET-NODE>
       <NET-NODE ID="ID-of-ECU3">
        <LONG-NAME>control unit 3</LONG-NAME>
        <SHORT-NAME>ECU3</SHORT-NAME>
        <NET-NODE-VARIANTS><NODE-VARIANT>
         <NET-NODE-PORTS>
          <NET-NODE-PORT ID="ID-of-ECUCAN3">
           <LONG-NAME>control unit 3 - CAN</LONG-NAME>
           <SHORT-NAME>ECUCAN3</SHORT-NAME>
           <LABEL>CAN</LABEL>
           <NET-PORT-REF NET-PORT="ID-of-nameloc-ECUCAN3">/engine-mgnt/ECU3/CAN
            </NET-PORT-REF></NET-NODE-PORT></NET-NODE-PORTS>
         <NODE-TYPE>auxiliary</NODE-TYPE></NODE-VARIANT></NET-NODE-VARIANTS>
       </NET-NODE></NET-NODES></NET-NODE-SPEC>
    <SEGMENTATION-SPEC>
     <CONNECTION-COMP-REF></CONNECTION-COMP-REF>
     <SEGMENTS>
      <SEGMENT>
       <SEGMENT-END-NODES>
        <NET-NODE-PORT-REF NET-NODE-PORT="ID-of-ECU1"></NET-NODE-PORT-REF>
        <NET-NODE-PORT-REF NET-NODE-PORT="ID-of-ECUMSA"></NET-NODE-PORT-REF>
        </SEGMENT-END-NODES>
       <SEGMENT-LENGTH>
        <SHORT-NAME>lseg1</SHORT-NAME>
        <PRM-CHAR>
         <ABS>1.5</ABS>
         <TOL>-</TOL>
         <UNIT>m</UNIT></PRM-CHAR></SEGMENT-LENGTH>
       </SEGMENT>
      <SEGMENT>
       <SEGMENT-END-NODES>
        <NET-NODE-PORT-REF NET-NODE-PORT="ID-of-ECUFG"></NET-NODE-PORT-REF>
        <NET-NODE-PORT-REF NET-NODE-PORT="ID-of-ECUCAN3"></NET-NODE-PORT-REF>
        </SEGMENT-END-NODES>
       <SEGMENT-LENGTH>
        <SHORT-NAME>lseg2</SHORT-NAME>
        <PRM-CHAR>
         <ABS>2</ABS>
         <TOL>-</TOL>
         <UNIT>m</UNIT></PRM-CHAR></SEGMENT-LENGTH>
       </SEGMENT>
      </SEGMENTS>
     </SEGMENTATION-SPEC>
    </NET-TOPOLOGY-SPEC>

    3.2.3     Description of network interfaces

    The network interface (<net-interface-spec>) constitutes the second part of the hardware description. This describes the driver concept (<driver-concept>), the network parameters globally defined for all participants (<net-interface-prms>), notes on the EMC design for the network (<net-emc-design>) as well as supplementary information (<add-info>).

    The description of the bus interface, or bus link, consists of a bus-global physical data sheet (requirements); either according to ISO Norm CAN High-Speed resp. ISO Norm CAN Low-Speed or individually characterized.

    The detailed description of the CAN-controller hardware occurs within <part-type-spec> in the MSRSYS DTD.
    Figure 10: Structure of the network interface

    net-interface-spec.eps


    The network parameters defined globally for all participants are summarized as a parameters table (<net-interface-prms>)FOOTNOTE:
    <baudrate>

    The baud rate (Baud rate) in Hz. The <abs>-<tol> model must be used. The tolerance shall be given in %.

    The baud-rate programming for the CAN-controller can be derived from the above parameter, is not however unique (e.g. Register occupation). It concerns here a description of the bus link at a higher level (higher than the physical level). This can also be termed parameterization of the CAN controller and is to be documented for the CAN controller or for the control unit.

    <sample-point>

    The sample point for a single bit in a message. The information is given as a percentage. (<abs>-<tol> model without completed tolerance information)

    This information is optional.

    This parameter indicates the point in time when a bit will be sampled. It is given as a percentage of the bit time (transmission time for one bit). A typical value is 75 %.

    <sample-rate>

    Number of sampling operations per bit

    This information is optional.

    <btl-cycles>

    Number of BTL cycles BTL cycles as a whole-number value, i.e. the resolution of one bit (<abs>-<tol> model without completed tolerance information).

    This information is optional.

    <sjw>

    SJW (Synchronization Jump Width) as whole-number value (SJW). The parameter "SJW" (Syncro Jump Width) is given as a percentage of the bit time as well.

    This information is optional.

    <sync-edge>

    Synchronization flank, to be given as a <text> parameter

    This information is optional.

    The <baudrate> is global to the bus. The parameters <sample-point>, <sjw> and <btl-cycles> are generally global, can however be participant-specific in exceptional cases. These special circumstances are not covered in MSR NET DTD.

    The driver modules used or to be used can be described within the scope of the optional driver concept (<driver-concept>).

    Just as for the driver concept, an structure (<net-emc-design>) is available for describing the network EMC design.

    Additional physical parameters such as flank steepness, input resistance and signal level shall be documented as required for the additional information (<add-info>).

    3.3

       

    Network operation

    This section (<net-oper-spec>) describes the data traffic for the differing network services (General network management as well as the behavior when faults occur (Error handling) and similar. The structures for the block-wise transmission of data are illustrated in Block transmission modes.
    Figure 11: Structuring the network operation

    net-oper-spec.eps


    A message that can be transmitted via CAN contains several signals as a rule, whereby it is possible that one signal is being used in more than one message. It is for this reason that the signals (<net-signal-spec>, refer to Network signals) are specified first, and then the messages (<net-message-spec> refer to Messages).

    3.3.1     General network management

    Information can be provided in this section (<net-mgmt-spec>) on, amongst others, sleep/wake-up mechanisms. If the network can run in different operational modes, then these (and the transition mechanisms) are to be described here as well.

    All net-signals and messages used for network management must be specified as net-signals (<net-signal>) or net-messages <net-message> (compare Network signals). Grouping single messages into groups (using <net-message-set>, compare Messages) serves this purpose in particular. Network management signals can be summarized manually as a separate table (CALS table) with <xref>s when preparing the documentationFOOTNOTE.

    The provsion of standby values is not included in the network description (e.g. for provisionnet-signal group) because this is to be executed as a rule by the recipient of the signal.

    3.3.2     Initialization

    The initialization (<net-init-spec>) describes services and protocols that serve to bring a network participant to a state capable of communication following power-up or after a reset.

    3.3.3     Error handling

    The section <net-error-handling> documents the mechanisms for handling errors within the network.

    3.3.4     Diagnostics

    The section <net-diag-spec> documents the mechanisms for processing diagnostic routines in the network.

    3.3.5     Block transmission modes

    The block transmission modes (<net-block-modes>) describe application-specific protocols (initialization, diagnostics and similar) for the transfer of data packages.

    It is recommended to link to (with <xref>) the messages used for the block transmission modes. Signals are also used to set up these messages. These signals are identified as such by the net-signal class (<net-signal-class>).

    3.3.6     Network signals

    <net-signal-spec> FOOTNOTE (refer to Network signals) specifies the signals transmitted in the network.

    Network signals are related to the variables in control-unit software. Therefore optional parts of the software data dictionary (<sw-units> and <sw-compu-methods>) are included in the DTD.

    The <net-signal-group>s contain those signals having exactly the same characteristics. Therefore duplicated descriptions are not necessary.
    Figure 12: Network signals

    net-signal-spec.eps


    The following signal characteristics (<net-signal-spec-variant>) existFOOTNOTE:
    <bitsize>

    Length of the signal in bits

    <init-value>

    Optional initialization value - this value is transmitted if the associated physical signal has not yet been measured.

    <net-signal-class>

    The optional net-signal class (<net-signal-class>) can be an "Application signal" or "Network management signal".

    <error-values>

    This value is transmitted if the associated physical signal is not available because of an error situation (e.g. sensor fallen off). Several <error-value>s can be given in order to differ between several error situations. This information is optional.

    <sw-limits>

    Optional information on the range of values for the signals. The information can be provided both as a network-internal (<coded>) as well as a physical (<phys>) presentation.

    <sw-compu-method-ref>

    The referenced conversion method specifies how the network-internal presentation (coded or internal values) is converted into the corresponding physical values (external values). Refer also to: [External Document: Structures Principles for MSR Software DTD / State: 1.1.0 / Publisher: MSR AG-MEDOC / Relevant Position: Content model software]

    This information is optional.

    3.3.7     Messages

    The signals in the network are transmitted as sets of messages. These messages can be specified in <net-message-spec> (refer to Structure of messages).

    Network messages can be grouped in <net-message-set>s. The grouping is not intended for messages that have identical specifications. It rather serves for logical grouping of messages.
    Figure 13: Structure of messages

    net-message-spec.eps



    Figure 14: Structure of a single net message

    net-message.eps


    Each message <net-message> can be specified variant-specific. The description consists of:
    <net-message-desc>

    The message can be described here in prose.

    <net-message-identifiers> or <calc-net-message-identifiers>

    Each message is identified by an identifier which is either specified either by <identifier> within <net-message-identifier> or which can be calculated (see.<calc-net-message-identifiers>).

    Each message can have several identifiers depending on their sender identified by <net-node-ref>. In order to enable variant specific sender/id-combinations, it is possible to specify more than one sender together with the according variants (<variant-def-ref>).

    The identifier is a hex value for identification of the message in the network.

    <calc-net-message-identifiers>

    Two mechanisms are available for determining the identifiers of a specific <net-message> (for a network node):
  •  
  •  

    Discrete information for the identifiers <net-message-identifiers>.

  •  
  •  

    A computation of the identifier (<calc-net-message-identifiers>) as the sum of a basis and <identifier-base-address> and an offset(<net-identifier-offset>) given in <net-node-variant>. The <msg-identifier-offset> is given by means of the respective <sender>.

    This allows to describe structurally identical (abstract) messages. Such messages can only then be transmitted on the bus when they have received a unique assignment to an identifier.FOOTNOTE

    <address-mode>

    The address mode can be "STD" (Standard) or "XTD" (Extended).

    A more appropriate label is "CAN data transmission format". This is a very global definition for a bus. In the case of "Extended-Format", it is possible to define for each control unit/CAN controller, whether it is "active" or "passive".

    <byte-order>

    Specifies the byte order in the message. Possible values are: motorola, motorola forwards, motorola backwards or intel.

    <dlc>

    The information DLC (Data Length Code) (refer to DLC) is given in bytes and indicates the length of the message. A message can include gaps and hence the length cannot be determined from the sum of the signal lengths.

    <net-message-signals>

    The signals of a message are listed in <net-message-signals> as <net-message-signal>. This information is optional. This is useful for the definition of block modes without <net-signal> specification. The usage of <net-signal>s within <net-message>s must be specified by linking the net-signal with <net-signal-ref> and giving an offset. Optional receivers can be linked by <net-node-ref>s.

    Multiplexed signals can also be supported. These are specified as <multiplex-signal-set> which comprises of a <multiplexor> and the associated signals (<multiplex-signal-list>). The multiplexor is specified by an <offset> FOOTNOTE and its length (<bitsize>). The <multiplex-signal-list> contains <multiplex-entry> which is used to associate a <multiplex-value> with a signal list (<net-message-signals>). Any number of interleaved multiplex signals can be established in this wayFOOTNOTE.

    The associated receivers <receivers> shall also be documented for each signal of a message (direct or multiplexed) since these can also depend on the message.

    <net-message-layout>

    The information <net-message-layout> is foreseen as an optional, redundant supplement to the signal list (<net-message-signals>). Preprocessed information can be stored here that cannot be derived by the SGML formatter from the <net-message-signals>. Valid is always the information given in <net-message-signals>.

    <sender>

    Designates the node which submits the signal by <net-node-ref>.

    <transmission-spec>

    Describes the transmission procedure for the message.

    An rough image in the form of a layer model (similar to the ISO/OSI reference model for communication) is provided by the following illustration:
    Figure 15: Layer model for times/transmission times

    net-times.eps


    The following parameters apply
    <powerup-receive-time>

    Readiness to receive following power-up Readiness to receive following power-up

    Transmission parameter for a message that describes the point in time following power-up as of which the message can be received.

    <powerup-transmit-time>

    Readiness to transmit following power-up Readiness to receive following power-down

    Transmission parameter for a message that describes the point in time following power-up as of which a message can be sent.

    <powerdown-receive-time>

    Readiness to receive following power-down Readiness to receive following power-down.

    Transmission parameter for a message that describes the time after a power-down message during which a reaction to incoming messages is possible even though sending is not possible. It can be prevented by this that a component goes into the sleep mode just when a message is en route to the component.

    <latency-time>

    Latency time Latency time

    Optional transmission parameter for a message that describes the transmission time in the network. The latency time is the time by which the sending process can be delayed by messages having a higher priority. In technical terms, the latency time is period of time between setting the TransmitRequestBit and receiving the AckMessage. The maximum latency time for this message can thus be specified for this messageFOOTNOTE.

    <cycle-time>

    Cycle time Cycle time (also cycle tolerance time), optional transmission time for a message that describes the tolerance time for a message for a cyclic control system (cycle sending of messages)FOOTNOTE.

    <phase-relations>

    Phase relation to other messages Phase relations to other messages.

    Transmission parameter for a message that describes whether there is a phase relation with other messages present.


    Figure 16: Structure of signals in a message

    net-message-signal.eps