Strukturelle Grundlagen

MSR-Teilprojekt MEDOC

Strukturelle Grundlagen
Bereich: Netzwerke
[SNT]
Version: 1.1.2
Dieses Dokument beschreibt die strukturellen Grundlagen der MSR-Entwicklungsdokumentation MEDOC für den Bereich Netzwerke. Die Beschreibung kann auch als Anleitung zur Erstellung einer strukturierten Entwicklungsdokumentation verwendet werden.


I. Einleitung

Strukturelle Grundlagen
I. Einleitung

Dieses Dokument beschreibt die strukturellen Grundlagen der MSR-Entwicklungsdokumentation MEDOC für den Bereich Netzwerke. Die Beschreibung kann auch als Anleitung zur Erstellung einer strukturierten Entwicklungsdokumentation verwendet werden.
Die Beschreibung erfolt u.a. in Strukturgrafiken, die aus der prototyp-Implementierung der MSRNET.DTD gewonnen wurden. Die Bedeutung der Symbole ergibt sich aus Bedeutung der Symbole in den Strukturgrafiken.
An dieser Stelle wird daraufhingewiesen, daß MSR keine Normung betreibt und auch in Zukunft keine betreiben wird. In der Anforderungsdokumentation und in der Entwicklungsdokumentation MEDOC werden lediglich Inhalt und Struktur von bestehenden Normen/Hausnormen verwendet. MEDOC soll die Möglichkeit bieten, die Inhalte der (inter-)nationalen Normen und Hausnormen sowie nicht genormte, für die Beschreibung von Systemen relevante Daten in einer Entwicklungsdokumentation abzulegen.
Der vereinfachte Sachverhalt ist in der nachfolgenden Tabelle dargestellt:
Abgrenzung der MEDOC-Aktivitäten von den Normungsaktivitäten
MEDOC | Norm | Hausnorm | keine Norm
Struktur | Struktur der Normen kann von MEDOC abgebildet werden | Struktur der Hausnormen kann abgebildet werden | Vom MSR-Kreis abgestimmt
Inhalt | Stammdaten aus Normen übernommen | Stammdaten können spezifisch ergänzt werden |
MEDOC erlaubt es, die Inhalte und die Struktur der internationalen, nationalen und der Hausnormen aufzunehmen. Grundlage für die Strukturdefinitionen sind die zum Zeitpunkt der Drucklegung gültigen Normen. Darüber hinaus können Datenbestände, die durch keine Norm abgebildet werden, mittels MEDOC erfaßt werden. Die Struktur der Daten wird vom MSR-Kreis abgestimmt, die Inhalte werden keinerlei Normung unterworfen. Tabellen und Tabelleninhalte, die sich in diesem Dokument befinden, sind nur als Beispieldaten anzusehen. Da für die einzelnen Konsortiumsfirmen unterschiedliche Grenzwerte gelten, wurden die Inhalte z.T. den internationalen Normen entnommen.


II. Ziel und Vorgehen

Strukturelle Grundlagen
II. Ziel und Vorgehen

Ziel der Arbeitsgruppe MEDOC-Netzwerke ist es, ein Format für alle möglichen Busbeschreibungen bzw. Beschreibungen von Netzwerken zu definieren. Die Datenmodellierung wird zunächst anhand des CAN vorgenommen (Full-CAN und Basic-CAN). Nach Abschluß der Datenmodellierung wird die Übertragung auf weitere Netz-Formate vorgenommen.


1. Allgemeines

Strukturelle Grundlagen
1. Allgemeines

Die bislang modellierte MSRDOC.DTD bildet in einer Instanz stets ein System inklusive der zugehörigen Steuergeräte bzw. des zugehörigen Steuergerätes ab (z.B. ein ABS-System). Da ein Netz i.a. mehrere Steuergeräte in unterschiedlichen Systemen verbindet (z.B. das Motor-Steuergerät und das ABS-Steuergerät), ist es sinnvoll, die Beschreibung von Netzwerken in einer eigenständigen DTD abzubilden.
Abbildung 1: MSRDOC.DTD und MSRNET.DTD
Für die Beschreibung der Ankopplung der Steuergeräte an das Netz sind instanzübergreifende Links notwendig. In Anlehnung an die MSRDOC.DTD ist ein entsprechendes Variantenkonzept vorgesehen, so daß die Bezüge zwischen Instanzen der MSRDOC.DTD und der MSRNET.DTD variantenbezogen beschrieben werden können. Die baureihenbezogene oder baureihenübergreifende Beschreibung von Netzen muß möglich sein.
Besitzt ein Fahrzeugsystem mehrere Netzsysteme parallel, so sind diese in entsprechend vielen Instanzen der MSRNET.DTD zu beschreiben. Damit wird eine klare Trennung (technisch wie auch organisatorisch) der verschiedenen Netzen erreicht [image] .
Für Simulationszwecke erhält der Zulieferer vom Hersteller die Beschreibung der gesamten Netztopologie in den betroffenen Baureihen.
Eine Verknüpfung zwischen der MSRNET.DTD und den MSRDOC.DTDs ist über die Kurzbezeichnung der Netzsignale denkbar.

Gateways legen zunächst eine Zusammenfassung mehrerer Netze in einer Instanz nahe. Die Gateway-Funktionalität wird aber in einem konkreten System bzw. Gerät realisiert, und ist daher in dessen Verhalten bzw. Software zu beschreiben.


2. Zuordnung von Netz und Steuergerät

Strukturelle Grundlagen
2. Zuordnung von Netz und Steuergerät

Inhalt dieses Kapitels:
  • 2.1. Anforderungen
  • 2.2. Beschreibung von Netzwerk-Anschlüssen in MSRDOC


2.1. Anforderungen

Die Kopplung eines Steuergerätes mit einem oder mehreren Netzen kann auf unterschiedliche Art und Weise erfolgen. In Kopplung von Steuergerät und Netz sind drei dieser Möglichkeiten aufgezeigt:
a) | Stichleitung und Netzsystem
b) | Abzweig bzw. Sternpunkt im Steuergerät (mehrfach n-adrige Leitungen)
c) | Verbindung zu mehreren Netzen (z. B. Gateway)
Allen drei Ansätzen ist gemeinsam, daß die Zuordnung auf Basis von Steuergeräte-Signalen zu Namen von Netzleitungen erfolgt [image] . Eine Zuordnung zu Steuergeräte-Port erscheint nicht flexibel genug im Hinblick auf die Verwendung einer Netz-Beschreibung für mehrere Steuergerätefamilien.
Abbildung 2: Kopplung von Steuergerät und Netz
Während in Teilabbildung a) das Steuergerät über eine n-adrige Stichleitung (z.B. CAN_High, CAN_Low, CAN_Shield) mit dem Netz verbunden ist, sind bei b) diese n-adrigen Signalleitungen mehrfach vorhanden. Im Fall b) befindet sich im Steuergerät ein Abzweig oder Sternpunkt des Netzes.
Weiterhin kann ein Steuergerät, wie in Teilabbildung c), mit verschiedenen Netzen verbunden sein (z.B. Gateway). Dabei sind die Ausführungen der Schnittstellen zu den jeweiligen Netzen nach a) und b) möglich.
Für die Beschreibung der Kopplung von Steuergerät und Netz wurden neben der gewählten Lösung auch die Alternativen in D. Betrachtete Alternativen zur Ankopplung von SG und Netz betrachtet. Es wird die Lösung in 2.2. Beschreibung von Netzwerk-Anschlüssen in MSRDOC) eingesetzt.

Hier wird nicht der Begriff Netz-Signal verwendet, da dieser im Zusammenhang mit den Botschaften in anderer Bedeutung wieder auftritt.


2.2. Beschreibung von Netzwerk-Anschlüssen in MSRDOC

Unter der <architecture> in MSRDOC.DTD wird ein neues Element <network-spec> (s.Netzwerk-Anschlüsse in MSRDOC ) eingeführt, um die Netzankopplungen des Bauteiltyps definieren zu können. Diese Modellierung wurde aus folgenden Gründen gewählt:
  • Die Ziele für eine (semantisch auszuführende) Referenzierung aus MSRNET.DTD Instanzen werden in <network-spec> konzentriert.
  • Netzbezogene Eigenschaften und Zusammenhänge von Signalen können hier konzentriert werden, ohne das Inhaltsmodell von < signal> generell auszuweiten und gleichzeitig Netzsignale wie alle anderen Signale behandeln zu können.
Eine mögliche semantische Überschneidung mit <signal-class> wird bewußt in Kauf genommen, da letzere für fimen- bzw. prozeßspezifische Klassifizierungen konzipiert ist.
Abbildung 3: Netzwerk-Anschlüsse in MSRDOC
Beispiel der Eingabe in MSRDOC - Instanz
Eine MSRDOC.DTD-Instanz (für Steuergerät 2 in Beispielszenario) sieht im Prinzip wie folgt aus (das Gegenstück in der MSRNET.DTD-Instanz ist in 3.2.2.4. Beispiel für Beschreibung der Netzwerk - Topologie dargestellt):
Abbildung 4: Beispielszenario
<part-type>
   <long-name>Steuergerät 2</long-name>
   <short-name>SG2</short-name>
...

 <architecture>
   <scheme-diagrams> ...
   <interface-spec>  ...
   <signal-spec>     ...
   <network-spec>
    <networks>
      <network><long-name>CAN-Bus der Motorsteuerung</>
        <short-name>MBUS</>
        <desc>Dieser Bus behandelt primär die Motorsteuerung</>
        <net-ports>
           <net-port>
              <long-name>motorraumseitiger Anschluß</>
              <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>fahrgastraumseitiger Anschluß</>
              <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>
Zusammenstellung von Net-Port, Net-Line, und Signalname
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
Diese Variante modelliert die komponentenspezifischen Netz-Eigenschaften komplett. Dazu gehört auch die explizite Zuordnung von Komponenten-Signalname und Netzleitung [image] .
Netz-Ports werden eingeführt, um Kopplung von Steuergerät und Netz Fall b) abdecken zu könenn. In diesem Fall liegt auf einer Komponente das Netz mehrfach (also auf mehreren Ports) auf und wird innerhalb der Komponente verbunden. Der Sternpunkt liegt also innerhalb der Komponente. Dabei ist davon auszugehen, daß die Netzleitungen an den jeweiligen Pins unterschiedlich benannt werden. Daher muß eine Netz-Port spezifische Zuordnung von Netzleitungsname zu komponenteninternen Signalnamen erfolgen. Diese Zuordnung kann im Prinzip in zwei Varianten erfolgen:
  • Zuordnung von Netzleitung und Komponenten-Signalname pro Netz-Port
  • Zuordnung von Netz-Port und Komponenten-Signalname pro Netzleitung

Diese Lösung wurde nicht gewählt und ist daher auch nicht als Beispiel aufgeführt.
Die Netzleitungs-Bezeichner werden nicht explizit normiert. Es ist Aufgabe einer semantischen Prüfung sicherzustellen, daß die Bezeichner der Netzleitungen der verschiedenen Net-Ports konsistent sind.


3. Strukturierung der MSRNET.DTD

Strukturelle Grundlagen
3. Strukturierung der MSRNET.DTD

Abbildung 5: Grundsätzlicher Aufbau der MSRNET.DTD
Die Beschreibung eines CAN-Netzwerkes gliedert sich in folgende Teile:
  • Lang- und Kurzbezeichnung (<long-name> <short-name>)
  • Verwaltungsinformation < admin-data>
  • Projektinformationen <project-data >
  • Allgemeine, globale Beschreibung <general-net-spec> 3.1. Allgemeine Beschreibung
  • Netz-Architektur (<net-architecture>) (Topologie, Kabel, Netzparameter, Treiberkonzept, Netz-EMV-Design)
  • Netzwerkbetrieb (<net-oper-spec>) (Datenverkehr, Signale, Botschaften).
Eine grobe Veranschaulichung in Form eines Schichtenmodelles (ähnlich dem ISO/OSI-Referenzmodell für Kommunikation) bietet die folgende Abbildung:
Abbildung 6: Schichtenmodell für Zeitangaben/Ü;bertragungszeiten
Die erste Version der DTD enthält keine formale Beschreibung von geforderten Übertragungszeiten [image] .
Zunächst sind bei der Botschaftsbeschreibung lediglich die Parameter Latenzzeit und Zykluszeit vorgesehen, innerhalb der Abbildung also Parameter in der unteren Schicht.

Eine solche Beschreibung formaler Art findet sich nicht in den derzeit vorliegenden Lastenheften.


3.1. Allgemeine Beschreibung

In <general-net-spec> können allgemeine, globale Beschreibungen zu einem Netz abgelegt werden. Darin wird z.B. beschrieben, wofür das Netz eingesetzt wird (Antriebsstrang, Komfortbereich ...).


3.2. Netz-Architektur

Die Beschreibung der Netz-Architektur (< net-architecture>) teilt sich in die Themen "Verbindungskomponenten" <connection-comp-spec-1>, "Topologie" (< net-topology-spec>) und "Netz-Interface" <net-interface-spec >auf. Hier können sowohl feste wie auch freie Parameter des Netzes bzw. der Netz-Hardware beschrieben werden.
<add-spec> dient zur Angabe weiterer, in der DTD nicht direkt vorgesehener Spezifikationen.


3.2.1. Verbindungskomponenten

Bei den Verbindungskomponenten werden die verwendeten Netz-Kabel als < connection-comp-spec-1> (siehe Struktur für Verbindungskomponenten) ähnlich wie in MSRDOC.DTD beschrieben. .
Abbildung 7: Struktur für Verbindungskomponenten

Es wird eine Abwandlung verwendet, die keinen part-type-ref zuläßt.


3.2.2. Topologie

Innerhalb der Topologie (<net-toplogy-spec > siehe Struktur der Topologie) können die Art, die Knoten sowie die Segmentierung dokumentiert werden. Die Art (<topology-type>) kann Ausprägungen wie "Ring", "Stern", "Bus", "Bus mit Stichleitung" oder auch "Mischform" besitzen und muß durch eine Grafik ergänzt werden.
Weiterhin werden Knoten <net-nodes> (3.2.2.1. Netzleitungen) und Segmentierung <segmentation> (3.2.2.3. Beschreibung der Segmentierung) beschrieben.
Abbildung 8: Struktur der Topologie


3.2.2.1. Netzleitungen

Das Netzverdrahtung selbst besteht in der Regel aus mehreren Leitungen (hier Netzleitung) genannt. Beispiel hierfür ist ( CAN_LOW, CAN_HIGH, CAN_SHIELD). Diese Signale können ebenfalls unter Topologie (<net-lines>) beschrieben werden. Die Beschreibung umfaßt zuminest einen <short-name > und einen <long-name>. Optional kann eine ausführliche Darstellung (<netline-desc>) mit Tabellen, Grafiken usw. gegeben werden .
In den MSRDOC.DTD - instanzen werden diese Netzleitungen den komponenteninternen Signalen zugeordnet (vgl 2.2. Beschreibung von Netzwerk-Anschlüssen in MSRDOC, < net-line>). Damit ist es möglich, die Konsistenz zu überprüfen [image] (Semantik).
Eine explizite Zuordnung dieser Leitungen zu den Adern (z.B. über Farbe) des Verbindungskabels erfolgt nicht, da dieses nicht fomell hierarchisiert beschrieben wird.

Auf eine formale Referenzierung der netlines zwischen msrdoc und msrnet wurde aus pragmatischen Gründen verzichetet, da i.d.R. in allen Instanzen gleiche Bezeichnugnen verwendet werden.


3.2.2.2. Beschreibung der Netzknoten

Die Beschreibung des Knotens besteht aus:
< short-name> | Nummer bzw. Kurz-Bezeichnung des Knotens im Netzwerk
< long-name> | Bezeichnung des Knotens im Netzwerk
<node-type> | Die Knotenart dient zur Unterscheidung von Teilnehmer und Hilfsknoten . Hilfsknoten nehmen nicht am Netzverkehr teil sondern dienen nur zum physikalischen Aufbau bzw. Darstellung der Topologie.
< net-node-port>s | Hier werden die Ports des Knotens definiert (vgl. 2.2. Beschreibung von Netzwerk-Anschlüssen in MSRDOC). Diese Stelle ist die einzige Stelle, an der referentielle Konsistenz zu MSRDOC.DTD - Instanzen gewährleistet werden muß. Das <net-node-port> referenziert aus der MSRDOC.DTD instanz das Bauteil (< part-ref>) sowie den dazu gehöringen Bauteiltyp enthaltenen Netport (<net-port-ref>).
<interface-circuit > | Angaben zur Abschlußbeschaltung. Hier kann <interface-circuit > verwendet werden. Diese Information ist redundant zur MSRDOC.DTD. Die Struktur wird vorgehalten, um eine MSRNET-Instanz autonom beschreiben zu können. Außerdem kann hier die gesamte Abschlußbeschaltung eines Knotens angegeben werden, wohingegen bei MSRDOC.DTD nur die Beschaltung eines einzelnen Pins beschrieben ist. Die Angabe ist optional.

Alle node-ports eines Knotens müssen das selbe part referenzieren. Trotzdem wurde die Referenz auf das Part nicht aus den node-ports "ausgeklammert". Dies hätte bedeutet, daß die Semantik der Referenz verteilt definiert ist. Dies sollte aus Handhabungsgründen vermieden werden. Es ist Aufgabe einer semantischen Prüfung, eventuelle Unstimmigkeiten festzustellen.


3.2.2.3. Beschreibung der Segmentierung

Die Segmentierung kann sowohl allgemein (durch Text und Grafik) (<segmentation-desc>) dokumentiert werden, als auch formell (<segments>) spezifiziert werden.
In <connection-comp-ref> kann die standardmäßige Kabelart für das Netz angegeben werden.
Die formelle Spezifikation beschreibt alle Segmente (<segment>):
  • Segmente können variantenspezifisch angegeben werden (spezifiziert in <variant-def-refs>).
  • Angaben zu Start-Knoten, Ende-Knoten, Segment-Längen (<segment-length>) sowie Kabelarten der einzelnen Segmente. Die Start- und Ende-Knoten werden durch Referenzierung auf einen der < net-node-port>s des betroffenen Knotens festgelegt (< net-node-port-ref>).
  • Als Segment-Länge ist die Angabe in der SI-Einheit Meter vorgesehen [image] .
  • Es kann eine segmentspezifische Kabelart angegeben werden (<connection-comp-ref>, falls diese von der standardmäßigen Kabelart für das Netz abweicht.

Hier wurde auf den Einsatz des Standard-Parameter-Modell verzichtet, um die Darstellung der Segmentierung als geschlossene Tabelle zu ermöglichen.


3.2.2.4. Beispiel füBeschreibung der Netzwerk - Topologie

3.2.2.4. Beispiel für Beschreibung der Netzwerk - Topologie

Das folgende Beispiel [image] entspricht dem Beispiel in Beispielszenario:
<net-topology-spec>
  <net-topolgy-type>bus</>
  <connection-comp-ref connection-comp="nyfaz"></>
  <nodes>
    <node>
       <long-name>Steuergerät 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>Teilnehmer</>
    </node>
    <node>
       <long-name>Steuergerät 2</>
       <short-name>SG2</>
       <node-variants>
         <node-variant>
           <node-ports>
             <node-port id=sg2.msa>
               <long-name>Motorraum-CAN</>
               <short-name>MSA</>
               <net-port-ref netport="SG2/MSA">
             </node-port>
             <node-port id="sg2.fg">
               <long-name> Fahrgastraum-CAN</>
               <short-name>FG</>
               <net-port-ref netport="SG2/FG">
             </node-port>
         </node-variant>
       </node-variants>
       <node-type>Teilnehmer</>
    </node>
    <node>
       <long-name>Steuergerät 3</>
       <short-name>3</>
       <node-variants>
         <node-variant>
           <node-ports>
             <node-port id=sg3.can>
               <long-name>Steuergerät3</>
               <short-name>can</>
               <net-port-ref netport="SG3/can</>
             </node-port>
             <node-type>Teilnehmer</>
         </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>

Das Beispiel muß noch aktualisiert werden.


3.2.3. Beschreibung der Netzwerk - Schnittstellen

Den zweiten Teil der Hardware-Dokumentation bildet das Netz-Interface (<net-interface-spec>). Diese beschreibt das Treiberkonzept (<driver-concept>), die global für alle Teilnehmer festgelegten Netzparameter (< net-interface-prms>), Hinweise zum Netz-EMV-Design (< net-emc-design>) sowie ergänzende Angaben (<add-info >).
Die Beschreibung des Bus-Interfaces oder auch der Bus-Ankopplung besteht aus einem Bus-globalen physikalischen Datenblatt (requirements); entweder gemäß ISO Norm CAN High-Speed ISO Norm CAN Low-Speed oder oder individuell ausgeprägt. Auf Teilnehmerseite (SG-Seite) ist dann festzulegen, welcher Chip eingesetzt wird (<part-type-spec > in MSRDOC).
Abbildung 9: Strukture des Netzinterfaces
Die global für alle Teilnehmer festgelegten Netzparameter werden als Parametertabelle (<net-interface-prms >) erfaßt [image] :
<baudrate>
die Baudrate (Baudrate) in Hz. Es muß <abs>-<tol> - Modell verwendet werden. Die Toleranz ist in % anzugeben.
Die Baud-Raten-Programmierung für den CAN-controller leitet sich aus den obigen Parametern ab, ist allerdings nicht eindeutig (z.B. Registerbelegung). Es handelt sich hier um eine Beschreibung der Bus-Ankopplung auf einer höheren Ebene (höher als die physikalische Ebene). Man kann auch von der Parametrisierung des CAN-Controllers sprechen. Diese ist beim CAN-Controller bzw. beim Steuergerät zu dokumentieren.
<sample-point>
der Abtastzeitpunkt eines einzelnen Bits in einer Botschaft. Die Angabe erfolgt in Prozent. (<abs>-<tol> - Modell, ohne ausgefüllte Toleranz)
Dies ist eine optionale Angabe.
Dieser Parameter gibt an, zu welchem Zeitpunkt ein Bit abgetastet wird. Er wird in Prozent der Bitzeit (Übertragungszeit für ein Bit) angegeben. Ein typischer Wert ist 75 %.

<sample-rate> | Anzahl der Abtastungen pro Bit Dies ist eine optionale Angabe.
<btl-cycles> | Anzahl der BTL-Zyklen BTL-Zyklen als ganzzahligen Wert, d.h. die Auflösung eines Bit (< abs>-<tol> - Modell ohne ausgefüllte Toleranz). Dies ist eine optionale Angabe.
<sjw> | SJW (Synchronization Jump Width) als ganzzahligen Wert (SJW). Der Parameter "SJW" (Syncro Jump Width) wird ebenfalls in Prozent der Bitzeit angegeben. Dies ist eine optionale Angabe.
<sync-edge> | Synchronisationsflanke, anzugeben als <text> - Parameter Dies ist eine optionale Angabe.
Die <baudrate> ist Bus-global. Die Parameter <sample-point>, <sjw > und <btl-cycles> sind i.A. global, können in Ausnahmefällen aber auch teilnehmerspezifisch sein Diese Sonderfälle sind nicht in MSRNET.DTD abgedeckt..
Innerhalb des optionalen Treiberkonzepts (< driver-concept>) können die zu verwendenden bzw. die verwendeten Treiberbausteine beschrieben werden.
Ebenso wie für das Treiberkonzept steht für die Beschreibung des Netz-EMV-Designs eine freie Struktur (<net-emc-design >) zur Verfügung.
Bei den ergänzenden Angaben (< add-info>) sind ggf. weitere physikalische Parameter wie Flankensteilheit, Eingangswiderstand und Signalpegel zu dokumentieren.

für jeden dieser Parameter sollte eigentlich ein spezifisches Parametermodell verwendet werden. Im Interesse der Verallgemeinerung wurde jedoch auf das MSR-Standardparametermodell zurückgegriffen. Wenn dieses künftig als Architectural Form ausgeführt wird, könnten spezifischere Modelle verwendet werden. Zunächst muß der der Benutzer das richtige Modell wählen, bzw. die Autorenumgebung sollte das richtige Model vorschlagen.


3.3. Netzwerkbetrieb

Dieser Abschnitt (<net-oper-spec >) beschreibt den Datenverkehr für unterschiedliche Netzwerkdienste (3.3.1. Allgemeines Netzwerkmanagement sowie die Verhaltensweisen bei Auftreten von Fehlern (3.3.3. Fehlerbehandlung) u. ä. Die Strukturen der blockweisen Datenübertragung werden in 3.3.5. Blockübertragungsmodi dargestellt.
Abbildung 10: Strukturierung des Netzwerkbetrieb
Eine Botschaft, die über CAN verschickt wird, enthält in der Regel mehrere Signale. Dabei ist es möglich, daß ein Signal in mehr als einer Botschaft verwendet wird. Daher werden zunächst die Signale (<net-signal-spec>, s. 3.3.6. Netz-Signale), und dann die Botschaften (<net-message-spec> s. 3.3.7. Botschaften) spezifiziert.


3.3.1. Allgemeines Netzwerkmanagement

Innerhalb dieses Punktes (<net-mgmt-spec >) können Angaben u.a. zu Sleep-/Wake-up-Mechanismen gemacht werden. Falls das Netz in verschiedenen Betriebsarten laufen kann, so sind diese (und die Übergangsmechanismen) ebenfalls hier zu beschreiben.
Alle Netz-Signale und Botschaften, die für das Netzwerkmanagement eingesetzt werden, müssen als Netzsignale (<net-signal> bzw. <net-message>) (vgl. 3.3.6. Netz-Signale) spezifiziert werden. Dazu dient insbesondere die Zusammenfassung der Einzelbotschaften zu Gruppen (vgl. 3.3.7. Botschaften). Bei der Erstellung von Dokumentationen sollten Netzwerkmanagementsignale als eigenständige Tabelle (CALS-Tabelle) zusammengefaßt werden [image] .
Ersatzwertbeschaffung wird nicht in die Netzwerkbeschreibung (z.B. bei Netz-signalgruppe) aufgenommen, weil diese in der Regel beim Empfänger des Signals auszuführen ist.
Es gibt Aktivitäten bei ASAP und bei OSEK im Bezug auf Standardisierung des Netzmanagements. Zunächst wird daher auf eine formale Modellierung verzichtet, und nur die vorgeschlagene Kapitelstruktur vorgesehen.

eine spätere Erweiterung der DTD könnte die strukturellen Grundlagen für eine Automaitisierung legen.


3.3.2. Initialisierung

Die Initialisierung (<net-init-spec >) beschreibt Dienste und Protokolle, die dazu dienen einen Netzteilnehmer nach Power-up oder Reset in den kommunikationsfähigen Zustand zu bringen.


3.3.3. Fehlerbehandlung

Der Abschnitt <net-error-handling > dokumentiert die Mechanismen für die Fehlerbehandlung.


3.3.4. Diagnose

Der Abschnitt <net-diag-spec> dokumentiert die Mechanismen für die Abwicklung der Diagnose auf dem Netz.


3.3.5. Blockübertragungsmodi

Die Blockübertragungsmodi (<net-block-modes >) beschreiben applikationsspezifische Protokolle (Initialisierung, Diagnose, u. ä.) für den Transfer von Datenpaketen.
Es wird empfohlen, die für die Blockübertragungsmodi verwendeten Botschaften zu referenzieren. Zum Aufbau dieser Botschaften werden ebenfalls Signale verwendet, die über die Netz-Signal-Klasse (< net-signal-class>) besonders gekennzeichnet sind.
Es gibt Aktivitäten bei ISO TC22 SC3 WG1 im Bezug auf Standardisierung der Blockübertragungsmodi. Zunächst wird daher auf eine formale Modellierung verzichtet, und nur die vorgeschlagene Kapitelstruktur vorgesehen.


3.3.6. Netz-Signale

<net-signal-spec > [image] (s. Netz-Signale) spezifiziert die auf dem Netz übertragenen Signale.
Die Netz-Signale sind verwandt mit Variablen in einer Steuergerätesoftware. Aus diesem Grund werden optional Teile des Software Datenlexikons (< sw-units> und <sw-compu-methods>) in die DTD aufgenommen.
Die Netz-Signal-Gruppen <net-signal-group >s dient zur Zusammenfassung von Signalen, die exakt gleiche Eigenschaften haben. Durch die Zusammenfassung in einer Gruppe ist eine redundante Beschreibung nicht mehr notwendig [image] [image] .
Abbildung 11: Netz-Signale
Die Signal-Eigenschaften (<net-signal-spec-variant >) umfassen die folgenden Teile [image] :
<bitsize> | Länge des Signals in Bit
<init-value> | Optionaler Initialisierungswert - Dieser Wert wird gesendet, wenn das zugehörige physikalische Signal noch nicht erfaßt worden ist.
<net-signal-class> | Die optionale Netz-Signal-Klasse (<net-signal-class>) kann " Applikationssignal" oder " Netzwerkmanagementsignal" sein.
<error-values > | Dieser Wert wird gesendet, wenn das zugehörige physikalische Signal aufgrund einer Fehlersituation (z.B. Sensorabfall) nicht zur Verfügung steht. Es können mehrere <error-value>s angegeben werden, um verschiedene Fehlersituationen zu unterscheiden. Die Angabe ist optional.
<sw-limits> | Optionale Angabe des Wertebereich des Signales. Die Angabe kann sowohl in netzinterner (<coded>) als auch physikalischer (<phys>) Darstellung erfolgen.
<sw-compu-method-ref > | Die Umrechnung dokumentiert, wie die netzinterne Darstellung (codierte, bzw. interne Werte) in die zugehörigen physikalischen Werte (externer Werte) umgerechnet wird. Die wird über eine Referenz auf die <sw-compu-methods > dokumentiert. Siehe auch: Strukturelle Grundlagen, Bereich Software Dies ist eine optionale Angabe.
Eine Empfängerliste ist bei der Definition der Netzsignale nicht vorgesehen, da eine solche über die Angaben zu den Botschaften (<receivers> innerhalb <net-message-signals > innerhalb <net-message-spec>) generiert werden kann.

Einige dieser Angaben sind optional, um z.B. auch Block-mode-Signale mit Name und Größe anlegen zu können.
Dies ist ein generelles Prinzip bei MSR
Die Struktur ist ähnlich aufgebaut wie signal-group in MSRDOC.DTD
Zur Abgrenzung gegen signal in MSRDOC wird hier von net-signal gesprochen.


3.3.7. Botschaften

Die Signale auf dem Netz werden in Botschaften zusammengefaßt übertragen. In <net-message-spec> (s. Struktur der Botschaften) können diese Botschaften spezifiziert werden.
Netz Botschaften können in <net-message-set>s zusammengefaßt werden. Die Zusammenfassung ist nicht für strukturell gleiche Botschaften gedacht. Sie dient vielmehr zur dokumentarischen Zusammenfassung.
Abbildung 12: Struktur der Botschaften
Jede Botschaft <net-message > wird variantenabhängig spezifiziert und identifiziert durch < long-name>, <short-name>. Die Beschreibung umfaßt:
<net-message-desc>
HIer hat man die Möglichkeit, die Botschaft in Prosa zu beschreiben.
<identifier>
Dies ist ein Hex-Wert, über den die Botschaft im Netzwerk identifiziert wird.
Für die Bestimmung der Identifier einer konkreten <net-message > (für einen Netzknoten) werden zwei Mechanismen angeboten:
  • Eine diskrete Angabe der Identifier <net-message-identifiers >.
  • eine Berechnung des Identifiers (<calc-net-message-identifiers >) als Summe einer basis und <Identifier-base-adress > und eines Offset, der im Knoten angegeben wird. Der < msg-identifier-offset> wird über beim jeweiligen <sender > angegeben.
    Dies dient zur Beschreibung von struktuell gleichen (abstrakten) Botschaften. Solche Botschaften können erst dann auf dem Bus übertragen werden wenn sie eine eindeutige Zuordnung zu einem Identifer erhalten.
Es besteht eine 1 zu n - Beziehung zwischen <identifier > und <sender>, um Varianten beschreiben zu können (<variant-def-ref>) .
<address-mode>
Der Address-Mode kann "STD" (Standard) oder "XTD" (Extended) sein.
Eine bessere Bezeichnung ist "CAN-Datenübertragungsformat". Dieses ist eine sehr globale Festlegung für einen Bus und kann " Standard-Format" oder "Extended-Format" sein. Hierzu existieren Spezifikationen der Fa.Bosch. Im Fall von "Extended-Format " kann je Steuergerät/CAN-Controller festgelegt werden, ob es/er "aktiv" oder "passiv " ist, d.h. ob es/er das Extended-Format kommunizieren kann oder nicht.
<byte-order>
bezeichnet das Byte-Ordering in der Botschaft. Mögliche Werte sind: motorola, motorola-vorwaerts, motorola-rueckwaerts oder intel
<dlc>
Die Angabe DLC (Data Length Code) (siehe DLC) wird in Byte angegeben und gibt an, wie lang die Botschaft ist. Eine Botschaft kann Lücken haben. Daher kann die Länge nicht aus der Summe der Signal-Längen ermittelt werden.
<net-message-signals>
Die Signale einer Botschaft werden in <net-message-signals > aufgelistet als (<net-message-signal>).Dies ist eine optionale Angabe. <net-message-signal> können entweder direkte <net-signal>s sein und mit einem <offset> versehen werden.
Es kann aber auch gemultiplexte Signale geben. Diese werden als < multiplex-signal-set> spezifiziert, welches einen < multiplexor> spezifiziert mit <offset> [image] und Länge <bitsize> besitzt. In der <multiplex-signal-list> wird in <multiplex-entry > jedem Wert des Multiplexors (<multiplexor-value>) wiederum eine Signal-Liste (<net-message-signals>) zugeordnet. Damit können beliebig verschachtelte Multiplexsignale aufgebaut werden [image] .
Bei jedem Signal einer Botschaft (direkt oder gemultiplext) sind auch die zugehörigen Empfänger <receivers> zu dokumentieren, da diese durchaus von der Botschaft abhängig sein können.
<net-message-layout>
Die Angabe <net-message-layout > ist als optionale, redundante Ergänzung zu der Signalliste (< net-message-signals>) vorgesehen. Dort können vorprozessierte Informationen abgelegt werden, die nicht vom SGML-Formatierer aus den <net-message-signals> abgeleitet werden können. Gültig sind stets die Angaben unter <net-message-signals>.
<sender>
Bezeichnet den Knoten, welcher das Signal sendet.
<transmission-spec>
beschreibt die Übertragungsverfahren der Botschaft. Es gelten folgende Parameter
<powerup-receive-time> | Empfängerbereitschaft nach Power up Empfängerbereitschaft nach Power up Übertragungsparameter einer Botschaft, der den Zeitpunkt nach Power up beschreibt, ab wann die Botschaft empfangen werden kann.
<powerup-transmit-time> | Sendebereitschaft nach Power upEmpfangsbereitschaft nach Power down Übertragungsparameter einer Botschaft, der den Zeitpunkt nach Power up beschreibt, ab wann die Botschaft gesendet werden kann.
<powerdown-receive-time> | Empfangsbereitschaft nach Power down Empfangsbereitschaft nach Power down Übertragungsparameter einer Botschaft, beschreibt die Zeit nach einer Power down Meldung, in der zwar nicht mehr gesendet, aber noch auf eintreffende Botschaften reagiert werden kann. Damit wird vermieden, daß eine Komponente in den sleep mode geht, obwohl gerade eine Botschaft an sie unterwegs ist.
<latency-time> | LatenzzeitLatenzzeit Optionaler Übertragungsparameter einer Botschaft, der die Übertragungszeit auf dem Netz beschreibt. Die Latenzzeit ist die Zeit, um der Sendevorgang einer Botschaft durch höherpriore Botschaften verzögert werden kann. Technisch gesprochen ist die Latenzzeit die Zeitspanne, die zwischen TransmitRequestBit setzen und AckMeldung erhalten liegt. An der Botschaft kann also die maximale Latenzzeit für diese Botschaft spezifiziert werden [image] .
<cycle-time> | ZykluszeitZykluszeit (auch Zyklustoleranzzeit), optionaler Übertragungsparameter einer Botschaft, der die Toleranzzeit einer Botschaft bei zyklischer Steuerung (zyklisches Versenden der Botschaft) beschreibt [image] .
<phase-relations> | Phasenbeziehung zu anderen Botschaften Phasenbeziehung zu anderen Botschaften Übertragungsparameter einer Botschaft, der beschreibt, ob eine Phasenbeziehung zu anderen Botschaften vorliegt.
Abbildung 13: Aufbau der signale in einer Botschaft
Die Konsistenz der eingegebenen Daten ist durch eine semantische Prüfung zu gewährleisten.

nur bei zyklischer Steuerug relevant, daher optional
nur bei zyklischer Steuerug relevant, daher optional
Diese Hierarchie ist auf allen Ebenen variantenabhängig möglich. Variantenabhängigkeiten sollten jedoch nur auf oberster Ebene eingeführt werden.
Die offsets beziehen sich grundsätzlich auf den Botschaftsanfang und werden addiert (beginnen also bei 0)
Es muß noch geklärt werden, wo diese Festlegung stattfindet.
Solche Botschaften sind z.B. Kommandobotschaften mit denen eine bestimmte Funktion innerhalb eines Steuergerätes von verschiedenen Knoten angestoßen wird. Weitere Beispiele sind Netzwerkmanagement- und Diagnosebotschaften.


3.4. Varianten

Variantenabhängigkeiten existieren bei:
  • Knoten (< net-node>)
  • Netinterface< interface-circuit>
  • Netzsegmente (< segment>)
  • Netz-Signal < net-signal>
  • Netz-Signal-Eigenschaften <net-signal-group>
  • Botschaft (< net-message>) wird dann verwendet, wenn die Botschaft variantenabhängig vorhanden ist.
  • Signaleintrag in Botschaft (<net-message-signal>) wird dann verwendet, wenn das Signal variantenabhängig vorhanden ist.
  • Speicherlayout (Aufgabe für AG-DTD %info variantenabhängig könnte man mit <xref> auf Variantendefinition) realisieren.
  • Übertragungsparameter (<transmission-spec>)
  • Für die Bestimmung der Identifier einer einer konreten < net-message> werden zwei Mechanismen angeboten:
    • Eine diskrete Angabe der Identifier <net-message-identifiers >.
    • eine Berechnung des Identifiers (<calc-net-message-identifiers >) als Summe einer basis und <Identifier-base-adress > und eines Offset, der im Knoten angegeben wird. Der < msg-identifier-offset> wird über beim jeweiligen <sender > angegeben. Dieses Verfahren wird vorzugsweise für Netzwerkmanagement und Diagnose verwendet.
    TBD

in 11.0 noch nicht realisiert


4. Übersicht Changes

Strukturelle Grundlagen
4. Übersicht Changes

[snt] Strukturelle Grundlagen Netzwerke


4.1. Übersicht zu Zweite Version mit neuem Anwedungsprofil

geplant für ???
Lösungen in Zweite Version mit neuem Anwedungsprofil
Name | Art | Thema | Status | Prio | MT | aufgetreten in | S.
cmt-text |  | sw-compu-method-text mit Beschreibung | PASSED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 | ->
resp.obj |  | Zuweisung von Verantwortlichkeiten zu Objekten | PASSED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 | ->


4.1.1. Anmerkungen

Inhalt dieses Kapitels:
  • 4.1.1.1. [cmt-text] sw-compu-method-text mit Beschreibung
  • 4.1.1.2. [resp.obj] Zuweisung von Verantwortlichkeiten zu Objekten


4.1.1.1. [cmt-text] sw-compu-method-text mit Beschreibung

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


4.1.1.2. [esp.obj] Zuweisung von Verantwortlichkeiten zu Objekten

4.1.1.2. [resp.obj] Zuweisung von Verantwortlichkeiten zu Objekten

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


4.2. Übersicht zu Erste Version mit Bugfixes

geplant für 06.02.98
Requests zu Erste Version mit Bugfixes
Name | Art | Thema | Status | Prio | MT | geplant für | S.
trans-mode | enh | Transmission-Modes ausmodellieren | OPEN H. Riegraf macht einen Vorschlag. |  |  | 4.2. Übersicht zu Erste Version mit Bugfixes | ->
docrefopt | enh | Dokumentübergreifende Verweise optional | PASSED |  |  | 4.2. Übersicht zu Erste Version mit Bugfixes | ->
Lösungen in Erste Version mit Bugfixes
Name | Art | Thema | Status | Prio | MT | aufgetreten in | S.
trans-mode | enh | Transmission-Modes ausmodellieren | OPEN H. Riegraf macht einen Vorschlag. |  |  | 4.2. Übersicht zu Erste Version mit Bugfixes | ->
basetype |  | sw-base-type in net-signal | PASSED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 | ->
docrefopt | enh | Dokumentübergreifende Verweise optional | PASSED |  |  | 4.2. Übersicht zu Erste Version mit Bugfixes | ->
init-opt | enh | init-value optional | PASSED |  |  | 4.3. Übersicht zu Erste Version | ->
msg-set | enh | Botschaften in einzelne Kapitel | PASSED | A 1 |  | 4.3. Übersicht zu Erste Version | ->
msgid-mask | enh | Gleiche Botschaft aus verschiedenen Sendern | PASSED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 | ->


4.2.1. Anmerkungen

Inhalt dieses Kapitels:
  • 4.2.1.1. enh: [trans-mode] Transmission-Modes ausmodellieren
  • 4.2.1.2. [basetype] sw-base-type in net-signal
  • 4.2.1.3. enh: [docrefopt] Dokumentübergreifende Verweise optional
  • 4.2.1.4. enh: [init-opt] init-value optional
  • 4.2.1.5. enh: [msg-set] Botschaften in einzelne Kapitel
  • 4.2.1.6. enh: [msgid-mask] Gleiche Botschaft aus verschiedenen Sendern


4.2.1.1. enh: [trans-mode] Transmission-Modes ausmodellieren

<event-mode> und <cycle-mode> wird entfernt bis formae Modelle vorliegen.


4.2.1.2. [basetype] sw-base-type in net-signal

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


4.2.1.3. enh: [docrefopt] Dokumentübergreifende Verweise optional

Die potentiell dokumentübergreifende Verweise werden optionalisiert und mit einem Label versehen. Damit kann MSRNET.DTD autonom benutzt werden.


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

<init-value> ist nun optional in < net-signal-spec-variant>


4.2.1.5. enh: [msg-set] Botschaften in einzelne Kapitel

<memory-layout> heißt nun <net-message-layout > umbenannt.
Netz Botschaften können nun in <net-message-set>s zusammengefaßt werden. Die Zusammenfassung ist für inhaltlich gleiche Botschaften gedacht. Sie dient zur dokumentarischen Zusammfenfassung.
Wenn eine solche Instanz in eine nicht normalisierte Datenbank eingelesen wird (d.h. die <short-name> der < net-message-set> werden den <net-message> zugeordnet), dient beim Wiederaufbau einer MSRNET-Instanz der <short-name > als Gruppenwechselkriterium.


4.2.1.6. enh: [msgid-mask] Gleiche Botschaft aus verschiedenen Sendern


4.3. Übersicht zu Erste Version

geplant für 18.11.97
Requests zu Erste Version
Name | Art | Thema | Status | Prio | MT | geplant für | S.
non-can |  | Ausdehnung auf nicht CAN-Netze | OPEN |  |  |  | ->
sw-var-abgl |  | Abgleich zwischen MSRSW-Variablen und MSRNET Signalen | OPEN |  |  |  | ->
init-opt | enh | init-value optional | PASSED |  |  | 4.2. Übersicht zu Erste Version mit Bugfixes | ->
msg-set | enh | Botschaften in einzelne Kapitel | PASSED | A 1 |  | 4.2. Übersicht zu Erste Version mit Bugfixes | ->
Lösungen in Erste Version
Name | Art | Thema | Status | Prio | MT | aufgetreten in | S.
ctrl-mode | enh | Wo wird der Mode der Controller festgelegt | PASSED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 | ->
var-trans | bug | Varianten in transmission-spec | PASSED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 | ->


4.3.1. Anmerkungen

Inhalt dieses Kapitels:
  • 4.3.1.1. enh: [ctrl-mode ] Wo wird der Mode der Controller festgelegt
  • 4.3.1.2. bug: [var-trans] Varianten in transmission-spec


4.3.1.1. enh: [ctrl-mode ] Wo wird der Mode der Controller festgelegt

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


4.3.1.2. bug: [var-trans] Varianten in transmission-spec

<transmission-spec> is no longer variant dependant.


4.4. Übersicht zu Einführung der Net-Ports

geplant für 12.6.96
Requests zu Einführung der Net-Ports
Name | Art | Thema | Status | Prio | MT | geplant für | S.
Netport-Node | enh | Behandlung von Knoten mit mehreren Netports zu unflexibel | PASSED |  |  | 4.5. Übersicht zu Sitzung 22.8.96 | ->


4.5. Übersicht zu Sitzung 22.8.96

geplant für 22.8.96
Lösungen in Sitzung 22.8.96
Name | Art | Thema | Status | Prio | MT | aufgetreten in | S.
Netport-Node | enh | Behandlung von Knoten mit mehreren Netports zu unflexibel | PASSED |  |  | 4.4. Übersicht zu Einführung der Net-Ports | ->


4.6. Übersicht zu Sitzung 12.12.96

geplant für 12.12.96
Requests zu Sitzung 12.12.96
Name | Art | Thema | Status | Prio | MT | geplant für | S.
gateway |  | Wie wird Gateway-Funktionalität behandelt | OPEN |  |  |  | ->
multi-arch | enh | Unterstützung von Multi-Architektur-Netzen | OPEN BMW, VW, Porsche diskutieren weiter |  |  |  | ->
net-class | enh | Netzwerk - Protokollklassen | OPEN |  |  |  | ->
supersignal |  | Supersignal | OPEN |  |  |  | ->
basetype |  | sw-base-type in net-signal | PASSED |  |  | 4.2. Übersicht zu Erste Version mit Bugfixes | ->
cmt-text |  | sw-compu-method-text mit Beschreibung | PASSED |  |  | 4.1. Übersicht zu Zweite Version mit neuem Anwedungsprofil | ->
ctrl-mode | enh | Wo wird der Mode der Controller festgelegt | PASSED |  |  | 4.3. Übersicht zu Erste Version | ->
msgid-mask | enh | Gleiche Botschaft aus verschiedenen Sendern | PASSED |  |  | 4.2. Übersicht zu Erste Version mit Bugfixes | ->
resp.obj |  | Zuweisung von Verantwortlichkeiten zu Objekten | PASSED |  |  | 4.1. Übersicht zu Zweite Version mit neuem Anwedungsprofil | ->
seg.na | enh | Segmentierung wird nicht immer eingegeben | PASSED | A1 |  |  | ->
var-trans | bug | Varianten in transmission-spec | PASSED |  |  | 4.3. Übersicht zu Erste Version | ->
lnk-sw |  | Wie werden Signale zu SW-Variablen zugeordnet | REJECTED |  |  |  | ->


5. Changes

Strukturelle Grundlagen
5. Changes

Inhalt dieses Kapitels:
  • 5.1. [gateway] Wie wird Gateway-Funktionalität behandelt
  • 5.2. [multi-arch] Unterstützung von Multi-Architektur-Netzen
  • 5.3. [net-class] Netzwerk - Protokollklassen
  • 5.4. [non-can] Ausdehnung auf nicht CAN-Netze
  • 5.5. [supersignal] Supersignal
  • 5.6. [sw-var-abgl ] Abgleich zwischen MSRSW-Variablen und MSRNET Signalen
  • 5.7. [trans-mode] Transmission-Modes ausmodellieren
  • 5.8. [basetype] sw-base-type in net-signal
  • 5.9. [cmt-text] sw-compu-method-text mit Beschreibung
  • 5.10. [ctrl-mode ] Wo wird der Mode der Controller festgelegt
  • 5.11. [docrefopt] Dokumentübergreifende Verweise optional
  • 5.12. [init-opt] init-value optional
  • 5.13. [msg-set] Botschaften in einzelne Kapitel
  • 5.14. [msgid-mask] Gleiche Botschaft aus verschiedenen Sendern
  • 5.15. [ Netport-Node] Behandlung von Knoten mit mehreren Netports zu unflexibel
  • 5.16. [resp.obj] Zuweisung von Verantwortlichkeiten zu Objekten
  • 5.17. [seg.na] Segmentierung wird nicht immer eingegeben
  • 5.18. [var-trans] Varianten in transmission-spec
  • 5.19. [lnk-sw ] Wie werden Signale zu SW-Variablen zugeordnet


5.1. [gateway] Wie wird Gateway-Funktionalität behandelt

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | Rauleder | OPEN |  |  | 4.6. Übersicht zu Sitzung 12.12.96 |
Sache | Wie werden Gateway - Funktionen beschrieben? Wie kommen Links zu MSRSW.DTD Instanzen. Dabei ist nur die Signal/Signal-Zuordnung zu betrachten?
Begründung | Hintergrund der Frage ist der unterschiedliche Grad der Formaliserung von Signalen im Spannungsfeld zwischen MSRSW.DTD MSRNET.DTD MSWDOC.DTD
Beschlossene Lösung
muß noch erarbeitet werden


5.2. [multi-arch] Unterstützung von Multi-Architektur-Netzen

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | BMW H. Kramer | OPEN BMW, VW, Porsche diskutieren weiter |  |  | 4.6. Übersicht zu Sitzung 12.12.96 |
Sache
Es muß eine Möglichkeit geben, Netzwerke zu beschreiben, die mit unterschiedlichen Protokollen und Architekturen arbeiten. Dabei ist zu betrachten
Gateway | Das Gesamtnetz besteht aus mehreren Beschreibungen mit getrennten Signaldefinitionen. Die Teilnetze wissen nichts voneinander.
Repeater | Das Gesamtnetz hat eine konsistente Beschreibung und eine gemeinsame Signaldefinition.
Begründung
Die Szenarien treten in der Praxis auf, in erster Linie aber Gateways
Lösungsansatz 1
Es werden mehrere Netz-Spezifikationen eingeführt, wobei eine gemeinsame und Subnetz-Komponenten auftreten. Die Subnetz-Komponenten können auf das gemeinsame Netz verweisen. Ohne Subnetze ist das gemeinsame Netz das gesamte Netz. Es ergibt sich also folgende Struktur.
   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
Zusätzlich ist ein Modell für Gateways zu finden.


5.3. [net-class] Netzwerk - Protokollklassen

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | BMW H. Krammer | OPEN |  |  | 4.6. Übersicht zu Sitzung 12.12.96 |
Sache | Es muß die Möglichkeit geben, den Protokolltyp eines Netzes zu spezifizieren.
Begründung | Es gibt verschiedenartigen Netze


5.4. [non-can] Ausdehnung auf nicht CAN-Netze

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | AG-Net 18.11.97 | OPEN |  |  | 4.3. Übersicht zu Erste Version |
Sache | Die Ausweitung auf nicht-CAN-Netze muß eingebaut werden.
Begründung | Es gibt auch nicht-CAN


5.5. [supersignal] Supersignal

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | BMW H. Krammer | OPEN |  |  | 4.6. Übersicht zu Sitzung 12.12.96 |
Sache | Es muß die Möglichkeit geben, verschiedenartige Signale zusammenzufassen.
Begründung | Verbesserung der Dokumentation.
Lösungsansatz 1
Lösung analog zu <port-groups> in MSRDOC
Lösungsansatz 2
Signale können über ein Cluster zusammengefasst werden. Dies ist ein Elment mit mehreren Zeigern auf <net-signal>.


5.6. [sw-var-abgl ] Abgleich zwischen MSRSW-Variablen und MSRNET Signalen

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | AG Net 18.11.97 | OPEN |  |  | 4.3. Übersicht zu Erste Version |
Sache | In künftigen Versionen muß ein Abgleich zwischen <sw-variable > und <net-signal-spec-variant>
Begründung | Diese Daten stehen in enger Beziehung zueinander.
Siehe auch | OTHER: 5.8. [basetype] sw-base-type in net-signal


5.7. [trans-mode] Transmission-Modes ausmodellieren

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | Riegraf, Aufdermauer | OPEN H. Riegraf macht einen Vorschlag. |  |  | 4.2. Übersicht zu Erste Version mit Bugfixes | 4.2. Übersicht zu Erste Version mit Bugfixes
Sache | Die transmission-Modes <event-mode> bzw. < cycle-mode> sollten ausmodelliert werden
Begründung | Damit kann eine formale Behandlung in Tools erfolgen
Beschlossene Lösung
Zunächst die informalen <event-mode> und < cycle-mode> entfernen. Wenn ein formaler Vorschlag vorliegt, wird er eingebaut
Anmerkungen
1.1.1


5.8. [basetype] sw-base-type in net-signal

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | BMW H. Krammer | PASSED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 | 4.2. Übersicht zu Erste Version mit Bugfixes
Sache | Es sollte die Möglichkeit geben, einen Basistyp für ein Signal anzugeben
Begründung | Aus der Umrechnugnsformel allein kann man nicht erkennen, ob es ein vorzeichenbehafteter Wert sein kann.
Beschlossene Lösung
Es wird <sw-base-type> in <net-signal-spec-variant > eingebaut.
In künftigen Versionen muß ein Abgleich zwischen <sw-variable > und <net-signal-spec-variant>
Anmerkungen
1.1.1


5.9. [cmt-text] sw-compu-method-text mit Beschreibung

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | BMW H. Krammer | PASSED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 | 4.1. Übersicht zu Zweite Version mit neuem Anwedungsprofil
Sache | <sw-compu-method-text> sollte ein weiteres Eleent <cmt-desc> haben, in welches weitere INformationen zu einem bestimmten wert geschrieben werden kann.
Begründung | Es kann sein daß <cmt-text> ein formaler Text ist, welcher in der Dokumentation detaillierter beschrieben werden soll.
Beschlossene Lösung
Es wird ein Element <desc> innerhlb < sw-compu-method-value-pair> eingeführt.
Anmerkungen
2.1.0


5.10. [ctrl-mode ] Wo wird der Mode der Controller festgelegt

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | Riegraf / Weichel | PASSED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 | 4.3. Übersicht zu Erste Version
Sache | Aussage von Dipl.-Ing. T. Riegraf zu <identifier-type>: Eine bessere Bezeichnung ist "CAN-Datenübertragungsformat". Dieses ist eine sehr globale Festlegung für einen Bus und kann " Standard-Format" oder "Extended-Format" sein. Hierzu existieren Spezifikationen der Fa.Bosch. Im Fall von "Extended-Format " kann je Steuergerät/CAN-Controller festgelegt werden, ob es/er "aktiv" oder "passiv " ist, d.h. ob es/er das Extended-Format kommunizieren kann oder nicht. Es muß noch geklärt werden, wo diese Festlegung stattfindet.
Begründung | Sonst haben wir eine Lücke
Beschlossene Lösung
  • <adress-mode> wird zu <identifier-type > umbeannt. Dieser kann die Werte standard bzw. extended annehmen.
  • <node-variant> bekommt ein neues Element <protocol-conformance> und kan die folgenden Werte annehmen
    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-passiv
    CAN Conformance 2.0B passivCAN Conformance 2.0B passiv
    NA
    Das beschriebene Netz kenn keine Konformitätsklassen. Der Wert ist daher nicht ausfüllbar.
Anmerkungen
1.1.0


5.11. [docrefopt] Dokumentübergreifende Verweise optional

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | Klein | PASSED |  |  | 4.2. Übersicht zu Erste Version mit Bugfixes | 4.2. Übersicht zu Erste Version mit Bugfixes
Sache | Die Dokumentübergreifenden Verweise sollten optional sein.
Begründung | Vereinfacht die Handhabung in einfachen Autorenumgebungen. Beschluß in der AG-DTD
Beschlossene Lösung
Die potentiell dokumentübergreifende Verweise werden optionaliseirt und mit einem Label versehen. Damit kann MSRNET.DTD autonom benutzt werden.
Anmerkungen
1.1.1


5.12. [init-opt] init-value optional

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | riegraf | PASSED |  |  | 4.3. Übersicht zu Erste Version | 4.2. Übersicht zu Erste Version mit Bugfixes
Sache | <init-value> soll optional sein.
Begründung | Die Angabe kann nicht immer gemacht werden, insbesondere bei Blockmodes.
Beschlossene Lösung
<init-value> ist nun optional in < net-signal-spec-variant>
Anmerkungen
1.1.1


5.13. [msg-set] Botschaften in einzelne Kapitel

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | Kramer | PASSED | A 1 |  | 4.3. Übersicht zu Erste Version | 4.2. Übersicht zu Erste Version mit Bugfixes
Sache | Es sollte eine Möglichkeit geben, Netzbotschaften so zu kategorisieren, daß sie bei gedruckter Dokumentation auf einzelne Kapitel verteilt werden können.
Begründung | Damit wird die Dokumentation übersichtlicher
Beschlossene Lösung
Es wird auch für Botschaften ein Gruppenkonzept eingeführt < net-message-set>. Es wurde nicht "group" verwendet, da "group" konzeptuell gleichartige Dinge zusammenfaßt. Nur bei der MSRSYS.DTD gibt es für Ports die Mögichkeit "group" zur Inhaltlichen und logischen Zusammenfassung zu verwenden.
Anmerkungen
1.1.1


5.14. [msgid-mask] Gleiche Botschaft aus verschiedenen Sendern

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | BMW H. Krammer | PASSED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 | 4.2. Übersicht zu Erste Version mit Bugfixes
Sache | Es muß möglich sein, einer Botschaft mehrere Sender zuzuweisen. Diese unterscheiden sich hinsichtlich Variante und Identifier.
Begründung | Es kann sein, daß die gleiche Botschaft von mehreren Sendern und unterschiedliche Identifier verschickt wird. Die Empfänger reagieren auf einen maskierten Identifier. Beispiel ist Fensterheber, wo jeder Taster die gleiche Botschaft abdrückt. Weiterhin ist Varianten handhabung zu untersützen.
Lösungsansatz 1
Für die Bestimmung der Identifier einer einer konreten < net-message> werden zwei Mechanismen angeboten:
  • Eine diskrete Angabe der Identifier <net-message-identifiers >.
  • eine Berechnung des Identifiers (<calc-net-message-identifiers >) als Summe einer basis und <Identifier-base-adress > und eines Offset, der im Knoten angegeben wird. Der < msg-identifier-offset> wird über beim jeweiligen <sender > angegeben. Dieses Verfahren wird vorzugsweise für Netzwerkmanagement und Diagnose verwendet.
Beschlossene Lösung
Es wird auch für Botschaften ein Gruppenkonzept eingeführt < net-message-group>
Anmerkungen
1.1.1


5.15. [ Netport-Node] Behandlung von Knoten mit mehreren Netports zu unflexibel

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | ?? | PASSED |  |  | 4.4. Übersicht zu Einführung der Net-Ports | 4.5. Übersicht zu Sitzung 22.8.96
Sache | Zur Zeit ist es so, daß jeder Net-Port als eigener Knoten in der Segmentierung auftritt.
Begründung | Das ist zu unflexibel. Der Zusammenhang zwischen den Netports ist im Netz-Dokument nicht sichtbar.
Lösungsansatz 1
Man könnte im Knoten auf die Erwähnung des Net-ports verzichten, dafür bei der Referenzierung des Knotens in der Segmentierung den Netport mit angeben.
Beschlossene Lösung
Net-ports wurde innerhalb von Knoten eingerichtet (s. 3.2.2.2. Beschreibung der Netzknoten). Die Segmentierung verweist auf die< net-node-port>s.
Anmerkungen


5.16. [esp.obj] Zuweisung von Verantwortlichkeiten zu Objekten

5.16. [resp.obj] Zuweisung von Verantwortlichkeiten zu Objekten

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | BMW H. Krammer | PASSED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 | 4.1. Übersicht zu Zweite Version mit neuem Anwedungsprofil
Sache | Es sollte möglich sein, die Verantwortung für bestimmte Teilbäume explizit anzugeben.
Begründung | Die beteiligten müssen ihre Partner kennen.
Lösungsansatz 1
<Admin-data> wird weiter verbreitet, in < company-doc-info> wird ein <team-member-ref> eingeführt.
Beschlossene Lösung
Bei den der <Team-Member>s werden verweise auf Objekte eingeführt, ähnlich wie <role>.
<admin-data> wird auch bei <net-node-variant > eingeführt
Anmerkungen
2.1.0


5.17. [seg.na] Segmentierung wird nicht immer eingegeben

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | BMW. H. Krammer | PASSED | A1 |  | 4.6. Übersicht zu Sitzung 12.12.96 |
Sache | Segmentierung sollte auch <na> erlauben. Im Prinzip sollte man das so weit treiben, daß veschiedene Szenarien abgedectk werden können, ähnlich wie bei msrsw.
Begründung | Es kann sein, daß das Netz abstrakt beschrieben werden soll, also ohne Segmentierung. Das erlaubt die DTD derzeit nicht.
Beschlossene Lösung
<setmentation> und ihre Zwillinge bekommen < na> usw.


5.18. [var-trans] Varianten in transmission-spec

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
bug | Weichel | PASSED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 | 4.3. Übersicht zu Erste Version
Sache | <transmission-spec> ist noch nicht variantenabhängig, ob wohl 3.4. Varianten das behauptet
Begründung | Das ist inkonsistent
Beschlossene Lösung
Dokumentation korrigiert in 3.4. Varianten.
Anmerkungen
1.1.0


5.19. [lnk-sw ] Wie werden Signale zu SW-Variablen zugeordnet

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | Rauleder 18.1.97 | REJECTED |  |  | 4.6. Übersicht zu Sitzung 12.12.96 |
Sache | Wie kommen Links zu MSRSW.DTD Instanzen. Dabei ist nur die Signal/Signal-Zuordnung zu betrachten?
Begründung | Wir haben keine Möglichkeit, diese Zuordnung durchzuführen.
Lösungsansatz 1
Parallel zu <locs> wird <net-sig-var-assocs > eingeführt. Dort kann an einer Stelle die Netzs-Signal zu Variable-Zuordnung beschrieben werden.
Pro
  • Löst das gegebene Problem
Con
  • Diese Angaben gehören eher zur Software und sollten dort beschrieben werden.
Beschlossene Lösung
Soll bei MSRSW.DTD behandelt werden.


A. Glossar

Strukturelle Grundlagen
A. Glossar

Abtastzeitpunkt
Bestimmt als Netzparameter den Zeitpunkt der Bitabtastung.
Adress-Mode
Der Adress-Mode einer Botschaft kann "Standard" oder "Extended" sein.
ASAP
Die ASAP-Schnittstellen wurden vom "Arbeitskreis zur Standardisierung von Applikationssystemen (ASAP)" vereinbart. Mitglieder dieses Arbeitskreises sind deutsche Automobilhersteller und Firmen der Zuliefererindustrie.
Basic-CAN
CAN-Chip; besitzt nur einen Sende- und einen Empfangsspeicher.
Baudrate
Betriebsart
Übertragungsparameter einer Botschaft, der z.B. beschreibt, ob ein Remote-Betrieb vorliegt oder nicht.
Bit Stuffing
Eine Technik, die in bitorientierten Netzprotokollen zur Resynchronisation genutzt wird. Nach einer festgelegten Anzahl von Bits gleichen Pegels wird durch Einfügen eines zusätzlichen komplementären Bits ein Flankenwechsel hervorgerufen. Das zusätzliche Bit wird vom Empfänger wieder entfernt.
BRT
Abkürzung für Baudrate Prescaler, definiert die Anzahl BTL-Zyklen.
BTL-Zyklen
Abkürzung für Bit Timing Logic-Takt; über den Baudrate Prescaler wird aus der Oszillatorfrequenz des Chips ein Abtastraster gebildet. Dieser Hilfstakt (BTL-Takt) dient zur Bestimmung der Zeitsegmente des Bit-Timings.
Byte-Order
Netzparameter, der die Reihenfolge für das höherwertige und das niederwertige Byte innerhalb eines Wortes festlegt. Da die Prozessor-Hersteller "Intel" und "Motorola" die Byte-Order konträr festgelegt haben, sind die möglichen Werte für diesen Parameter "Intel", "Motorola vorwärts" und "Motorola rückwärts".
CAN
Abkürzung für Controller Area Network
CAN High Speed
Netzankopplung und Netzmedium nach [To be defined;ISO 11898;DIS;;ganzes Dokument;], u.a. gekennzeichnet durch eine Datenrate von 125kBit/s bis 1Mbit/s.
CAN Low Speed
Netzankopplung und Netzmedium nach [To be defined;ISO 11519-1;DIS;;gesamtes Dokument;], u.a. gekennzeichnet durch eine Datenrate bis 125kBit/s.
CAN Conformance 2.0A
CAN mit einer Identifierlänge von 11 Bit (Standard).
CAN Conformance 2.0B
CAN mit einer Identifierlänge von 29 Bit (Extended). Alle CAN-Controller, die CAN 2.0B-Telegramme verarbeiten können, sind auch in der Lage Standard-Frames zu verarbeiten, d.h. sowohl zu senden als auch zu empfangen.
CAN Conformance 2.0B passiv
CAN-Controller, die nur Standard-Frames verarbeiten und sich bei CAN Version 2.0B passiv verhalten. Sie ignorieren die Extended-Telegramme nach Version 2.0B.
CANdb
CAN-Datenbasis
CRC
Abkürzung für Cyclic Redundancy Check; enthält den Fehlercode über alle vorangegangenen Stellen. Die CRC-Prüfsumme wird zur Fehlererkennung, nicht zur Fehlerkorrektur verwendet.
CSMA/CD
Abkürzung für Carrier Sense Multiple Access with Collision Detect
DLC
Abkürzung für Data Length Code; gibt die Länge der Botschaft in Byte an.
Empfangsbereitschaft nach Power down
Übertragungsparameter einer Botschaft, beschreibt die Zeit nach einer Power down Meldung, in der zwar nicht mehr gesendet, aber noch auf eintreffende Botschaften reagiert werden kann. Damit wird vermieden, daß eine Komponente in den sleep mode geht, obwohl gerade eine Botschaft an sie unterwegs ist.
Empfängerbereitschaft nach Power up
Übertragungsparameter einer Botschaft, der den Zeitpunkt nach Power up beschreibt, ab wann die Botschaft empfangen werden kann.
Fehlerwert
Wert eines Signals, wenn ein Fehler erkannt wird und die eigentliche Informationen nicht übertragen werden kann.
Full-CAN
CAN Chip, besitzt im Gegensatz zum Basic-CAN mehrere Sende- und Empfangsspeicher.
Initialisierungswert
Wert eines Signals vor dem ersten Empfang im Empfänger.
Knoten
Ein Netzknoten umfaßt jeglichen Teilnehmer oder auch Abzweig des Netzwerks.
Latenzzeit
Übertragungsparameter einer Botschaft, der die Übertragungszeit auf dem Netz beschreibt. Die Latenzzeit ist die Zeit, um der Sendevorgang einer Botschaft durch höherpriore Botschaften verzögert werden kann. Technisch gesprochen ist die Latenzzeit die Zeitspanne, die zwischen TransmitRequestBit setzen und AckMeldung erhalten liegt. An der Botschaft kann also die maximale Latenzzeit für diese Botschaft spezifiziert werden.
Multiplex-Signal-Gruppe
In einer Multiplex-Signal-Gruppe innerhalb einer Botschaft werden mehrere Signal-Gruppen zusammengefaßt, die über einen jeweiligen (Gruppen-)Wert identifiziert werden. Ein Empfänger der Botschaft kann die für ihn bestimmte Signal-Gruppe über diesen Wert herausfiltern.
Net-EMV-Design
Beschreibung des Designs bzw. der Auslegung des Netzwerkes hinsichtlich seiner elektromagnetischen Verträglichkeit.
Netz-Signal-Gruppe
...
Netz-Signal-Klasse
Die Netz-Signal-Klasse teilt die Netz-Signale in Applikationssignale und Netzwerkmanagementsignale ein.
OSEK
To be defined
Phasenbeziehung zu anderen Botschaften
Übertragungsparameter einer Botschaft, der beschreibt, ob eine Phasenbeziehung zu anderen Botschaften vorliegt.
Physikalischer Bereich
Zulässiger Bereich für die physikalischen (externen) Werte eines Signals, die sich aufgrund der Umrechung von der Netz-internen Darstellung ergeben.
Quarzfrequenz
Der Frequenzwert des am CAN-Controller angeschlossenen Quarzes bzw. Quarzoszillators.
RTR
Abkürzung für Remote Transmission Request; ein Flag zur Kennzeichnung einer Datenanfrage. Ein Sender wird aufgefordert ein entsprechendes Datentelegramm als Antwort zu senden.
Sendebedingungen
Übertragungsparameter einer Botschaft, der Sendebedingungen beschreibt.
Sendebereitschaft nach Power up
Übertragungsparameter einer Botschaft, der den Zeitpunkt nach Power up beschreibt, ab wann die Botschaft gesendet werden kann.
SJW
Abkürzung für Synchronization Jump Width, die in BTL-Zyklen angegeben wird. Definiert den maximalen Betrag, um den der CAN-Controller die beiden Hauptsegmente der Bitzeit verlängern oder verkürzen darf.
Sleep-/Wake up-Mechanismus
Ein Mechanismus, der den Netz in einen " Ruhezustand" mit geringer Stromaufnahme versetzt (Sleep) und ihn bei Bedarf wieder aktiviert (Wake up); z.B. für eine Zentralverriegelung.
SLIO
Abkürzung für Serial Linked I/O.
Speicherlayout
Für eine Botschaft ist das Speicherlayout eine (grafische) Ergänzung zu der Beschreibung von Signallisten und Multiplex-Signal-Gruppen, die die Signalverteilung einer Botschaft im Speicher beschreibt.
Umrechnung
Vorschrift, wie die Netz-interne Darstellung (interner Werte) eines Signals in die zugehörigen physikalischen Werte (externe Werte) umzurechnen sind.
Vorteiler
oder auch Baudrate Prescaler; zur Erzeugung des BTL-Zyklen-Taktes aus der Quarzfrequenz.
Zykluszeit
(Auch Zyklustoleranzzeit), Übertragungsparameter einer Botschaft, der die Toleranzzeit einer Botschaft bei zyklischer Steuerung (zyklisches Versenden der Botschaft) beschreibt.


B. Literaturverzeichnis

Strukturelle Grundlagen
B. Literaturverzeichnis

CAN-ER-Modell
Analyse zur CAN-Datenbank, Unterlage der Fa.Bosch,
CAN-Contoller Area Network, Grundlagen und Praxis
CAN Controller Area Network, Grundlagen, Protokolle, Bausteine, Anwendungen


C. Legende der Strukturgrafiken

Strukturelle Grundlagen
C. Legende der Strukturgrafiken

Abbildung 14: Bedeutung der Symbole in den Strukturgrafiken


D. Betrachtete Alternativen zur Ankopplung von SG und Netz

Strukturelle Grundlagen
D. Betrachtete Alternativen zur Ankopplung von SG und Netz

Inhalt dieses Kapitels:
  • D.1. Kopplung über Einzelsignale
  • D.2. Verwendung von Namenskonventionen
  • D.3. Einführung eines Netz-Signalelementes
  • D.4. Referenzieren von Netzelementen bei der Signaldefinition


D.1. Kopplung über Einzelsignale

Im Fall a) werden die Einzelsignale der Netzverbindung (z.B. Low, High, Shield) spezifiziert und bei der Verbindungsspezifikation auf die entsprechenden Ports gelegt.
Bei b) wird nur ein Netz-Signal definiert und auf alle Ports gelegt.


D.2. Verwendung von Namenskonventionen

Die Namen der Einzelleitungen des Netzes werden wie normale Signale behandelt. Die Zuordnung der Steuergeräte-Signale zu einem Netz erfolgt über eine Namenskonvention, indem die Bezeichnung des Netzes als Präfix im Signalnamen wieder auftritt. Für eine Netz CANx könnten die Signale die Namen CANx_High, CANx_Low, und CANx_Shield tragen.
Diese Variante ist nicht ausreichend, da im Fall c) in Kopplung von Steuergerät und Netz nicht eindeutig ist an welche Herausführung das Netz aufgelegt wird.
Diese Namenskonventionen können auch dadurch realisiert werden, daß Signale in < signal> ein weiteres Element < net-name> bekommen, welches die Einzelsignale dem Netz zuordnet.


D.3. Einführung eines Netz-Signalelementes

Zusätzlich zu der bestehenden Signalbeschreibung wird eine neue Art der Signaldefinition eingeführt. Dieses kann innerhalb der Signalspezifikation < signal-spec> oder innerhalb einer Signalgruppe < signal-group> erfolgen.
Abbildung 15: Zuordnung der Netzleitungen zum Steuergerät (SG)
a)
<signal-group>
   <signals>
   <net-lines>
      <long-name>
      <short-name>
      <variant-def-refs>

b)
<signal-spec>
   <signal-groups>
   <net-lines>
a)
<signals> und <net-lines> sind insoweit äquivalent, als daß bei <net-lines > noch Mittel zur Bezeichnung des Netzes vorhanden sind. Daß <signals> in < net-lines> enthalten ist, liegt an der Konvention, daß mehrfach auftretende Elemente ein Hüllenelement haben sollten. Rein logisch betrachtet, kommt hier eine Menge von <signal > vor wie in <signals > auch. Bei dieser Lösung müssen für ein Netz z.B. drei <signal-group> angelegt werden.
<signal-group>
  <signals>
  <net-lines>
     <long-name>           Bezeichnung des Netzes
     <short-name>          Bezeichnung des Netzes
     <signals>
  <signal-spec-variants>
b)
Dieser Ansatz ist äquivalent zu a). Auch hier sind drei <signal-group > anzulegen. Die Hierarchie ist jedoch etwas flacher.
<signal-group>
   <signals>
   <net-lines>
       <net-line>
          <long-name>      Signalbezeichnung
          <short-name>     Signalbezeichnung
          <net-name>        müßte konsequenterweise <net-ref>
                           sein,
                           ist im Grunde ein Zeiger aus der
                           MSRDOC-Instanz in MSRNET Instanz.
          <variant-def-refs>
c)
Diese Variante beschreibt das Netzwerk geschlossen. Auch hier werden für ein Netzwerk drei < signal-group> Elemente angelegt, die jedoch unter einem zusammengefaßt sind. Diese Variante hat den Nachteil, daß Signale an verschiedenen Stellen definiert werden. Wenn also alle Signale einer Komponente aufgesucht werden sollen, muß an mehreren Stellen gesucht werden. Dem steht der Vorteil gegenüber, daß ein Netzwerk in sich komplett beschrieben wird.
<signal-spec>
   ...
   <busses>
      <bus>
         <long-name>       Busbezeichnung
         <short-name>
            <signal-groups>
Diese Variante adressiert ebenfalls nicht das Problem Kopplung von Steuergerät und Netz Fall b). Um das zu behandeln, wären weitere Elemente notwendig, welche den Signalnamen modifizieren.


D.4. Referenzieren von Netzelementen bei der Signaldefinition

Netzsignale werden wie Signale behandelt. Die Kennzeichnung als Netzsignal erfolgt über eine Referenz auf ein neues Netzelement.
<architecture>
   <buses>
      <bus>
         1
         2    <-
                |
<signal> -> <bus-ref>
Innerhalb der Architecture werden Netzwerke eingeführt. Jedes Signal kann wahlweise genau einem Netzwerk zugeordnet werden. Dies ist eine Fortentwicklung von D.3. Einführung eines Netz-Signalelementes , indem das dortige <net-name> normiert wird.
<architecture>
  <buses>
     <bus>
        <long-name>
        <short-name>
        <desc>
        <add-info>

<signal>
   <bus-ref>
Löst noch nicht die Problematik Kopplung von Steuergerät und Netz Fall b).


E. Festlegung von Wertebereichen

Strukturelle Grundlagen
E. Festlegung von Wertebereichen

Inhalt dieses Kapitels:
  • 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 1.1.1 am 10.7.98

Strukturelle Grundlagen
F. Zusätzliche Anmerkungen zum Dokumentstand 1.1.1 am 10.7.98

Status dieses Dokument: CD


Technische Begriffe

Strukturelle Grundlagen
Technische Begriffe

Organisationen
ASAP
ISO TC22 SC3 WG1
OSEK
MEDOC-Netzwerke
Parameter
Latenzzeit
Zykluszeit
Produkte
Steuergerät
ABS-Steuergerät
CAN-controller
Motor-Steuergerät
MSRNET.DTD, MSRNET.DTD
MSRSW.DTD
Steuergerät, Steuergerät
Fahrzeugsystem
MSRDOC
MSRDOC.DTD, MSRDOC.DTD, MSRDOC.DTD
MSRNET.DTD, MSRNET.DTD, MSRNET.DTD, MSRNET.DTD, MSRNET.DTD
MSRSW.DTD, MSRSW.DTD
MSRSYS.DTD
MSWDOC.DTD
Netzwerke, Netzwerke
Steuergerät, Steuergerät, Steuergerät, Steuergerät, Steuergerät
Steuergerät
Programmcode
extended, extended
standard, standard
SGML Elemente
long-name
net-node-port
short-name
net-message-signals
interface-circuit
signal-group
abs
add-info
admin-data
company-doc-info
connection-comp-spec-1
cycle-mode
driver-concept
identifier-type
long-name
msg-identifier-offset, msg-identifier-offset, msg-identifier-offset
multiplex-signal-set
multiplexor
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-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
segment
signal, signal
signal-group
signal-spec
sw-base-type
sw-compu-method-value-pair
sw-units
abs
add-info
add-spec
address-mode
admin-data, admin-data
adress-mode, adress-mode
architecture
baudrate
bitsize, bitsize
btl-cycles
byte-order
calc-net-message-identifiers , calc-net-message-identifiers , calc-net-message-identifiers
cmt-desc
cmt-text
coded
connection-comp-ref
connection-comp-spec-1
cycle-mode
cycle-time
desc, desc
dlc
driver-concept
error-value
error-values
event-mode, event-mode
general-net-spec, general-net-spec
identifier
identifier
Identifier-base-adress , Identifier-base-adress , Identifier-base-adress
identifier-type
identifier-type
init-value, init-value, init-value
interface-circuit
latency-time
locs
long-name, long-name
memory-layout
multiplex-entry
multiplex-signal-list
multiplexor-value
na
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
offset
part-type-spec
phase-relations
phys
port-groups
powerdown-receive-time
powerup-receive-time
powerup-transmit-time
project-data
protocol-conformance
protocol-conformance
receivers, receivers
role
sample-point
sample-rate
segment
segment-length
segmentation
segmentation-desc
segments
sender
sender , sender , sender
setmentation
short-name, short-name, short-name
short-name , short-name
signal
signal-class
signal-group
signal-group
signals
signals
sjw
sjw
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-limits
sw-variable , sw-variable
sync-edge
Team-Member
team-member-ref
text
tol
topology-type
transmission-spec, transmission-spec, transmission-spec, transmission-spec
variant-def-ref
variant-def-refs
xref
Sonstige
Netzwerkmanagementsignal
Standard-Format, Standard-Format
Netz-signalgruppe
Applikationssignal
CAN_LOW
Low
Power down Meldung, Power down Meldung
CAN_HIGH
CAN_SHIELD
Extended-Format, Extended-Format
Extended-Format , Extended-Format
High
Shield
Status
Power up
Power up
Ruhezustand
Teilnehmer
aktiv, aktiv
Hilfsknoten
intel
motorola
motorola-rueckwaerts
motorola-vorwaerts
passiv , passiv
Power up
STD
XTD
Variablen
Registerbelegung
Werkzeuge
MSRNET.DTD
MSRDOC.DTD
MSRNET.DTD
MSRDOC.DTD
CAN
MSRDOC.DTD, MSRDOC.DTD, MSRDOC.DTD
MSRDOC.DTD
MSRNET.DTD
SGML-Formatierer


Untitled

Gateways legen zunächst eine Zusammenfassung mehrerer Netze in einer Instanz nahe. Die Gateway-Funktionalität wird aber in einem konkreten System bzw. Gerät realisiert, und ist daher in dessen Verhalten bzw. Software zu beschreiben.


Untitled

Hier wird nicht der Begriff Netz-Signal verwendet, da dieser im Zusammenhang mit den Botschaften in anderer Bedeutung wieder auftritt.


Untitled

Die Netzleitungs-Bezeichner werden nicht explizit normiert. Es ist Aufgabe einer semantischen Prüfung sicherzustellen, daß die Bezeichner der Netzleitungen der verschiedenen Net-Ports konsistent sind.


Untitled

Diese Lösung wurde nicht gewählt und ist daher auch nicht als Beispiel aufgeführt.


Untitled

Es wird eine Abwandlung verwendet, die keinen part-type-ref zuläßt.


Untitled

Eine solche Beschreibung formaler Art findet sich nicht in den derzeit vorliegenden Lastenheften.


Untitled

Auf eine formale Referenzierung der netlines zwischen msrdoc und msrnet wurde aus pragmatischen Gründen verzichetet, da i.d.R. in allen Instanzen gleiche Bezeichnugnen verwendet werden.


Untitled

Alle node-ports eines Knotens müssen das selbe part referenzieren. Trotzdem wurde die Referenz auf das Part nicht aus den node-ports "ausgeklammert". Dies hätte bedeutet, daß die Semantik der Referenz verteilt definiert ist. Dies sollte aus Handhabungsgründen vermieden werden. Es ist Aufgabe einer semantischen Prüfung, eventuelle Unstimmigkeiten festzustellen.


Untitled

Hier wurde auf den Einsatz des Standard-Parameter-Modell verzichtet, um die Darstellung der Segmentierung als geschlossene Tabelle zu ermöglichen.


Untitled

für jeden dieser Parameter sollte eigentlich ein spezifisches Parametermodell verwendet werden. Im Interesse der Verallgemeinerung wurde jedoch auf das MSR-Standardparametermodell zurückgegriffen. Wenn dieses künftig als Architectural Form ausgeführt wird, könnten spezifischere Modelle verwendet werden. Zunächst muß der der Benutzer das richtige Modell wählen, bzw. die Autorenumgebung sollte das richtige Model vorschlagen.


Untitled

Zur Abgrenzung gegen signal in MSRDOC wird hier von net-signal gesprochen.


Untitled

Solche Botschaften sind z.B. Kommandobotschaften mit denen eine bestimmte Funktion innerhalb eines Steuergerätes von verschiedenen Knoten angestoßen wird. Weitere Beispiele sind Netzwerkmanagement- und Diagnosebotschaften.


Untitled

Die offsets beziehen sich grundsätzlich auf den Botschaftsanfang und werden addiert (beginnen also bei 0)


Untitled

nur bei zyklischer Steuerug relevant, daher optional


Untitled

Die Struktur ist ähnlich aufgebaut wie signal-group in MSRDOC.DTD


Untitled

Es muß noch geklärt werden, wo diese Festlegung stattfindet.


Untitled

eine spätere Erweiterung der DTD könnte die strukturellen Grundlagen für eine Automaitisierung legen.


Untitled

Einige dieser Angaben sind optional, um z.B. auch Block-mode-Signale mit Name und Größe anlegen zu können.


Untitled

Diese Hierarchie ist auf allen Ebenen variantenabhängig möglich. Variantenabhängigkeiten sollten jedoch nur auf oberster Ebene eingeführt werden.