2

   

Arrangement of network and control units

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)


Figure 3: Linking network and control unit

bus02.wmf


The following cases are covered in Linking network and control unit:
a)

The control unit is linked to the network via an n-conductor single feeder (e.g. CAN_High, CAN_Low, CAN_Shield).

b)

The control unit is linked to the network via an n-conductor multiple feeder. This illustrates a branched feeder or star point of the network in the control unit. This case is supported by allowing multiple <net-port>s within <network>.

c)

A control unit can furthermore be connected to different networks (e.g. gateway). Versions of the interfaces to each of the networks according to case a) and b) are possible here. This is supported by allowing multiple <network>s within <network-spec>.

b) and c)

These cases can occur at the same time. They are supported by allowing multiple <network>s each allowing <net-port>s.

2.2

   

Description of network connections in MSRSYS DTD

The definition of network related <port>s, <signal>s and <connection>s in an MSRSYS instance is done in the same way as with any other.

An element <network-spec> (refer to Structure of Network Specification in MSRSYS ) is introduced in <architecture> in the MSRSYS DTD in order to be able to specify the network related information for the component types. This modelling was chosen for the following reasons:
  •  
  •  

    The targets for referencing from MSRNET DTD instances are concentrated in <network-spec>.

  •  
  •  

    Network-related characteristics of signals can be concentrated here without a general expansion of the contents model of <signal>. This allows to describe network related signalsFOOTNOTE just as any other signal and avoids an oversized content model for <signal>.

    A possible semantic overlapping with <signal-class> is intentionally accepted since the latter has been designed for company and process-specific classifications.

    This models the component-specific network characteristics. This implies the explicit arrangement of <signal> (which is the component signal) and <net-line> (which reflects the sense of the wire with respect to the network, e.g. CAN_High)FOOTNOTE.

    Multiple <net-port>s are possible in order to be able to cover Linking network and control unit case b). In this case, the network is connected to a component more than once by using several ports. These ports are connected within the component. It can thereby be assumed that the involved ports are named differently. This is done by introducing specific relation of <net-line> and <signal> per <net-port> as shown in Summary of net-port, net-line, and signal name in the MSRSYS instance according to the given example.
    Figure 4: Structure of Network Specification in MSRSYS

    network-spec.eps



    Figure 5: Structure of Network Port in MSRSYS

    net-port.eps


    Example for an entry in the MSRSYS instance

    A MSRSYS DTD instance (for control unit 2 in Exemplarily scenario) looks in principle like the following (the counterpart in the MSRNET DTD instance is given in Example of a description for the network topology):
    Figure 6: Exemplarily scenario

    bus05.eps


    Table 1: Summary of net-port, net-line, and signal name in the MSRSYS instance according to the given example

    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

    <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>