Structure Principles

MSR Sub-project MEDOC

Structure Principles
Scope: Networks
[SNT]
Revision: 3
This document describes the principles for the structure of the MSR development documentation MEDOC for Networks. The description can also be used as a guideline for preparing structured development documentation.


I. Introduction

Structure Principles
I. Introduction

This document describes the principles for the structure of for the MSR development documentation MEDOC for Networks. The description can also be used as guideline for preparing structured development documentation.
The description is given in, amongst others, the structures of graphics that have been acquired from implementation of the MSRNET.DTD prototype. The meanings for the symbols used in the graphics are given in Meaning of symbols in the structural graphics.
It shall be noted at this point that MSR does not pursue standardization and will not pursue any in the future. Only content and structure of existing standards/in-house standards are used in the requirements documentation and in the MEDOC development documentation. MEDOC shall provide the possibility of storing the contents of (inter)national standards and in-house standards as well as non-standardized documents, for describing data of relevance to development documentation.
A simplified presentation of this is given in the following table:
Delimitation of MEDOC activities from standardization activities
MEDOC | Standard | In-house standard | No standard
Structure | Structure of standards can be reproduced by MEDOC | Structure of in-house standards can be reproduced | Agreed by MSR group
Content | Master data taken from standards | Master data can be supplemented in specific cases |
MEDOC allows inclusion of the contents and structure of international, national and in-house standards. Fundamentals for the structure definitions are standards that are valid at the time of printing. In addition to this, data that cannot be reproduced by any standard, can be recorded using MEDOC. The structure for the data will be agreed by the MSR group, contents will not be subjected to any standardization whatsoever. Tables and contents of tables that are given in this document are only to be regarded as examples of data. The contents have been taken in some instances from international standards since different limiting values apply for individual companies within the consortium.


II. Objective and procedure

Structure Principles
II. Objective and procedure

The objective of the study group MEDOC Networks is to define one format for all possible bus descriptions and descriptions for networks. The data modeling is performed initially on the basis of the CAN (Full CAN and Basic CAN). The transfer to further network formats is made after the data modeling has been completed.


1. General

Structure Principles
1. General

The MSRDOC.DTD modeled up to now always represented one entity, a system including the associated control units or the associated control unit (e.g. an ABS system). Since a network generally links several control units in various systems (e.g. the engine control unit and the ABS control unit), it is meaningful to display the description of networks in a separate DTD.
Figure 1: MSRDOC.DTD and MSRNET.DTD
Entity-overriding links are needed for a description of coupling the control units to the network. A corresponding variant concept based on the MSRDOC.DTD is foreseen for this, such that the references between entities of the MSRDOC.DTD and the MSRNET.DTD can be written with reference to variants. A series-related or series-overriding description of networks must be possible.
If a vehicle system possesses several network systems in parallel, then these shall be accordingly described in several entities of the MSRNET.DTD. A clear distinction (engineering as well as organization) between the differing networks is attained by this [image] .
The supplier receives the description of the entire network topology in the types series in question from the manufacturer.
A link between the MSRNET.DTD and the MSRDOC.DTD's via the short description for the net-signals is conceivable.

Gateways initially propose a compilation of several networks in one entity. The gateway functionality is however realized in a specific system or unit, and is therefore to be described in this performance or software.


2. Arrangement of network and control units

Structure Principles
2. Arrangement of network and control units

Contents of this chapter:
  • 2.1. Requirements
  • 2.2. Description of network connections in MSRDOC


2.1. Requirements

Coupling a control unit with one or more networks can be realized by differing ways and means. Three of these possibilities are shown in Linking network and control unit :
a) | Single feeder and network system
b) | Branched feeder or star point in the control unit (multiple n-conductor lines)
c) | Connections to several networks (e.g. gateway)
Common to all three approaches is that the arrangement is on the basis of control-unit signals to names for network lines [image] . An arrangement to a control-unit port does not appear to have sufficient flexibility for use as a network description for several families of control units.
Figure 2: Linking network and control unit
Whereas in figure a) the control unit is linked to the network via an n-conductor single feeder (e.g. CAN_High, CAN_Low, CAN_Shield), there are a number of these n-conductor signal lines in figure b). Case b) illustrates a branched feeder or star point of the network in the control unit.
A control unit can furthermore, as illustrated in figure c), be connected to differing networks (e.g. gateway). Versions of the interfaces to each of the networks to a) and b) are possible here.
The alternatives in D. Alternatives considered for linking control unit and network, were also considered alongside the solution chosen for the description of control unit and network. The solution in 2.2. Description of network connections in MSRDOC) is applied.

The term net-signal is not used here as this appears elsewhere in another context in conjunction with messages.


2.2. Description of network connections in MSRDOC

A new element <network-spec> (refer to Network connections in MSRDOC ) is introduced in the <architecture> in MSRDOC.DTD in order to be able to define the network links for the component types. This modeling was chosen for the following reasons:
  • The objectives for a (semantic execution) referencing from MSRNET.DTD entities are concentrated in <network-spec>.
  • Network-related characteristics and interrelationships of signals can be concentrated here without a general expansion of the contents model of < signal> and at the same time, so as to be able to handle net-signals like all other signals.
A possible sematic overlapping with <signal-class> is intentionally accepted since the latter has been designed for company and process-specific classifications.
Figure 3: Network connections in MSRDOC
Example for an entry in the MSRDOC entity
A MSRDOC.DTD entity (for control unit 2 in Examplary scenario) looks in principle like the following (the counterpart in the MSRNET.DTD entity is given in 3.2.2.4. Example of a description for the network topology ):
Figure 4: Examplary scenario
<part-type>
   <long-name>control unit 2</long-name>
   <short-name>SG2</short-name>
...

 <architecture>
   <scheme-diagrams> ...
   <interface-spec>  ...
   <signal-spec>     ...
   <network-spec>
    <networks>
      <network><long-name>CAN bus for engine management</>
        <short-name>MBUS</>
        <desc>This bus primarily handles engine management</>
        <net-ports>
           <net-port>
              <long-name>engine-side connection</>
              <short-name>MSA</>
              <net-lines>
                <net-line>
                   <net-line-name>CAN_LOW</>
                   <signal-ref sref="MBUS_MSA_LOW">
                </>
                <net-line>
                   <net-line-name>CAN_High</>
                   <signal-ref sref="MBUS_MSA_HIGH">
                </>
                <net-line>
                   <net-line-name>CAN_shield</>
                   <signal-ref sref="MBUS_MSA_SHIELD">
                </>
           </net-port>
           <net-port>
              <long-name>connection on passenger-compartment side</>
              <short-name>FG</>
              <net-lines>
                <net-line>
                   <net-line-name>CAN_LOW</>
                   <signal-ref sref="MBUS_FG_LOW">
                </>
                <net-line>
                   <net-line-name>CAN_HIGH</>
                   <signal-ref sref="MBUS_FG_HIGH">
                </>
                <net-line>
                   <net-line-name>CAN_SHIELD</>
                   <signal-ref sref="MBUS_FG_SHIELD">
                </>
            </net-port>
        </net-ports>
     </network>
    </networks>
   </network-spec>
  ...
</part-type>
Summary of net-port, net-line, and signal name
Net-Port | Net-Line | Signal
MSA | CAN_LOW | MBUS_MSA_LOW
 | CAN_HIGH | MBUS_MSA_HIGH
 | CAN_SHIELD | MBUS_MSA_SHIELD
FG | CAN_LOW | MBUS_FG_LOW
 | CAN_HIGH | MBUS_FG_HIGH
 | CAN_SHIELD | MBUS_FG_SHIELD
This variant completely models the component-specific network characteristics. Included in this is also the explicit arrangement of component-signal name and network line [image] .
Net-ports are introduced in order to be able to cover Linking network and control unit case b). The network is applied to a component at several points in this case (i.e. at several ports) and is linked within the component. It can thereby be assumed that the network lines are assigned different designations at the differing pins. A specific net-port arrangement of network-line names to component-internal signal names must therefore be made. This arrangement can in principle be realized by two variants:
  • Arrangement of network-line and component signal name per net-port
  • Arrangement of net-port und component signal name per network-line

This solution was not chosen and an example is therefore not given.
The network-line identifiers are not explicitely normed. It is the task of a semantic check to ensure consistency by the network-line identifiers for the differing net-ports.


3. Structuring of MSRNET.DTD

Structure Principles
3. Structuring of MSRNET.DTD

Figure 5: Basic structure of MSRNET.DTD
The description of a CAN network is made up of the following parts:
  • Long and short designation (<long-name> <short-name>)
  • Administration information < admin-data>
  • Project information <project-data >
  • General global description <general-net-spec> 3.1. General description
  • Network architecture (<net-architecture>) (topology, cables, network parameters, driver concept, network EMC design)
  • Network operation (<net-oper-spec>) (data traffic, signals, messages).
An approximate pictorialization in the form of a layer model (similar to the ISO/OSI reference model for communication) is provided by the following illustration:
Figure 6: Layer model for times/transmission times
The first version of the DTD contains no formal description of required transmission times [image] .
The parameters Latency and Cycle time are only foreseen for the initial description of messages, i.e. parameters in the lower layer within the illustration.

Such a description of a formal nature is not be found in currently applicable specifications either.


3.1. General description

Generally speaking, global descriptions of a network can be stored in <general-net-spec>. Described in this are for example, the application for the network (drive train, comfort area ...).


3.2. Network architecture

The description of the network architecture (< net-architecture>) comprises the topics of "Connection component" <connection-comp-spec-1>, "Topology" (< net-topology-spec>) and "Network interface" <net-interface-spec >. Both fixed as well as independent parameters can be described here for the network and the network hardware.
<add-spec> serves to define additional specifications nor foreseen in the DTD.


3.2.1. Connection components

The network cables used for the connection components are described as < connection-comp-spec-1> (refer to Structure for connection components), similar as in MSRDOC.DTD . .
Figure 7: Structure for connection components

A modification is used that does not permit use of a part-type reference.


3.2.2. Topology

The type, the nodes as well as the segmentation, can be documented within the topology (<net-toplogy-spec > refer to Structure of the topology). The type (<topology-type>) can exhibit characteristics such as "ring", "star", "bus", "bus with single feeder" or even "mixed form" and must be supplemented by graphics.
Nodes <net-nodes> (3.2.2.1. Network lines) and segmentation <segmentation> (3.2.2.3. Description of segmentation) can be described in addition to this.
Figure 8: Structure of the topology


3.2.2.1. Network lines

The wiring in the network itself consists as a rule of many lines (called net-line here. An example for this is ( CAN_LOW, CAN_HIGH, CAN_SHIELD). These signals can be described in topology (<net-lines>) as well. The description comprises as a minimum, a <short-name > and a <long-name>. A detailed presentation (<netline-desc>) can be given with tables, graphics, etc., as an option.
In the MSRDOC.DTD entities, these net-lines are arranged according to the component internal signals (compare 2.2. Description of network connections in MSRDOC, < net-line>). Thus it is possible by this to check the consistency [image] (semantics).
An explicit allocation of these leads to the conductors (e.g. by color code) of the connection cable is not made as this cannot be described by a formalized hierarchy.

Formal referencing of net-lines between msrdoc and msrnet was dispensed with for pragmatic reasons since the same designations are used as a rule in all entities.


3.2.2.2. Description of network nodes

The description of the node comprises:
< short-name> | Number or short designation for the node in the network
< long-name> | Designation for the node in the network
<node-type> | The node type serves to differentiate between participators 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 2.2. Description of network connections in MSRDOC). This is the only point where the referential consistency to MSRDOC.DTD entities 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 MSRDOC.DTD.
<interface-circuit > | Information on the terminal protective circuitry. <interface-circuit > can be used here. This information is redundant to MSRDOC.DTD. The structure is retained in order to be able to give an autonomous description for a MSRNET entity. The entire terminal protective circuit can be given for a node in addition to this, whereas for MSRDOC.DTD only the circuit for a single pin is described. The information is optional.

All node-ports of a node must reference the same part. The reference to the part has not be "taken out" of the node-ports in spite of this. This would have meant a distrubition for the definition of the the semantics for the reference. This should be avoided for handling reasons. It is the task of a semantic check to determine any inconsistencies.


3.2.2.3. Description of segmentation

Documentation of the segmentation can be both of a general nature (by text and graphics) (<segmentation-desc>) as well as by a formal (<segments>) specification.
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 as being variant-specific (specified in <variant-def-refs>).
  • Details on the start-nodes, end-nodes, segment lengths (<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 information in the SU unit of measure of meters is foreseen for the segment length [image] .
  • A segment-specific type of cable can be given (<connection-comp-ref> if this deviates from the type of cable used as standard for the network.

The application of the standard parameters model was dispensed with here in order to enable the presentation of segmentation as a closed table.


3.2.2.4. Example of a description for the network topology

The following example [image] corresponds to the example given in Examplary scenario:
<net-topology-spec>
  <net-topolgy-type>bus</>
  <connection-comp-ref connection-comp="nyfaz"></>
  <nodes>
    <node>
       <long-name>control unit 1</>
       <short-name>1</>
       <node-variants>
         <node-variant>
           <node-ports>
             <node-port id="sg1.can">
               <long-name>SG1 - CAN</>
               <short-name>can</>
               <net-port-ref netport="SG1/CAN">
             </node-port>
         </node-variant>
       </node-variants>
       <node-type>participator</>
    </node>
    <node>
       <long-name>control unit 2</>
       <short-name>SG2</>
       <node-variants>
         <node-variant>
           <node-ports>
             <node-port id=sg2.msa>
               <long-name>engine compartment CAN</>
               <short-name>MSA</>
               <net-port-ref netport="SG2/MSA">
             </node-port>
             <node-port id="sg2.fg">
               <long-name> passenger compartment CAN</>
               <short-name>FG</>
               <net-port-ref netport="SG2/FG">
             </node-port>
         </node-variant>
       </node-variants>
       <node-type>participator</>
    </node>
    <node>
       <long-name>control unit 3</>
       <short-name>3</>
       <node-variants>
         <node-variant>
           <node-ports>
             <node-port id=sg3.can>
               <long-name>control unit3</>
               <short-name>can</>
               <net-port-ref netport="SG3/can</>
             </node-port>
             <node-type>participator</>
         </node-variant>
       </node-variants>
     </node>
   </nodes>

   <segmentation>
     <segments>
        <segment>
           <segment-end-nodes>
             <node-port-ref node-port="sg1.can"></>
             <node-prot-ref node-port="sg2.msa"></>
           </segment-end-nodes>
           <segment-length>1</>
        </segment>
        <segment>
           <segment-end-nodes>
             <node-port-ref node-port="sg2.fg"></>
             <node-prot-ref node-port="sg3.can"></>
           </segment-end-nodes>
           <segment-length>1</>
        </segment>
      </segments>
</net-topology-spec>

The example has to be updated.


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 ISO Norm CAN Low-Speed or individually characterized. It shall then be established on the participant side (control unit side) that chip that shall be used (<part-type-spec > in MSRDOC).
Figure 9: Structure of the network interface
The network parameters defined globally for all participants are summarized as a parameters table (<net-interface-prms >) [image] :
<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> | Numple 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 precentage 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 MSRNET.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 arbitrary 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>).

A specific parameter model should really be used for each of these parameters. The MSR standard parameters model has however been used in the interests of generalization. If this is executed in future as the architectural form, then more specific model models could be used. The user must however first select the correct model, or the author environment should propose the correct model.


3.3. Network operation

This section (<net-oper-spec >) describes the data traffic for the differing network services (3.3.1. General network management as well as the behavior when faults occur (3.3.3. Error handling) and similar. The structures for the block-wise transmission of data are illustrated in 3.3.5. Block transmission modes.
Figure 10: Structuring the network operation
A message that can be transmitted via CAN contains several signals as a rule, whereby it is possible that one one signal is being used in more than one message. It is for this reason that the signals (<net-signal-spec>, refer to 3.3.6. Network signals) are specified first, and then the messages (<net-message-spec> refer to 3.3.7. Messages).


3.3.1. General network management

Information can be provided in this section (<net-mgmt-spec >) on, amomgst 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-message>) (compare 3.3.6. Network signals). Grouping single messages into groups (compare 3.3.7. Messages) serves this purpose in particular . Network management signals should be summarized as a separate table (CALS table) when preparing the documentation [image] .
The provsion of standby values is not included in the network description (e.g. for net-signal group) because this is to be executed as a rule by the recipient of the signal.
There are also activities for ASAP and for OSEK regarding the standardization of network management. Formal modeling is initially dispensed with for this reason, and is only foreseen for the structure proposed for the chapter.

An extension of the DTD at a later point in time could provide the structural basis for automation of this.


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.


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 reference 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>).
There are also activities for ISO TC22 SC3 WG1 regarding the standardization of block transmission modes. Formal modeling is initially dispensed with for this reason, and is only foreseen for the structure proposed for the chapter.


3.3.6. Network signals

<net-signal-spec > [image] (refer to Network signals) specifies the signals transmitted in the network.
Network signals are related to the variables in control-unit software. It is for this reason that optional parts of the software data dictionary (< sw-units> and <sw-compu-methods>) are included in the DTD.
The net-signal groups <net-signal-group >s serve to group those signals having exactly the same characteristics. A redundant description is no longer necessary due to the grouping into a group [image] [image] .
Figure 11: Network signals
The signal characteristics (<net-signal-spec-variant >) comprise the following parts [image] :
<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 differentiate between differing 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 conversion documents how the network-internal presentation (coded or internal values) is converted into the corresponding physical values (external values). This is documented by a reference to the <sw-compu-methods >. Refer also to: Fundamental structures for software This information is optional.
A recipients list is not foreseen for the definition of network signals since such a definition can be generated by the information on the messages (<receivers> within <net-message-signals > within <net-message-spec>).

Some of this information is optional, in order to be able for instance, to apply name and size to these block mode signals as well.
This is a general principle for MSR
The structure is similar to that for a signal group in MSRDOC.DTD
The term network signal is used here for differentiation in MSRDOC from the term signal.


3.3.7. Messages

The signals in the network are transmitted as groups 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 are structurally identical but rather serves for documentation of the grouping.
Figure 12: Structure of messages
Each message <net-message > is specified as a function of the variant and identified by < long-name>, <short-name>. The description consists of:
<net-message-desc>
The option is given here of describing the message in prose.
<identifier>
This a hex. value for identification of the message in the network.
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 given in nodes. The < msg-identifier-offset> is given by means of the respective <sender >.
    This serves to describe structurally identical (abstract) messages. Such messages can only then be transmitted on the bus when they have received a unique allocation to an identifer.
There exists a 1-to-n relationship between <identifier > and <sender>, in order to be able to describe variants (<variant-def-ref>).
<address-mode>
The address mode can be "STD" (Standard) or "XTD" (Extended).
A more appropriate designation is "CAN data transmission format". This is a very global definition for a bus and can be " Standard-Format" or "Extended-Format". Specifications from the Bosch company are available for this. It can be defined in the case of "Extended-Format " for each control unit/CAN controller, whether this is "active" or "passive ", i.e. whether communication with the extended format is possible or not.
<byte-order>
Designates 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. <net-message-signal> can either be direct <net-signal>s or an <offset> can be applied.
Multiplexed signals can also be given. These are specified as < multiplex-signal-set> that specify a < multiplexer> with included an <offset> [image] and length <bitsize>. A signal list (<net-message-signals>) is in turn assigned in the <multiplex-entry > in the <multiplex-signal-list> to each value of the multiplexer. Any number of interleaved multiplex signals can be established in this way [image] .
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>). Pre-processed 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 that the signal sends.
<transmission-spec>
Describes the transmission procedure for the message. 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-upReadiness 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 timeLatency 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 message [image] .
<cycle-time> | Cycle timeCycle 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) [image] .
<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 13: Structure of signals in a message
The consistency of the entered data shall be assured by a semantic check.

Only of relevance for cyclic control systems, hence optional.
Only of relevance for cyclic control systems, hence optional.
This hierarchy is possible as a variant-dependent structure at all levels. Variant-dependencies should however only be introduced at the highest level.
The offsets refer principally to the beginning of the message and are summated (i.e. beginning at 0)
It still has to be clarified where this is defined.
Such messages are e.g., command messages by which a certain function within a control unit can be triggered from different nodes. Further examples are network management and diagnostic messages.


3.4. Variants

Variant dependencies exist for:
  • Nodes (< net-node>)
  • Network interfaces< interface-circuit>
  • Network segments (< segment>)
  • Net-signals < net-signal>
  • Net-signal characteristics <net-signal-group>
  • Message (< net-message>) is then used when the message is present as variant-dependent.
  • Signal entry in message (<net-message-signal>) is then used when the message is present as variant-dependent.
  • Memory layout (task for AG-DTD %info variant-dependent could be realized with <xref> by variants definition).
  • Transmission parameter (<transmission-spec>)
  • Two mechanisms are available for determining the identifiers of a specific < net-message>:
    • Discrete information pertaining to identifiers <net-message-identifiers >.
    • A calculation of the identifier (<calc-net-message-identifiers >) as the sum of a basis and <Identifier-base-adress > and and offset that is given in the node. The < msg-identifier-offset> is given using the corresponding <sender >. This procedure is preferentially used for network management and diagnostics.
    TBD

Not yet realized in 11.0.


4. Basic Structures of the MSR Application Profile

Structure Principles
4. Basic Structures of the MSR Application Profile

All MSR DTDs are using some common data structures. These operating models are described in this chapter.


4.1. Not Content Orientated Information (ncoi)

<ncoi-1> contains all basic descriptive elements. There are also elements like <chapter> or <fail-save-concept> in the MSRSYS DTD which have the same content model as <ncoi-1>.
The figure below illustrates the structure of <ncoi-1>.
Figure 14: Structure of <ncoi-1>
There also are two weaker ncoi models ( ncoi-2 and ncoi-3) with lesser elements than <ncoi-1>. ncoi-2 has no <chapters>. ncoi-3 has also no chapters and futhermore another "topic" model without <prms>.
The components of ncoi [image] are interchangeable between all MSR DTDs [image] without any changes.

DTDs with the same version of the MSR application profile
not content orientated information


4.1.1. Chapter

<chapter> is a sequence of paragraph level elements mixed with <chapter>. <chapter>s can be nested as deeply as required. It is up to the author to make sure, that the nesting of the chapters can be handled by the processing system [image] .
Figure 15: chapter content model
One advantage of using <chapter> for all levels [image] is the option to move a chapter using cut & paste to any place in the document at any level.

the other option would be to have an extra element for each chapter level
In that respect, it is recommended to nest not more than four levels.


4.1.2. Topic

Use <topic-1> or <topic-2> to create bridge titles instead of one line paragraphs with entirely emphasized contents. Note that these elements can be referenced by <xref>. In difference to <topic-1>, <topic-2> has no <prms>.
Figure 16: Structure of <topic-1>


4.1.3. Paragraph Level Elements

"Paragraph level elements" are elements which occur on the same level as <p>.
The user should first look for an appropriate one among the available elements before trying to simulate things by using inadequate elements. In that respect the following hints are given:
<p> | Paragraph
<verbatim> | Preformatted text which is usually set in monospaced font. Tabs, line spaces and carrige returns are considered. Use <verbatim> to print program listings etc. It can even be used to show simple diagrams.
<figure> | See chapter 4.1.3.2. Figure.
<formula> | See chapter 4.1.3.3. Formula.
<list> | A ordered or unordered list of items. For an unordered set of items, use <list type="unnumbered">. For a ordered list of items use <list type="numbered"> [image] .
<def-list> | Use <def-list> to create definition lists which might be collected into an overall definition list or a glossary. In this case <labeled-list> might lead to the same rendition but has no information about the fact that terms are defined [image] .
<labeled-list> | Use<labeled-list> to create explanations or even bridge titles for very short topics instead of bulleted lists with emphasized initial words. See also 4.1.3.1. Labeled List Use <labeled-list> instead of two column tables if the first column cells almost contain one word.
<note> | See chapter 4.1.3.4. Note

it is not really easy to distinguish between these two elements. As a rule of thumb, one might say that the semantics of def-list is stronger than the one of labeled-list which is more layout oriented. The items of def-list can be referenced by xref which is not possible with the items of a labeled-list.
Actually it is up to the rendition system if the sequence is expressed as numbers or as letters.


4.1.3.1. Labeled List

Figure 17: Structure of <labeled list>
<labeled-list> is one of the most powerful elements. If possible it is rendered as a label followed by the item body:
XX      XXXXXXXXXXXXXX
        XXXXXXXXXXXXXX

XXXXXX  XXXXXXXXXXXXXX
        XXXXXXXXXXXXXX

XXXXX   XXXXXXXXXXXXXX
        XXXXXXXXXXXXXX
The indentation is determined by the rendition system which should take into account the biggest <item-label>.
Sometimes the author wants some influence to the indentation. For this respect <indent-sample> can receive any content which is used by the rendition system as a sample which must be rendered and measured to determine the indentation.
The attribute [item-label-pos] defines how the <item-label> should be handled. The default value of the attribute is [item-label-pos]="no-newline". If an <item-label> is wider than <ident-sample> the most general case is to start the item body in a new line if necessary([item-label-pos]="newline-if-necessary"):
XXXXXXXXXX

        XXXXXXXXXXXXXX
        XXXXXXXXXXXXXX

XXXXXX  XXXXXXXXXXXXXX
        XXXXXXXXXXXXXX

XXXXXX  XXXXXXXXXXXXXX
        XXXXXXXXXXXXXX
If the attribute has the value [item-label-pos]="newline" the item-body starts generally in a new line.
Note that <indent-sample> can be used to adjust the indentation if there are multiple <labeled-list>s which should have the same indentation.


4.1.3.2. Figure

<figure> is used to insert graphics into the document. A figure can be defined in three different ways.
  1. as a real <graphic>
  2. as an ASCII graphic (<verbatim>)
  3. as a pure textual description (<desc>) of the graphic
The treatment of the graphic is determined by the attributes of <graphic>:
Do not enter annotating text to <long-name>in<figure> or <table>(like Figure 1: ...). This embellishment is the task of the processing system, not of the author. If the author adds these things, they will be there twice since the rendition system will add it again.
[category]
Denotes the category of the graphic. This information can be used to generate more specific list of figures
[filename]
Denotes the system filename where the rendition system can find the graphic. This is not necessarily the final format. It is up to the rendition system to locate the graphic in the company specific environment, to change the file extension to get the appropriate graphic representation.
The type of this attribute can be turned from SDATA toENTITY in the DTD file in order to allow SGML tools access to the file using its entity manager. In this case, the entity name should be chosen in the style of a filename (e.g. crpctmt.wmf) [image] .
[fit]

0 | figure is placed in original size. If it does not fit on the page or the available space, it is scaled down.
1 | the figure is scaled up or down to fit the page as possible. This value will be ignored if [width] or [height] is specified in addition.
2 | the figure is rotated counterclockwise by 90o if it is landscape and is wider than the actual text area. It is scaled down to the page size if it does not fit otherwise. This value will be ignored if [width] or [height] is specified in addition.
3 | the figure is always rotated counterclockwise by 90o. If it does not fit on the page it will be scaled down. If [width] or [height] is specified in addition, the figure will be rotated and then scaled to the specified values.
4 | the figure is always rotated counterclockwise by 90o and scaled up or down for best fit on the page. This value will be ignored if [width] or [height] is specified in addition.
[height]
If this attribute has a value, the figure will be scaled to the defined height which is a real value with dimensions (e.g. "10cm", "150mm", "12.5in"). If also [width]is specified the figure will be distorted. This value always specifies the width of the "figure box" on the page after possible scaling/rotating.
[notation]
This attribute specifies the format of the graphic file if used by an SGML Application supporting notations.
[scale]
If this attribute receives a value, the figure will be scaled by the given factor which must be a signed real number. Numbers greater 1 increase the size of the figure, values less than 1 make the figure smaller. For example with scale="0.5" the a figure of the size 10x10 cm will appear as 5*5cm.
[width]
If this attribute has a value, the figure will be scaled to the defined width which is a real value with dimensions (e.g. "10cm", "150mm", "12.5in"). If also [height]is specified the figure will be distorted. This value always specifies the width of the "figure box" on the page after possible scaling/rotating.
The scaling attribute precedence is:
  • [scale] has precedence over all
  • [fit]has precedence over [width]and/or [height]

This is the way how this document is prepared. It is visible in the sgml source.
This can be used for systems which can't display graphics.


4.1.3.3. Formula

Figure 18: Structure of <figure>
A formula can be described in five different ways which can exist parallel. These are:
<graphic> | A formula prerendered as a figure.
<verbatim> | A simple ASCII formula.
<tex-math> | A TeX math formula which can be processed by a TeX or LaTeX processor.
<c-code> | A formula which is defined as c-code.
<generic-math> | This element is intended for the definition of semantic math descriptions which can be processed by math processors. Actually there is no recommentation for the language of the formula specification or usage of a special rendering system.
It is up to the rendering system which of the available representations is used.


4.1.3.4. Note

A note is an object to express a combination of an icon with descriptive text and an additional label. This is useful for things like cautions, hints etc..
The attribute [notetype] defines the note category. The following values are available:
  • caution
  • hint
  • tip
  • instruction
  • exercise
  • other
If the attribute [notetype] has a value of "other" the user has to specify a own type within the attribute [user-defined-type].
A formatter has to place the right icon before the descriptive text according to the value of [notetype] or [user-defined-type]. The optional <label > can be used to define a title of the note.


4.1.4. Character Level Elements

Character level elements can occur within element like <p>, <item-label>. There are rendition oriented elements like <e> (emphasis), <sub> as well as semantically oriented Elements as <tt> (technical term) or <std>(referring to an external standard). It is highly recommended to use rather semantically oriented elements than rendition oriented ones.


4.1.4.1. Rendition Oriented Character Level Elements

The rendition oriented character level elements are:
<e> | Emphasizes the text. The attribute [type]determines the rendition style.
<sub> | Subscript - places the contents with smaller font below the base line.
<sup>
Superscript - places the contents with smaller font above the base line.


4.1.4.2. Semantically Oriented Character Level Elements

semantically oriented character level elements
Element | use for | example
<tt> | Use for any technical term. The type of that term is determined by the attribute [type] [image] . This element could be treated as a back-door to markup information which is not totally semantic. The SGML processing system can generate list of technical terms which makes it easier to find misspellings and other errors. | This is an SGML tag <tt type=sgmltag> we can collect all <tt>s
<xref> | Used to create links in the document. The role of the target is determined by the attribute [id-class] receiving the value of the target's fixed attribute [f-id-class]. The attributes of <xref> should be maintained by the authoring system. |
<xdoc> | Used to refer to an external document which usually is not available electronically. <xdoc> receives a set of elements characterizing the external document | Details to architectural forms can be found in .
<ft> | Is used to create footnotes | Footnotes seem to be small and unimportant [image] .
<ie> | creates index entries | It is not necessary to put SGML tags into the Index, since the processing for MSRREP.DTD recommends to create a list of SGML tags automatically.
<xfile> | Is used to create pointers to external files which are not to be processed by the native SGML processing system. The contents of <xfile> can be used to connect to appropriate systems in later steps of the processing chain. | The schematic is found in [MOTRONIC wiring diagram;motronic.asc;concept-ascii-format;concept;2.7;]
<std> | Is used to refer to a standard. | SGML is defined in [Information Processing - Text and Office Information Systems;ISO 8879;Standard Generalized Markup Language;standard;1986;;entire document;]
usage of technical terms
type | use for | example
<tt type=sgmltag> | Used to describe SGML tags including attributes | To describe SGML tags use <tt type=sgmltag>.
<tt type=sgml-attribute> | Used to describe SGML attributes outside of tags | The sgmltag is denoted by the attribute [type]
<tt type=tool> | Used to mention tools used for example in a process. This can be software, as well as mechanical tools. The tool should be specified by its nature not by the specific product name. | SGML files are processed using an SGML processing system.
<tt type=product> | Used to mention specific products. | This document is processed using MetaMorphosis.
<tt type=variable> | Used to mention a variable informally. This is used to control the rendition as well as for generating variable lists. This is mainly for informal reports [image] . It is also possible to use this to mention a variable in the ECU software if no <sw-data-dictionary> is part of the document. In a later process step, this can be turned over to a formal <xref> | The initialization is controlled by the environment variable MMRC. The initial advanced angle is calculated based on NandTL.
<tt type=state> | Used to mention a state for example of a process. | The documents must at least be revised if they are submitted to the customer.
<tt type=prm> | Used to mention a state for example of a process. It is also possible to use this to mention a calibration parameter in the ECU software if no <sw-data-dictionary> is part of the document. In a later process step, this can be turned over to a formal <xref> | The initial advanced angle is calculated using a lookup table KFZW.
<tt type=material> | Used to mention material. | Furniture is usually made of wood and plastic
<tt type=control-element> | Used to mention control elements of tools like push-buttons, menu items, switches etc. as well as keyboard keys. | To finish the dialog push the OK button.
<tt type=code> | Used to markup program in line code sequences | MetaMorphosis is invoked with mm crp.sgm
<tt type=organisation> | Used to markup the name of an organization. | SGML is standardized by ISO
<tt type=other> | Used to mention a special term which does not fit to the other types. This is a back-door for the definition of user defined types. They have to be specified within the attribute [user-defined-type]. A formatter uses this user defined type only if [type=other]. | This is a thing not covered by <tt>.
sub-elements for xdoc and xfile
Element | use for | example
<number> | Used to markup the document ISBN resp. the standard number | ISBN 0-7923-9432-1
<state> | Used to markup the state of the referred document resp. standard. | released
<date> | Used to markup the release date of the referred document resp. standard. This could be expressed as year only, if the exact date is not known. | 1994
<publisher> | Markup the publisher of the document or the standard. This can be the author as well as the publishing organization. | Steven J. DeRose and David G. Durand / Kluwer Academic Publishers
<position> | Markup the relevant position in the referenced document resp. standard. | Chapter 5.2 - Architectural forms
<subtitle> | Used to markup the subtitle of the referenced document or standard if there is one. | HyTime
<short-name> | Used to markup the document identifier | SGML
<long-name> | Used to markup the main title of the referenced object. | Making Hypermedia work
<file> | Used to markup the file access information. This is intended to be processed by external systems. | [MOTRONIC wiring diagram;motronic.asc;concept-ascii-format;concept;2.7;]

Note that in MSRDOC.DTD there are means to formally describe variables to be used if the system software of an ECU is specified.
But many people read footnotes first - so put the interesting stuff in footnotes
it is recommended to enter the term always in singular and create plurals outside of the element (see second example).


4.1.5. Table

<table> is implemented as CALS table (see CALS table spec at www.oasis.org). Capturing these kind of tables must be supported by the SGML editor, so only some hints are given here:
  • CALS tables consist of mainly three parts within <tgroup>: <thead>, <tbody>, <tfoot>.
  • Each part is made of <row>s of <entry>s. Each of these elements have attributes to control the layout of the table.
  • <tgroup> also receives a set of <colspec>s having information about the table columns.
  • One of the major problems if CALS tables do not work is, that the amount of <colspec> elements and <entry> does not match the value of the attribute [columns] in <tgroup>.
  • Within <entry> most of the paragraph level elements are allowed.
Note
It is highly recommended to insert <thead>. This creates a table heading which is repeated on each page, if a pagebreak falls into the table.


4.1.6. Parameter tables

User Definable Parameters
For structured documentation of individual numerical and/or alpha-numerical requirements, so-called parameters are available. They have the following structure:
Figure 19: Structure of prms
* parameter
* long-name
* short-name
* description
* parameter characteristics
* condition
((* absolute value and tolerance [image] or
* minimum, typical, maximum value [image] )
* unit) or
* text
The following representation example can be drawn from this structure:
<short-name> UB
Parameter structure
 |  | <prm-char>
Element: <long-name> | Element: <short-name> | Element: <min> | Element: <typ> | Element: <max> | Element: <abs> | Element: <unit> | Element: <tol>
Operating voltage | UB | 10,8 |  | 14,2 |  | V |
 |  |  |  |  | 13,5 | V | 5 %
Colour of housing |  | red, green and blue
Function state |  | active
  • Defined Parameters
    There are many pre-defined parameters in the MSR DOC DTD. The only difference between them and user defined parameters is that the designation (long-name element) of the parameter is pre-defined.

For definition of an alpha-numerical value.
For definition of a typical value or value range.
For definition of an exact setting or measurement value.


4.2. Predefined Document Structure

The automotive systems to be described with the help of this DTD possess very different specifications. Because of this, the specification of a particular topic, e.g. "acoustic characteristics" might not make sense or might only become necessary later on, depending on the project.
This situation was also taken into account in the DTD through the elements "<na>" (not applicable), "<tbd>" (to be defined) and "<tbr>" (to be resolved) as shown in Principles of information acquisition. This is a mechanism is located at each element on chapter level and works like a check list. A user has to make a statement for each topic.
Figure 20: Principles of information acquisition
If a certain topic is not applicable it has to be marked with <na>. If it is applicable it can be marked with either with <tbd> which indicates that someone has to do a job, or it can be marked with <tbr> which indicates that a specification already exists but it hasn't yet been included, or a detail specification can be defined.
The elements <na>and<tbr> can be described with a short description. Within the element <tbd> the persons responsible for the definitions that have to been made can be specified with <team-member-ref>s. The schedule for the definitions can be defined within <schedule>.


4.3. Project Data

Registering and documenting development of a MSR system is project-oriented, whereby there may be several versions of the product data of a project. The projects can be combined with the help of main projects. This can be defined within <overall-project> by a <label> an a short description in <desc>. Each project is assigned to a maximum of one main project.
The documentation and continuation of project phases occurs in versions. We differentiate between active versions, the data of which can still be modified, and fixed versions, the data of which can no longer be modified. New versions can be designed on the basis of a fixed version. New versions can reuse complete fixed versions of a document or even parts of such a document. This is illustrated by the following figure:
Figure 21: Structure of <project-data>
Project data can be described by a PDM system in an integrated SGML-Editor and PDM environment. This is information on the current project and possibly the main project. Company-specific details about the project can be specified in <general-project-data> on the following items:
System overview <system-overview> | This chapter can be used to define information about a global system, e.g. a certain car model.
Order justification <reason-order> | This may be used to specify information about the reasons for the order of the described component resp. for making the specification of such a component.
Objectives <objectives> | This chapter can be used to specify information about the project objectives. E.g. "Development and system release of the engine-managment-system for the model NEW-BEETLE"
Models <sample-spec> | This structure is used to define development samples like A-,B-,C-,D-sample. These samples represent the results of the different development phases.
Variant specification <variant-spec> | This section is used to specify all variant definitions and their corresponding variant characteristics. See also 4.5. Variant Concept.
Limits to other projects <demarcation-other-projects> | This chapter is used to describe the demarcation to other projects.
Parallel developments <parallel-design> | This can be used to give an overview of the work in parallel projects.
Integration capability <integration-capability> | In this chapter requirements on the capabilities of integration in other systems can be described.
Acceptance conditions<acceptance-cond> | This chapter is used to define the general conditions for the acceptance of the described components.
Schedule and plans <project-schedule> | This chapter is used to define the project-schedule, e.g. project milestones, dates, time limits etc.
Purchasing conditions <purchasing-cond> | This is used to define purchasing conditions like amount of devices per year, delivery times, storage quantities, etc. .
Protocols, minutes of meeting <protocols> | This is the place where project minutes and other arrangements can be mentioned.
Handed over documents and data<dir-hand-over-doc-data> | This is the directory of the handed over documents and data.
Additional project specifications<add-spec> | Any kind of additional project description which can't be described with the chapters mentioned above.


4.4. Administrative Data

Since the respective companies explode the interchange DTD into fragments and use it for the respective acquisition DTDs (perhaps in different departments), the administrative dataappears in many places in the DTD. Each of these places can be used as such a fragment(see below).
Figure 22: Support of DTD fragmentation through administrative data
The operating model is
  • The document respectively the fragment is written in a certain language which can be defined in the element <language>. This element can be used to control a SGML system, e.g. to set the correct prefix strings for elements.
  • The DTD can be configured for the multilingual operation. In this case <language> contains the language of the origin document. All languages used in a document have to be defined within <used-languages>, that is each language is defined with a <l-10>-element which contains the full language name and in the Attribute [l] the short language name (see 4.6. Multilinguality).
  • The document (or the fragment) is handled in all companies participating in the project.
  • The data management in the various companies is different. For that reason, each participant can enter information about their document management facilities in <company-doc-info>:
    <doc-label>
    this is the label under which the document is managed in the company denoted by <company-ref>
    <private-code>
    allows to transport company specific information in a private notation. This is the place, where for example PDMS (Product Data Management Systems) can place pointers and document ids required to resynchronize after a document exchange.
    <entity-name>
    It might be the case that each participating company uses a different fragmentation strategy. In order to support this, <entity-name> can receive information useable by a split utility which creates the desired fragments out of the entire document.
  • If a new release of the document or the fragment is given, each participating site may use a specific scheme for revision numbers. For that reason, each <doc-revision> can receive <company-revision-info> which holds the participant specific information for the actual document revision.
    It is up to a semantical check utility to keep sure that there is only one entry per company.
  • nevertheless, the actual revision is initiated by one individual denoted by <team-member-ref> at one certain point of time denoted by <date>.
  • Finally the modifications made in that revision are stored in <modifcations> where the actual <change> as well as the <reason> for that change is notified. If possible, the change can be located by <xref>.
  • For each <modifcation> the attribute [type] determines, if the change is made to the document only (doc-related) or to the subject of the document (content-related).


4.5. Variant Concept

Especially in the automotive sector there is a multiplicity of different variants of a part type. Normally there is not only one variant documented in the system requirements respectively the product specification of such part types.
To understand the implementation of the variant concept in the MSR DTDs, first some definitions have to be made:
Variant Characteristic
Characteristics that lead to a new variant e.g. engine, product line, country, etc. Characteristics are defined in <variant-char>. The characteristics have to be subdivided in three classes. These are:
  • characteristics which lead to a new subject number(<variant-char [type="new-part-number"]>). For this only the existence of such a characteristic is enough to establish a new subject number for this variant!
  • characteristics which don't lead to a new subject number (<variant-char [type="no-new-part-number"]>).
  • characteristics which lead to a new subject number according to shaping.
Variant Definition:
Definition of several variants with their variant characteristics for a part type.
Variant:
A variant of a part type is defined through the values of it's variant characteristics.
Variant Coding:
Allocation of all variant definitions to their corresponding subject- and drawing- numbers and the respective development versions.


4.6. Multilinguality

The MSR DTDs can be configured for multilingual operation. To use the multilingual DTD configuration the DTD switch "multilinguality : YES or NO" have to be set.
The description of multilingual texts is made through multiple terminal elements that is multiple elements with content of #PCDATA. Multilingual elements get one of the additional language elements <l1>,<l2>, <l3>,<l4>,<l10> to build an aggregate of terminal elements. These language elements provide an attribute [l] where the language of this element can be specified. The content of the attribute [l] have to be defined as two-letter lower-case symbols according to the [Code for the representation of names of languages;ISO639::1988((E/F));;Part1;]
Figure 23: Multilingual Paragraph


5. Übersicht Changes

Structure Principles
5. Übersicht Changes

[snt] Structural Fundamentals of Networks


5.1. Übersicht zu Second version with new application profile

geplant für ???
Lösungen in Second version with new application profile
Name | Art | Thema | Status | Prio | MT | aufgetreten in | S.
cmt-text |  | sw-compu-method-text with description | PASSED |  |  | 5.6. Übersicht zu Meeting 12.12.96 | ->
resp.obj |  | Assignment of responsibilities for objects | PASSED |  |  | 5.6. Übersicht zu Meeting 12.12.96 | ->


5.1.1. Notes

Contents of this chapter:
  • 5.1.1.1. [cmt-text] sw-compu-method-text with description
  • 5.1.1.2. [resp.obj] Assignment of responsibilities for objects


5.1.1.1. [cmt-text] sw-compu-method-text with description

<sw-compu-method-text> can now be documented in detail by using <desc> within <sw-compu-method-value-pair >.
Migration
No migration required


5.1.1.2. [esp.obj] Assignment of responsibilities for objects

5.1.1.2. [resp.obj] Assignment of responsibilities for objects

<admin-data> is now allowed on < net-port-variant>


5.2. Übersicht zu First version with bug-fixes

geplant für 06.02.98
Requests zu First version with bug-fixes
Name | Art | Thema | Status | Prio | MT | geplant für | S.
trans-mode | enh | Model transmission modes to completion | OPEN H. Riegraf to submit a proposal. |  |  | 5.2. Übersicht zu First version with bug-fixes | ->
docrefopt | enh | Document-overriding references optional | PASSED |  |  | 5.2. Übersicht zu First version with bug-fixes | ->
Lösungen in First version with bug-fixes
Name | Art | Thema | Status | Prio | MT | aufgetreten in | S.
trans-mode | enh | Model transmission modes to completion | OPEN H. Riegraf to submit a proposal. |  |  | 5.2. Übersicht zu First version with bug-fixes | ->
basetype |  | SW base type in net-signal | PASSED |  |  | 5.6. Übersicht zu Meeting 12.12.96 | ->
docrefopt | enh | Document-overriding references optional | PASSED |  |  | 5.2. Übersicht zu First version with bug-fixes | ->
init-opt | enh | init-value optional | PASSED |  |  | 5.3. Übersicht zu First version | ->
msg-set | enh | Messages in individual chapters | PASSED | A 1 |  | 5.3. Übersicht zu First version | ->
msgid-mask | enh | Same message from different senders | PASSED |  |  | 5.6. Übersicht zu Meeting 12.12.96 | ->


5.2.1. Notes

Contents of this chapter:
  • 5.2.1.1. enh: [trans-mode] Model transmission modes to completion
  • 5.2.1.2. [basetype] SW base type in net-signal
  • 5.2.1.3. enh: [docrefopt] Document-overriding references optional
  • 5.2.1.4. enh: [init-opt] init-value optional
  • 5.2.1.5. enh: [msg-set] Messages in individual chapters
  • 5.2.1.6. enh: [msgid-mask] Same message from different senders


5.2.1.1. enh: [trans-mode] Model transmission modes to completion

<event-mode> and <cycle-mode> to be removed until formal formal models are available.


5.2.1.2. [basetype] SW base type in net-signal

<net-signal-spec-variant> now has < sw-base-type>.


5.2.1.3. enh: [docrefopt] Document-overriding references optional

The potential document-overriding references to be optional and assigned a label. MSRNET.DTD can therefore be used autonomously by this.


5.2.1.4. enh: [init-opt] init-value optional

<init-value> is now optional in < net-signal-spec-variant>


5.2.1.5. enh: [msg-set] Messages in individual chapters

<memory-layout> is now renamed in <net-message-layout >.
Network messages can now be grouped in <net-message-set>s. The grouping is intended for messages having the same contents and serves to group the documentation.
If such an entity is read into a non-standardized database (i.e. the <short-name> of the < net-message-set> are allocated to the <net-message>), then the <short-name > serves as the criterion for changing groups when restoring a MSRNET entity.


5.2.1.6. enh: [msgid-mask] Same message from different senders


5.3. Übersicht zu First version

geplant für 18.11.97
Requests zu First version
Name | Art | Thema | Status | Prio | MT | geplant für | S.
non-can |  | Extension to non-CAN networks | OPEN |  |  |  | ->
sw-var-abgl |  | Agreement between MSRSW variables and MSRNET signals | OPEN |  |  |  | ->
init-opt | enh | init-value optional | PASSED |  |  | 5.2. Übersicht zu First version with bug-fixes | ->
msg-set | enh | Messages in individual chapters | PASSED | A 1 |  | 5.2. Übersicht zu First version with bug-fixes | ->
Lösungen in First version
Name | Art | Thema | Status | Prio | MT | aufgetreten in | S.
ctrl-mode | enh | Where is controller mode specified | PASSED |  |  | 5.6. Übersicht zu Meeting 12.12.96 | ->
var-trans | bug | Variants in transmission spec. | PASSED |  |  | 5.6. Übersicht zu Meeting 12.12.96 | ->


5.3.1. Notes

Contents of this chapter:
  • 5.3.1.1. enh: [ctrl-mode ] Where is controller mode specified
  • 5.3.1.2. bug: [var-trans] Variants in transmission spec.


5.3.1.1. enh: [ctrl-mode ] Where is controller mode specified

<adress-mode> is now renamed to < identifier-type> which can take the values standard or extended.
<node-variant> now has <protocol-conformance > to capture the level of conformance the node provides.


5.3.1.2. bug: [var-trans] Variants in transmission spec.

<transmission-spec> is no longer variant-dependent.


5.4. Übersicht zu Introduction of Net-Ports

geplant für 12.6.96
Requests zu Introduction of Net-Ports
Name | Art | Thema | Status | Prio | MT | geplant für | S.
Netport-Node | enh | Handling nodes with several inflexible net-ports | PASSED |  |  | 5.5. Übersicht zu Meeting 22.8.96 | ->


5.5. Übersicht zu Meeting 22.8.96

geplant für 22.8.96
Lösungen in Meeting 22.8.96
Name | Art | Thema | Status | Prio | MT | aufgetreten in | S.
Netport-Node | enh | Handling nodes with several inflexible net-ports | PASSED |  |  | 5.4. Übersicht zu Introduction of Net-Ports | ->


5.6. Übersicht zu Meeting 12.12.96

geplant für 12.12.96
Requests zu Meeting 12.12.96
Name | Art | Thema | Status | Prio | MT | geplant für | S.
gateway |  | How will gateway functionality be handled | OPEN |  |  |  | ->
multi-arch | enh | Support of multi-architecture networks | OPEN BMW, VW, Porsche to be discussed further |  |  |  | ->
net-class | enh | Network-protocol classes | OPEN |  |  |  | ->
supersignal |  | Supersignal | OPEN |  |  |  | ->
basetype |  | SW base type in net-signal | PASSED |  |  | 5.2. Übersicht zu First version with bug-fixes | ->
cmt-text |  | sw-compu-method-text with description | PASSED |  |  | 5.1. Übersicht zu Second version with new application profile | ->
ctrl-mode | enh | Where is controller mode specified | PASSED |  |  | 5.3. Übersicht zu First version | ->
msgid-mask | enh | Same message from different senders | PASSED |  |  | 5.2. Übersicht zu First version with bug-fixes | ->
resp.obj |  | Assignment of responsibilities for objects | PASSED |  |  | 5.1. Übersicht zu Second version with new application profile | ->
seg.na | enh | Segmentation is not always entered | PASSED | A1 |  |  | ->
var-trans | bug | Variants in transmission spec. | PASSED |  |  | 5.3. Übersicht zu First version | ->
lnk-sw |  | How are signals allocated to SW variables | REJECTED |  |  |  | ->


6. Changes

Structure Principles
6. Changes

Contents of this chapter:
  • 6.1. [gateway] How will gateway functionality be handled
  • 6.2. [multi-arch] Support of multi-architecture networks
  • 6.3. [net-class] Network-protocol classes
  • 6.4. [non-can] Extension to non-CAN networks
  • 6.5. [supersignal] Supersignal
  • 6.6. [sw-var-abgl ] Agreement between MSRSW variables and MSRNET signals
  • 6.7. [trans-mode] Model transmission modes to completion
  • 6.8. [basetype] SW base type in net-signal
  • 6.9. [cmt-text] sw-compu-method-text with description
  • 6.10. [ctrl-mode ] Where is controller mode specified
  • 6.11. [docrefopt] Document-overriding references optional
  • 6.12. [init-opt] init-value optional
  • 6.13. [msg-set] Messages in individual chapters
  • 6.14. [msgid-mask] Same message from different senders
  • 6.15. [ Netport-Node] Handling nodes with several inflexible net-ports
  • 6.16. [resp.obj] Assignment of responsibilities for objects
  • 6.17. [seg.na] Segmentation is not always entered
  • 6.18. [var-trans] Variants in transmission spec.
  • 6.19. [lnk-sw ] How are signals allocated to SW variables


6.1. [gateway] How will gateway functionality be handled

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | Rauleder | OPEN |  |  | 5.6. Übersicht zu Meeting 12.12.96 |
Sache | How are gateway functions described? How do links come to MSRSW.DTD entities. Is only the signal-signal arrangement to be considered here?
Begründung | Background is the issue of the different degree of formalization in the stress field between MSRSW.DTD MSRNET.DTD MSWDOC.DTD
Beschlossene Lösung
Still to be resolved


6.2. [multi-arch] Support of multi-architecture networks

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | BMW H. Kramer | OPEN BMW, VW, Porsche to be discussed further |  |  | 5.6. Übersicht zu Meeting 12.12.96 |
Sache
The possibility must be given to describe networks that work using different protocols and architectures. The following shall thereby be observed
Gateway | The entire network consists of several descriptions with separate signal definitions. The sub-networks are ignorant of each other.
Repeater | The entire network has one consistent description and one common signal definition.
Begründung
Scenarios occur in practice, in the first instance however gateways
Lösungsansatz 1
Several network specifications to be introduced, whereby one common sub-network component occurs. The sub-network components can reference the common network. Without sub-networks, the common network is the entire network. The following structure is thus given.
   common-network
      net-signal-spec
      net-message-spec
   sub-net*
      net-signal-spec
         net-signal
         net-signal-ref
      net-message-spec
         net-message
         net-message-ref
A model for gateways shall be found in addition to this.


6.3. [net-class] Network-protocol classes

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | BMW H. Krammer | OPEN |  |  | 5.6. Übersicht zu Meeting 12.12.96 |
Sache | The possibility must be given to specify the protocol type for a network.
Begründung | There are different types of networks


6.4. [non-can] Extension to non-CAN networks

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | AG-Net 18.11.97 | OPEN |  |  | 5.3. Übersicht zu First version |
Sache | The extension to non-CAN networks must be included.
Begründung | Non-CAN can also be given


6.5. [supersignal] Supersignal

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | BMW H. Krammer | OPEN |  |  | 5.6. Übersicht zu Meeting 12.12.96 |
Sache | The possibility must be given to group different types of signals.
Begründung | Improvements in the documentation.
Lösungsansatz 1
Solution analogous to <port-groups> in MSRDOC
Lösungsansatz 2
Signals can be grouped using a cluster. This is one element with several indicators to <net-signal>.


6.6. [sw-var-abgl ] Agreement between MSRSW variables and MSRNET signals

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | AG Net 18.11.97 | OPEN |  |  | 5.3. Übersicht zu First version |
Sache | Agreement between <sw-variable > and <net-signal-spec-variant> in future versions
Begründung | These data are closely related.
Siehe auch | OTHER: 6.8. [basetype] SW base type in net-signal


6.7. [trans-mode] Model transmission modes to completion

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | Riegraf, Aufdermauer | OPEN H. Riegraf to submit a proposal. |  |  | 5.2. Übersicht zu First version with bug-fixes | 5.2. Übersicht zu First version with bug-fixes
Sache | The transmission modes <event-mode> bzw. < cycle-mode> should be modeled to completion
Begründung | In order that a formal handling in tools can follow
Beschlossene Lösung
Initially remove the informal <event-mode> and < cycle-mode>. A formal proposal will be included when proposed.
Notes
1.1.1


6.8. [basetype] SW base type in net-signal

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | BMW H. Krammer | PASSED |  |  | 5.6. Übersicht zu Meeting 12.12.96 | 5.2. Übersicht zu First version with bug-fixes
Sache | The possibility should be provided to give a base type for a signal
Begründung | It cannot be determined from the conversion formula alone whether this can be a value with a prefixed sign.
Beschlossene Lösung
<sw-base-type> to be included in <net-signal-spec-variant >.
Matching between <sw-variable > and <net-signal-spec-variant> must be possible in future versions
Notes
1.1.1


6.9. [cmt-text] sw-compu-method-text with description

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | BMW H. Krammer | PASSED |  |  | 5.6. Übersicht zu Meeting 12.12.96 | 5.1. Übersicht zu Second version with new application profile
Sache | <sw-compu-method-text> should have a further element <cmt-desc> where additional information on a certain value can be described.
Begründung | It can be that <cmt-text> is a formal text that shall be described in detail in the documentation.
Beschlossene Lösung
An element <desc> will be introduced within < sw-compu-method-value-pair>.
Notes
2.1.0


6.10. [ctrl-mode ] Where is controller mode specified

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | Riegraf / Weichel | PASSED |  |  | 5.6. Übersicht zu Meeting 12.12.96 | 5.3. Übersicht zu First version
Sache | Statement from Dipl.-Ing. T. Riegraf on <identifier-type>: A better designation is "CAN-data transmission format". This is a very global definition for a bus and can be " Standard-Format" or "Extended-Format". Specifications from the Bosch company exist for this. It can be defined in the case of "Extended-Format " for each control unit/CAN controller, whether it is "active" or "passive ", i.e. whether communication with the Extended-Format is possible or not. Clarification is required as to where this definition is made.
Begründung | A gap is otherwise given
Beschlossene Lösung
  • <adress-mode> to be renamed in <identifier-type >. This can take the value of standard or extended.
  • <node-variant> receives a new element <protocol-conformance> and can take the following values
    CAN-2.0A-active
    CAN conformance 2.0ACAN Conformance 2.0A
    CAN-2.0B-active
    CAN conformance 2.0BCAN Conformance 2.0B
    CAN-2.0B-passive
    CAN conformance 2.0B passiveCAN Conformance 2.0B passive
    NA
    The network described knows no conformity classes. The value can therefore not be filled out.
Notes
1.1.0


6.11. [docrefopt] Document-overriding references optional

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | Klein | PASSED |  |  | 5.2. Übersicht zu First version with bug-fixes | 5.2. Übersicht zu First version with bug-fixes
Sache | Document-overriding references should be optional.
Begründung | Simplifies the handling in simple author environments. Resolution by the AG-DTD
Beschlossene Lösung
The potential document-overriding references to be optional and assigned a label. MSRNET.DTD can therefore be used autonomously by this.
Notes
1.1.1


6.12. [init-opt] init-value optional

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | riegraf | PASSED |  |  | 5.3. Übersicht zu First version | 5.2. Übersicht zu First version with bug-fixes
Sache | <init-value> shall be optional.
Begründung | The information cannot always be provided, especially in the case of block modes.
Beschlossene Lösung
<init-value> is now optional in < net-signal-spec-variant>
Notes
1.1.1


6.13. [msg-set] Messages in individual chapters

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | Kramer | PASSED | A 1 |  | 5.3. Übersicht zu First version | 5.2. Übersicht zu First version with bug-fixes
Sache | The possibility should be given to categorize network messages such that these can be distributed amongst individual chapters for printed documentation.
Begründung | Better overview of the documentation
Beschlossene Lösung
A group concept will be introduced for messages < net-message-set>. "Group" was not used since "group" groups conceptually identical types together. It is only for MSRSYS.DTD that the possibility "group" is given for ports to use contents and logical grouping.
Notes
1.1.1


6.14. [msgid-mask] Same message from different senders

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | BMW H. Krammer | PASSED |  |  | 5.6. Übersicht zu Meeting 12.12.96 | 5.2. Übersicht zu First version with bug-fixes
Sache | It must be possible to allocate several senders to one message. These differ in variants and identifiers.
Begründung | It is possible that the same message can be sent by different senders and differing identifiers. The receivers respond to a masked identifier. Example is a window lifter where each contact pushbutton depresses the same message. Furthermore, variant-handling is to be supported.
Lösungsansatz 1
Two mechanisms are provided for determining the identifier for a specific < net-message>:
  • Discrete information on the identifiers <net-message-identifiers >.
  • A computation of the identifiers (<calc-net-message-identifiers >) as the sum of a basis and <Identifier-base-adress > and an offset that is given in the node. The < msg-identifier-offset> is given by the respective <sender >. This procedure is used preferentially for network management and diagnostics.
Beschlossene Lösung
A group concept will be introduced for messages as well < net-message-group>
Notes
1.1.1


6.15. [ Netport-Node] Handling nodes with several inflexible net-ports

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | ?? | PASSED |  |  | 5.4. Übersicht zu Introduction of Net-Ports | 5.5. Übersicht zu Meeting 22.8.96
Sache | It is currently such that each net-port appears as a separate node in the segmentation.
Begründung | This is inflexible. The relation between net-ports is is not transparent in the network document.
Lösungsansatz 1
The mention of net-ports in the node could be dispensed with. The net-port could be included in the segmentation when referencing the node.
Beschlossene Lösung
Net-ports have been set up within nodes (refer to 3.2.2.2. Description of network nodes). The segmentation refers to the< net-node-port>s.
Notes


6.16. [esp.obj] Assignment of responsibilities for objects

6.16. [resp.obj] Assignment of responsibilities for objects

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | BMW H. Krammer | PASSED |  |  | 5.6. Übersicht zu Meeting 12.12.96 | 5.1. Übersicht zu Second version with new application profile
Sache | It should be possible to explicitly assign the responsibility for certain sub-trees.
Begründung | The participants must know their partners.
Lösungsansatz 1
<Admin-data> will be propogated further, a <team-member-ref> will introduced in < company-doc-info>.
Beschlossene Lösung
References to objects will be introduced for the <Team-Member>s, similar to <role>.
<admin-data> will also be introduced for <net-node-variant >
Notes
2.1.0


6.17. [seg.na] Segmentation is not always entered

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | BMW. H. Krammer | PASSED | A1 |  | 5.6. Übersicht zu Meeting 12.12.96 |
Sache | Segmentation should also permit <na>. In principle, this should be executed such that differing scenarios can be covered, similar to msrsw.
Begründung | It can be that the network shall be described in abstract terms, i.e without segmentation. This is currently not permitted by the DTD.
Beschlossene Lösung
<setmentation> and its twins will receive < na> etc.


6.18. [var-trans] Variants in transmission spec.

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
bug | Weichel | PASSED |  |  | 5.6. Übersicht zu Meeting 12.12.96 | 5.3. Übersicht zu First version
Sache | <transmission-spec> is not yet variant-dependent even though this is contended by 3.4. Variants
Begründung | Inconsistency
Beschlossene Lösung
Documentation corrected in 3.4. Variants.
Notes
1.1.0


6.19. [lnk-sw ] How are signals allocated to SW variables

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | Rauleder 18.1.97 | REJECTED |  |  | 5.6. Übersicht zu Meeting 12.12.96 |
Sache | How do the links come to MSRSW.DTD entities. Is only the signal-signal allocation to be considered here?
Begründung | We have no possibility of executing this arrangement.
Lösungsansatz 1
<net-sig-var-assocs > will be introduced in parallel to <locs>. The arrangement of net-signal to the variable can be described here at a suitable point.
Pro
  • Resolves the given problem
Con
  • This information is more a part of the software and should be described here.
Beschlossene Lösung
To be handled with MSRSW.DTD.


A. Glossary

Structure Principles
A. Glossary

Sampling point
Determines as a network parameter the point in time when the bit is sampled.
Address mode
The address mode for a message can be "Standard" or "Extended".
ASAP
The ASAP interfaces have been agreed by the "Study Group for the Standardization of Application Systems (ASAP)". Members of this study group are the German autombile manufacturers and companies in the supplier industry.
Basic CAN
CAN Chip; possesses only one sender and one reception memory.
Baud rate
Operating mode
Transmission parameter for a message that describes for instance, whether remote operation is present or not.
Bit stuffing
A technique that is used for resynchronization in bit-oriented network protocols. A change in the flank is caused by the inclusion of an additional complementary bit according to a defined number of bits of the same level. The additional bit is removed again by the receiver.
BRT
Abbreviation for baud rate prescaler, defined as the number of BTL cycles.
BTL cycles
Abbreviation for Bit Timing Logic cycle; a sampling frame is formed via the baud rate prescaler from the oscillator frequency of the chip. This auxiliary cycle (BTL cycle) serves to determine the time segments for the bit timing.
Byte order
Network parameter that defines the sequence for the higher-value and the lower-value byte within a word. Since the processor manufacturers "Intel" and "Motorola" have made contrary definitions for the byte order, the values "Intel", "Motorola forwards" and "Motorola backwards" are possible for this parameter.
CAN
Abbreviation for Controller Area Network
CAN High Speed
Network link and network medium according to [To be defined;ISO 11898;DIS;;Entire document;], amongst others, characterized by a data rate of between 125 Kbit/s and 1 Mbit/s.
CAN Low Speed
Network link and network medium according to [To be defined;ISO 11519-1;DIS;;Entire document;], amongst others, characterized by a data rate of up to 125 Kbit/s
CAN conformance 2.0A
CAN with an identifier length of 11 bits (standard).
CAN conformance 2.0B
CAN with an identifier length of 29 bits (Extended). All CAN controllers that can process CAN 2.0B telegrams are also capable of processing standard frame, i.e. to both send as well as to receive.
CAN conformance 2.0B passive
CAN controllers that only process standard frames and that are passive in their response to CAN version 2.0B. These ignore extended telegrams according to version 2.0B.
CANdb
CAN data basis
CRC
Abbreviation for Cyclic Redundancy Check; included the error code over all previous possitions. The CRC checksum is used for fault detection yet not for fault corrections.
CSMA/CD
Abbreviation for Carrier Sense Multiple Access with Collision Detect
DLC
Abbreviation for Data Length Code; gives the length of the message in bytes.
Readiness to receive following power-down
Transmission parameter for a message that describes the time following a power- down message, during which a reaction to incoming messages is possible even though sending is not possible. It is prevented by this that a component goes into the sleep mode when a message is en route to the component.
Readiness to receive following power-up
Transmission parameter for a message that describes the point in time following power-up, as of when the message can be received.
Error value
Value for a signal if a fault is detected and the actual information can no longer be transmitted.
Full CAN
CAN chip that, unlike the basic CAN, includes several sending and receiving storage devices.
Initialization value
Value of a signal before the first reception in the receiver.
Node
A network node that includes any participant or branch of the network.
Latency time
Transmission parameter for a message that describes the transmission time in the network. The latency time is the time by which the the sending process for a message can be delayed by messages having a higher priority. In technical terms, the latency time is the period of time between setting the TransmitRequestBit and receiving the AckMessage. The maximum latency time for this message can thus be specified in the message.
Multiplex-signal group
Several signal groups can be grouped together in a multiplex-signal group that can be identified by a respective (group) value. A receiver of the message can filter out the signal group intended for the receiver from this value.
Network EMC design
Description of the designs or set-up of the network with regard to electromagnetic compatibility.
net-signal group
...
net-signal class
The net-signal class classifies the net-signals according to application signals and network management signals.
OSEK
To be defined
Phase relation to other messages
Transmission parameter for a message that describes whether there is a phase relation with other messages present.
Physical range
Permissible range for the physical (external) values for a signal that are given on account of the conversion from the network-internal presentation.
Quartz frequency
The frequency of the quartz or quartz oscillator connected to the CAN controller.
RTR
Abbreviation for Remote Transmission Request; a flag for identification of a data request. A sender is requested to tranmsit a corresponding data telegram as the response.
Transmission conditions
Transmission parameter for a message that describes the transmission conditions.
Readiness to transmit following power-up
Transmission parameter for a message that describes the point in time following power-up as of which the message can be sent.
SJW
Abbreviation for Synchronization Jump Width that is given in BTL cycles. Defines the maximum amount by which the CAN controller may extend or shorten both major segments of the bit time.
Sleep/wake-up mechanism
A mechanism that puts the network into a " dormant state" with low power consumption (sleep) and re-activates this as required (wake-up); e.g. for a central-locking system.
SLIO
Abbreviation for Serial Linked I/O.
Memory layout
For a message, the memory layout is a (graphical) supplement to the description of signal lists and multiplex-signal groups that describes the signal distribution of a message in the memory.
Conversion
Procedure, on how to convert the network-internal presentation (internal values) of a signal in the corresponding physical values (external values).
Prescaler
Or baud-rate prescaler; for generation of the BTL-cycle frequency from the quartz frequency.
Cycle time
(Also cycle tolerance time), transmission parameter for a message that describes the tolerance time for a message for a cyclic control system (cycle sending of the message).


B. Bibliography

Structure Principles
B. Bibliography

CAN-ER-Modell
Analysis of the CAN database, documents of the Bosch company,
CAN-Contoller Area Network, Principles and Practice
CAN Controller Area Network, Principles, Protocols, Modules, Applications


C. Legend of structural grafiphics

Structure Principles
C. Legend of structural grafiphics

Figure 24: Meaning of symbols in the structural graphics


D. Alternatives considered for linking control unit and network

Structure Principles
D. Alternatives considered for linking control unit and network

Contents of this chapter:
  • D.1. Linking via individual signals
  • D.2. Use of nomenclature conventions
  • D.3. Introduction of a net-signal element
  • D.4. Referencing network elements for signal definition


D.1. Linking via individual signals

In case a), the individual signals of the network connection (e.g. Low, High, Shield) are specified and applied to the corresponding ports for the connection specification.
For b), only one net-signal is applied and applied to all ports.


D.2. Use of nomenclature conventions

The names for the individual lines for the network are handled as normal signals. The arrangement of the control-unit signals to a network is by means of a nomenclature convention, in which the designation for the network appears again in the signal name as the prefix. Signals for a network CANx could take the names CANx_High, CANx_Low, and CANx_Shield.
This variant does not suffice since in case c) in Linking network and control unit , it is not clear which lead-through is applied to the network.
These nomenclature conventions can also be realized in that signals in < signal> receive an additional element < net-name> to allocate the individual signals to the network.


D.3. Introduction of a net-signal element

A new type of signal definition is introduced in addition to the existing signal description. This can be made within the scope of the signal specification < signal-spec> or within a signal group < signal-group>.
Figure 25: Arrangement of net-lines to the control unit (SG)
a)
<signal-group>
   <signals>
   <net-lines>
      <long-name>
      <short-name>
      <variant-def-refs>

b)
<signal-spec>
   <signal-groups>
   <net-lines>
a)
<signals> and <net-lines> are equivalent to the extent that means are already available for the <net-lines > for designation of the network. That <signals> are included in < net-lines> is attributable to the convention whereby elements occurring several times should have an envelope element. From the purely logical viewpoint, there is a large number of <signal >s occuring as for <signals > as well. Three <signal-group>s for example must be applied for one network.
<signal-group>
  <signals>
  <net-lines>
     <long-name>           Designation of the network
     <short-name>          Designation of the network
     <signals>
  <signal-spec-variants>
b)
This approach is equivalent to a). Three <signal-group >s are to be aplied here as well. The hierarchy is however somewhat flatter.
<signal-group>
   <signals>
   <net-lines>
       <net-line>
          <long-name>      Signal designation
          <short-name>     Signal designation
          <net-name>        should consequently be <net-ref>

                           is basically an indicator from the
                           MSRDOC-entity in the MSRNET entity.
          <variant-def-refs>
c)
This variant describes the network closed. Three < signal-group> elements are applied for one network here as well, though these are grouped as one. This variant has the disadvantage that signals are defined at different points. If then all signals of one component shall be searched, then the search must be carried at several locations. This is in contrast to the advantage that one network can be described completely as such.
<signal-spec>
   ...
   <busses>
      <bus>
         <long-name>       Bus designation
         <short-name>
            <signal-groups>
This variant does not address the problem in figure b) either Linking network and control unit . Additional elements that modify the signal name would be needed to cover this.


D.4. Referencing network elements for signal definition

Network signals are treated as signals. The identification as a network signal is by means of a reference to a new network element.
<architecture>
   <buses>
      <bus>
         1
         2    <-
                |
<signal> -> <bus-ref>
Networks are introduced within the architecture. Alternatively, each signal can be assigned exactly to one network. This is a further development of D.3. Introduction of a net-signal element in that the <net-name> here is standardized.
<architecture>
  <buses>
     <bus>
        <long-name>
        <short-name>
        <desc>
        <add-info>

<signal>
   <bus-ref>
Does not resolve the problematical nature of Linking network and control unit case b).


E. Defining ranges of values

Structure Principles
E. Defining ranges of values

Contents of this chapter:
  • E.1. Node type
  • E.2. Topology type
  • E.3. Net-signal class


E.1. Node type

TBD


E.2. Topology type

TBD


E.3. Net-signal class

TBD


F. Zusätzliche Anmerkungen zum Dokumentstand 2 am 23.7.98

Structure Principles
F. Zusätzliche Anmerkungen zum Dokumentstand 2 am 23.7.98

Status dieses Dokument: cd


Technical Terms

Structure Principles
Technical Terms

Code
content-related
crpctmt.wmf
doc-related
ENTITY
extended, extended
mm crp.sgm
scale="0.5"
SDATA
standard, standard
Control elements
OK
Material
plastic
wood
Organisations
ASAP
ISO TC22 SC3 WG1
OSEK
MEDOC Networks
OTHER
CAN_LOW
power- down message
Application signal
Low
net-signal group
Network management signal
power-down message
Standard-Format, Standard-Format
CALS table
CAN_HIGH
CAN_SHIELD
Extended-Format, Extended-Format
Extended-Format , Extended-Format
High
ISO
ncoi-2
ncoi-3
Shield
thing
Parameter
Cycle time
KFZW
Latency
Products
MSRNET.DTD
CAN-controller
control unit
MSRNET.DTD
MSRSW.DTD
ABS control unit
control unit, control unit
control unit, control unit, control unit
control unit
engine control unit
MetaMorphosis
MSRDOC
MSRDOC.DTD, MSRDOC.DTD, MSRDOC.DTD
MSRNET.DTD, MSRNET.DTD, MSRNET.DTD, MSRNET.DTD, MSRNET.DTD
MSRREP.DTD
MSRSW.DTD, MSRSW.DTD
MSRSYS DTD
MSRSYS.DTD
MSWDOC.DTD
Networks, Networks
vehicle system
SGML Attributes
category
columns
f-id-class
filename
fit
height
id-class
item-label-pos
l, l
notation
notetype
scale
type, type, type
type="new-part-number"
type="no-new-part-number"
type=other
user-defined-type, user-defined-type
width
SGML Elements
long-name
net-node-port
short-name
interface-circuit
segment
driver-concept
long-name
signal-group
abs
add-info
admin-data
company-doc-info
connection-comp-spec-1
cycle-mode
identifier-type
msg-identifier-offset, msg-identifier-offset, msg-identifier-offset
multiplex-signal-set
multiplexer
na
net-architecture
net-emc-design
net-interface-prms
net-line
net-lines
net-message, net-message
net-message-group
net-message-set, net-message-set
net-message-signals
net-name
net-node
net-node-port, net-node-port
net-node-port-ref
net-port-variant
net-signal
net-signal-class
net-signal-spec-variant, net-signal-spec-variant
net-topology-spec
part-ref
signal, signal
signal-group
signal-spec
sw-base-type
sw-compu-method-value-pair
sw-units
abs, abs
acceptance-cond
add-info
add-spec, add-spec
address-mode
admin-data, admin-data
adress-mode, adress-mode
architecture
baudrate
bitsize, bitsize
btl-cycles
byte-order
c-code
calc-net-message-identifiers , calc-net-message-identifiers , calc-net-message-identifiers
change
chapter, chapter
chapters
cmt-desc
cmt-text
coded
colspec
company-doc-info
company-ref
company-revision-info
connection-comp-ref
connection-comp-spec-1
cycle-mode
cycle-time
date, date
def-list
demarcation-other-projects
desc, desc, desc, desc
dir-hand-over-doc-data
dlc
doc-label
doc-revision
driver-concept
e, e
entity-name
entry
error-value
error-values
event-mode, event-mode
fail-save-concept
figure, figure
file
formula
ft
general-net-spec, general-net-spec
general-project-data
generic-math
graphic, graphic
ident-sample
identifier
identifier
Identifier-base-address
Identifier-base-adress , Identifier-base-adress
identifier-type
identifier-type
ie
indent-sample
init-value, init-value, init-value
integration-capability
interface-circuit
item-label, item-label
l-10
l1
l10
l2
l3
l4
label
label
labeled-list, labeled-list
language
latency-time
list
list type="unnumbered"
list type="numbered"
locs
long-name, long-name, long-name, long-name, long-name
max
memory-layout
min
modifcation
modifcations
multiplex-entry
multiplex-signal-list
na, na
ncoi-1
net-architecture
net-block-modes
net-diag-spec
net-emc-design
net-error-handling
net-init-spec
net-interface-prms
net-interface-spec
net-interface-spec
net-lines, net-lines
net-lines
net-message, net-message
net-message
net-message-desc
net-message-identifiers , net-message-identifiers , net-message-identifiers
net-message-layout
net-message-layout , net-message-layout
net-message-set, net-message-set
net-message-signal, net-message-signal
net-message-signals
net-message-signals , net-message-signals
net-message-spec, net-message-spec, net-message-spec
net-mgmt-spec
net-name
net-node-port
net-node-variant
net-nodes
net-oper-spec
net-oper-spec
net-port-ref
net-sig-var-assocs
net-signal, net-signal, net-signal
net-signal-class
net-signal-group
net-signal-group
net-signal-spec
net-signal-spec
net-signal-spec-variant, net-signal-spec-variant, net-signal-spec-variant
net-signal-spec-variant , net-signal-spec-variant
net-toplogy-spec
netline-desc
network-spec
node-type
node-variant, node-variant
note
number
objectives
offset
overall-project
p, p
parallel-design
part-type-spec
phase-relations
phys
port-groups
position
powerdown-receive-time
powerup-receive-time
powerup-transmit-time
private-code
prm-char
prms, prms
project-data
project-schedule
protocol-conformance
protocol-conformance
protocols
publisher
purchasing-cond
reason
reason-order
receivers, receivers
role
row
sample-point
sample-rate
sample-spec
schedule
segment
segment-length
segmentation
segmentation-desc
segments
sender
sender , sender , sender
setmentation
short-name, short-name, short-name, short-name, short-name
short-name , short-name
signal
signal-class
signal-group
signal-group
signals
signals
sjw
sjw
state
std, std
sub, sub
subtitle
sup
sw-base-type
sw-compu-method-ref
sw-compu-method-text, sw-compu-method-text
sw-compu-method-value-pair
sw-compu-methods
sw-compu-methods
sw-data-dictionary
sw-limits
sw-variable , sw-variable
sync-edge
system-overview
table, table
tbd
tbody
tbr
Team-Member
team-member-ref, team-member-ref, team-member-ref
tex-math
text
tfoot
tgroup
thead
tol, tol
topic-1
topic-2
topology-type
transmission-spec, transmission-spec, transmission-spec, transmission-spec
tt, tt
tt type=control-element
tt type=material
tt type=organisation
tt type=sgml-attribute
tt type=sgmltag
tt type=code
tt type=other
tt type=prm
tt type=product
tt type=sgmltag
tt type=state
tt type=tool
tt type=variable
typ
unit
used-languages
variant-char
variant-def-ref
variant-def-refs
variant-spec
verbatim, verbatim, verbatim
xdoc
xfile
xref, xref, xref, xref
State
dormant state
participators
power-up
active, active
auxiliary nodes
intel
motorola
motorola backwards
motorola forwards
passive , passive
power-up
revised
STD
XTD
Tools
MSRNET.DTD
MSRDOC.DTD
MSRNET.DTD
authoring system
cut & paste
entity manager
LaTeX
MSRDOC.DTD, MSRDOC.DTD, MSRDOC.DTD
MSRDOC.DTD
MSRNET.DTD
PDMS
Product Data Management System
rendition system
rendition system, rendition system
semantical check utility
SGML processing system
SGML Application
SGML editor
SGML formatter
SGML processing system
SGML processing system
SGML tool
split utility
TeX
Variables
MMRC
N
Register occupation
TL


Untitled

The network-line identifiers are not explicitely normed. It is the task of a semantic check to ensure consistency by the network-line identifiers for the differing net-ports.


Untitled

The offsets refer principally to the beginning of the message and are summated (i.e. beginning at 0)


Untitled

Only of relevance for cyclic control systems, hence optional.


Untitled

Not yet realized in 11.0.


Untitled

not content orientated information


Untitled

In that respect, it is recommended to nest not more than four levels.


Untitled

the other option would be to have an extra element for each chapter level


Untitled

Actually it is up to the rendition system if the sequence is expressed as numbers or as letters.


Untitled

This can be used for systems which can't display graphics.


Untitled

it is recommended to enter the term always in singular and create plurals outside of the element (see second example).


Untitled

Note that in MSRDOC.DTD there are means to formally describe variables to be used if the system software of an ECU is specified.


Untitled

For definition of a typical value or value range.


Untitled

Formal referencing of net-lines between msrdoc and msrnet was dispensed with for pragmatic reasons since the same designations are used as a rule in all entities.


Untitled

All node-ports of a node must reference the same part. The reference to the part has not be "taken out" of the node-ports in spite of this. This would have meant a distrubition for the definition of the the semantics for the reference. This should be avoided for handling reasons. It is the task of a semantic check to determine any inconsistencies.


Untitled

The application of the standard parameters model was dispensed with here in order to enable the presentation of segmentation as a closed table.


Untitled

The example has to be updated.


Untitled

A specific parameter model should really be used for each of these parameters. The MSR standard parameters model has however been used in the interests of generalization. If this is executed in future as the architectural form, then more specific model models could be used. The user must however first select the correct model, or the author environment should propose the correct model.


Untitled

An extension of the DTD at a later point in time could provide the structural basis for automation of this.


Untitled

The term network signal is used here for differentiation in MSRDOC from the term signal.


Untitled

The structure is similar to that for a signal group in MSRDOC.DTD


Untitled

This is a general principle for MSR


Untitled

Some of this information is optional, in order to be able for instance, to apply name and size to these block mode signals as well.


Untitled

Such messages are e.g., command messages by which a certain function within a control unit can be triggered from different nodes. Further examples are network management and diagnostic messages.


Untitled

It still has to be clarified where this is defined.


Untitled

The term net-signal is not used here as this appears elsewhere in another context in conjunction with messages.


Untitled

This solution was not chosen and an example is therefore not given.


Untitled

A modification is used that does not permit use of a part-type reference.


Untitled

This hierarchy is possible as a variant-dependent structure at all levels. Variant-dependencies should however only be introduced at the highest level.


Untitled

it is not really easy to distinguish between these two elements. As a rule of thumb, one might say that the semantics of def-list is stronger than the one of labeled-list which is more layout oriented. The items of def-list can be referenced by xref which is not possible with the items of a labeled-list.


Untitled

This is the way how this document is prepared. It is visible in the sgml source.


Untitled

But many people read footnotes first - so put the interesting stuff in footnotes


Untitled

For definition of an exact setting or measurement value.


Untitled

For definition of an alpha-numerical value.


Untitled

Gateways initially propose a compilation of several networks in one entity. The gateway functionality is however realized in a specific system or unit, and is therefore to be described in this performance or software.


Untitled

Such a description of a formal nature is not be found in currently applicable specifications either.


Untitled

DTDs with the same version of the MSR application profile