![]() ![]() |
3 |
Structuring of MSRNET DTD |
Long and short name of the instance (<long-name> <short-name>) |
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. |
3.1 |
General description |
3.2 |
Network architecture |
<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>. A connection (refer to Structure for connection components), similar
as in MSRSYS DTD.
Figure 8: Structure for connection components
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
3.2.2.1 | Network lines |
The physical layer of the network is established by multiple logical 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 consistency (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. |
<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>). |
The <segment-length> is to be given in the SI unit of meters |
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
The network parameters defined globally for all participants are summarized as a parameters table (<net-interface-prms>):
<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 |
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 documentation.
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> (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
The following signal characteristics (<net-signal-spec-variant>) exist:
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
Figure 14: Structure of a single net message
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):
| ||||||||||||
<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> 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: The following parameters apply
|
![]() ![]() |