Strukturelle Grundlagen

MSR-Teilprojekt MEDOC

Strukturelle Grundlagen
Bereich: Verhalten / Software
[ msrsw-sp-de]
Version: 1.1.0a
Dieses Dokument beschreibt die strukturellen Grundlagen der MSR-Entwicklungsdokumentation MEDOC für den Bereich Software für Steuergeräte. Es werden Hinweise zum zugrundeliegenden Entwicklungsprozeß gegeben. Die Struktur der MSRSW.DTD wird detailliert beschrieben.


I. Einleitung

Strukturelle Grundlagen
I. Einleitung

Dieses Dokument beschreibt die strukturellen Grundlagen der MSR-Entwicklungsdokumentation MEDOC für den Bereich Software für Steuergeräte.
An dieser Stelle wird daraufhingewiesen, daß MSR keine Normung hinsichtlich der mit MEDOC beschriebenen Systeme oder deren Eigenschaften betreibt. MEDOC unterstützt die Verwendung von (inter-)nationalen Standards und Hausnormen sowie nicht genormten, für die Beschreibung von Systemen relevante Daten in einer Entwicklungsdokumentation.


II. Allgemeine Projektdaten

Strukturelle Grundlagen
II. Allgemeine Projektdaten


III. Dokumentenverwaltung

Strukturelle Grundlagen
III. Dokumentenverwaltung

Beteiligte Personen
Name | Firma
Dipl.-Ing.(FH) Uwe Bless | MSR-Arbeitskreis MEDOC
Dipl.-Inform. Helmut Gengenbach | MSR-Arbeitskreis MEDOC
Dipl. Ing. Eckard Jakobi | MSR-Arbeitskreis MEDOC
Dipl.-Ing. Herbert Klein | MSR-Arbeitskreis MEDOC
Dipl. Ing. Oliver Marcks | MSR-Arbeitskreis MEDOC
Dipl.-Inform. Peter Rauleder | MSR-Arbeitskreis MEDOC
Dipl.-Ing. Martin Trinschek | MSR-Arbeitskreis MEDOC
Dipl.-Ing. Bernhard Weichel | MSR-Arbeitskreis MEDOC
Versionsübersicht
Datum | Herausgeber
10.7.98 | Dipl.-Ing. Bernhard Weichel
27.4.98 | Dipl.-Ing. Bernhard Weichel
5.3.98 | Dipl.-Ing. Bernhard Weichel
16.12.97 | Dipl.-Inform. Helmut Gengenbach
25.08.97 | Dipl.-Inform. Helmut Gengenbach
12.08.97 | Dipl.-Inform. Helmut Gengenbach
17.06.97 | Dipl.-Inform. Helmut Gengenbach
10.04.1997 | Dipl.-Inform. Helmut Gengenbach
17.02.1997 | Dipl.-Inform. Helmut Gengenbach
13.01.1997 | Dipl.-Inform. Helmut Gengenbach
04.08.96 | Dipl.-Inform. Helmut Gengenbach
03.07.96 | Dipl.-Inform. Helmut Gengenbach
24.06.96 | Dipl.-Inform. Helmut Gengenbach
24.06.96 | Dipl.-Inform. Helmut Gengenbach
3.6.96 | Dipl.-Ing. Bernhard Weichel
15.5.96 | Dipl.-Ing. Bernhard Weichel
23.4.1996 | Dipl.-Inform. Helmut Gengenbach
Änderungen
Änderung
Bezug
Dokument in neue Dokumentationsstruktur (entprechend TR-DOV übernommen)
Grund: Neue Struktur wurde festgelegt
Inhalt
Redaktionelle Überarbeitung, Bereinigung der Strukturen
Grund: Erstellung des Abschlußdokumentes
Inhalt
Beginn der redaktionellen Überarbeitung
Grund:
Inhalt
Ersterstellung
Grund: Veröffentlichung der ersten offiziellen Version
Dokument
Ersterstellung
Grund: Veröffentlichung der ersten offiziellen Version
Dokument
Ändern des Inhaltsmodells von Variablen
Grund: Bei Variablen muß zwischen der Definition und dem Zugriff auf eine Variable unterschieden werden.
Dokument
Dokument
Dokument
Inhalt
In der Abbildug der <sw-unit> auf eine SI-Einheit wird ein zusätzliches Element <si-unit> eingeführt.
Grund: Dies wird benötigt, wenn man mit Werkzeugen arbeitet, die nur mit SI-Einheiten rechnen können.
Dokument
Dokument
Dokument
Dokument
Physikalischer Datentyp bei Implementierung von Variablen eingeführtt, Basisdatentyp/C-Typ bei Parametern eingeführt, Maßeinheiten im Datadictionary, weitere Elemente für verschiedene Fragmentierungsmodelle
Grund: Erweiterung, Verbesserung, Fragmentierung
Dokument
Dokument
Beispiele hinzugefügt, Redaktionelle Überarbeitung
Grund: Verständlichkeit
Dokument
Dokument
Redaktionelle überarbeitung von 1.2. Phasenmodell zur Erstellung von Software
Grund: Übersichtlichkeit, Verständlichkeit
Dokument
Dokument
Inhalt
Inhalt
Inhalt
Inhalt
Inhalt
Inhalt
Variantenbehandlung, Inhaltsmodell Software neu strukuriert
Grund: Vervollständigung
Dokument
Dokument
Inhalt
Inhalt
Dokument
Dokument
aktuelle Near&Far Grafiken eingebaut
Grund: Aktualisierung
Dokument
Erweiterung Beschreibung der Elemente.
Grund: Vervollständigung.
Inhalt
Ebenen der Standardisierung eingebaut
Grund: Erweiterung
Dokument
Inhalt
Inhalt
Schreibfehler korrigiert
Grund: Qualitätssteigerung
Dokument
Inhalt
Changes eingeführt
Grund: Zur gezielten Weiterentwicklung
Inhalt
Dokument
Umstellung auf SGML.
Grund: Arbeitskreisbeschluß.
Dokument
Inhalt
Inhalt
Inhalt
Inhalt
Inhalt
Inhalt
Inhalt
Enthaltene Änderungen
Datum
Kapitel
Änderung
Bezug
10.7.98
Gesamt
Dokument in neue Dokumentationsstruktur (entprechend TR-DOV übernommen)
Grund: Neue Struktur wurde festgelegt
Inhalt
27.4.98
Gesamt
Redaktionelle Überarbeitung, Bereinigung der Strukturen
Grund: Erstellung des Abschlußdokumentes
Inhalt
5.3.98
Gesamt
Beginn der redaktionellen Überarbeitung
Grund:
Inhalt
16.12.97
Gesamt
Ersterstellung
Grund: Veröffentlichung der ersten offiziellen Version
Dokument
25.08.97
Gesamt
Ersterstellung
Grund: Veröffentlichung der ersten offiziellen Version
Dokument
12.08.97
Gesamt
Ändern des Inhaltsmodells von Variablen
Grund: Bei Variablen muß zwischen der Definition und dem Zugriff auf eine Variable unterschieden werden.
Dokument
Aktualisierung der Grafiken
Grund: Vollständigkeit, Aktualisierung
Dokument
Redaktionelle Überarbeitung
Grund: Vollständigkeit, Aktualisierung
Dokument
Versionierung von Variablen
Grund: Entspricht der Praxis
Inhalt
17.06.97
Gesamt
In der Abbildug der <sw-unit> auf eine SI-Einheit wird ein zusätzliches Element <si-unit> eingeführt.
Grund: Dies wird benötigt, wenn man mit Werkzeugen arbeitet, die nur mit SI-Einheiten rechnen können.
Dokument
Mehrere Datadictionaries
Grund: Es gibt Werkzeuge, die Datadictionaries funktionsspezifisch behandeln.
Dokument
Projektdaten eingeführt
Grund: Vollständigkeit
Dokument
In <sw-function-variant> die Parameterinhalte analog zu den Datadictionaries geändert.
Grund: Bereinigung
Dokument
10.04.1997
Gesamt
Physikalischer Datentyp bei Implementierung von Variablen eingeführtt, Basisdatentyp/C-Typ bei Parametern eingeführt, Maßeinheiten im Datadictionary, weitere Elemente für verschiedene Fragmentierungsmodelle
Grund: Erweiterung, Verbesserung, Fragmentierung
Dokument
Redaktionelle Überarbeitung
Grund: Übersichtlichkeit, Schreibfehler beseitigt
Dokument
17.02.1997
Gesamt
Beispiele hinzugefügt, Redaktionelle Überarbeitung
Grund: Verständlichkeit
Dokument
Redaktionelle Überarbeitung
Grund: Übersichtlichkeit, Schreibfehler beseitigt
Dokument
13.01.1997
Gesamt
Redaktionelle überarbeitung von 1.2. Phasenmodell zur Erstellung von Software
Grund: Übersichtlichkeit, Verständlichkeit
Dokument
Aktionsliste in Changes eingebaut
Grund: Vereinheitlichung der Vorgehensweise
Dokument
Einführung von physical types in (2.2.3.2. Physikalische Datentypen)
Grund: Arbeitsweise von Anwendern (mit Excel-Listen)
Inhalt
Einführung von Maßeinheiten bei Parameterinhalten (5.2. [paramunit] Parameterinhalte brauchen eine Maßeinheit).
Grund: Die Parameterinhalte werden verwendet, um physikalische Daten zu dokumentieren und mit anderen Systemen auszutauschen. Bei einem Austausch ist ggf. nicht das ganze Datenlexikon verfügbar. Daher müssen die Maßeinheiten zumindest optional angebbar sein.
Inhalt
Die Parameterinhalte müssen nicht nur als Integergrößen darstellbar sein (5.3. [paramhex] Parameterinhalte auf Integer/HEX/Adressniveau).
Grund: Für die Dokumentation sinnvoll.
Inhalt
Parameterinhalte sollen Funktionen zuzuordnen sein (5.4. [paramfunc] Parameterinhalte müssen Funktionen zuordenbar sein).
Grund: Im Autonom-Betrieb kann man eine funktionsorientierte Datenverwaltung aufsetzen.
Inhalt
Unterstützung von Kenngrößenstrukturen (5.5. [kgrhierachie] Unterstützung von Kenngrößenhierarchien).
Grund: Werden in der Praxis bereits eingesetzt.
Inhalt
Einführung von Notiz-Objekten ( 5.8. [annot] Notizobjekte<annotation>
Grund: siehe daselbst
Inhalt
04.08.96
Gesamt
Variantenbehandlung, Inhaltsmodell Software neu strukuriert
Grund: Vervollständigung
Dokument
Kapitel 4.6 Inhaltsmodell Software mit Unterkapiteln neu strukturiert.
Grund: Qualitätssteigerung
Dokument
Beschreibung der Elemente erweitert.
Grund: Vervollständigung
Inhalt
Beschreibung der Attribute neu aufgenommen.
Grund: Vervollständigung
Inhalt
Referenzen innerhalb der Software.
Grund: Vervollständigung
Dokument
Beschreibung von allgemeinen Strukturen
Grund: Qualitätssteigerung
Dokument
03.07.96
Gesamt
aktuelle Near&Far Grafiken eingebaut
Grund: Aktualisierung
Dokument
24.06.96
Gesamt
Erweiterung Beschreibung der Elemente.
Grund: Vervollständigung.
Inhalt
24.06.96
Gesamt
Ebenen der Standardisierung eingebaut
Grund: Erweiterung
Dokument
Inhaltsmodell Software bereinigt.
Grund: Qualitätssteigerung
Inhalt
Weitere Änderungen aus Sitzung vom 3.6.96
Grund: Nachtragen
Inhalt
3.6.96
Gesamt
Schreibfehler korrigiert
Grund: Qualitätssteigerung
Dokument
Änderungen aus Sitzung vom 3.6.96 eingebaut.
Grund: AG-Beschluß
Inhalt
15.5.96
Gesamt
Changes eingeführt
Grund: Zur gezielten Weiterentwicklung
Inhalt
Weitere Änderungen aus letzter Sitzung?
Grund: noch nachtragen
Dokument
23.4.1996
Gesamt
Umstellung auf SGML.
Grund: Arbeitskreisbeschluß.
Dokument
Einbau der Struktur in From von NEAR&FAR.
Grund: Arbeitskreisbeschluß.
Inhalt
Erweiterung der Struktur.
Grund: Abgleich mit ASAP u. Bei Bosch verwendeten Strukturen.
Inhalt
Beschreibung der SGML-Elemente.
Grund: Erweiterung
Inhalt
<sw-params> wurden ins Datendictionary übernommen.
Grund: Kenngrößen werden funktionsübergreifend referenziert.
Inhalt
<sw-base-type> <in sw-variable>
Grund: Der Basistyp ist variablen-spezifisch.
Inhalt
In <sw-desc> <prms> entfernt.
Grund:
Inhalt
Richtung (direction) als Attribut von <sw-variable-ref unter <sw-function-variables> implementiert.
Grund:
Inhalt


1. Hinweise zum Software-Entwicklungsprozeß

Strukturelle Grundlagen
1. Hinweise zum Software-Entwicklungsprozeß

Inhalt dieses Kapitels:
  • 1.1. Zusammenarbeit zwischen Hersteller und Zulieferer
  • 1.2. Phasenmodell zur Erstellung von Software
  • 1.3. Sprachebenen


1.1. Zusammenarbeit zwischen Hersteller und Zulieferer

Die in Hersteller-Zulieferer-Szenarien dargestellten Szenarien bzgl. Zusammenarbeit bei der Software-Entwicklung zwischen Hersteller und Zulieferer wurden bei der Definition der MSRSW.DTD berücksichtigt.
Abbildung 1: Hersteller-Zulieferer-Szenarien
Black Box | Alle Entwicklungen laufen beim Zulieferer. Der Zulieferer erstellt eine komplette Dokumentation.
Grey Box | Hersteller und Zulieferer haben jeweils einen definierten Satz von Steuergeräte-Funktionen für die sie verantwortlich sind. Die jeweiligen Entwicklungsergebnisse werden zusammengefaßt.
White Box | Hersteller und Zulieferer arbeiten gemeinsam an Steuergeräte-Funktionen. Es findet ein laufender Austausch, auch von einzelnen Teilen (z.B. Variablendefinitionen usw.) statt.


1.2. Phasenmodell zur Erstellung von Software

In diesem Kapitel wird ein Phasenmodell für die Erstellung von Software skizziert. Es stellt eine gemeinsame Verständnisgrundlage aller MSR-Beteiligten dar. Die Phasen können in Schleifen wiederholt werden.
Auf Basis dieses Phasenmodells werden diejenigen Ergebnisse identifiziert, die zwischen Hersteller und Zulieferer ausgetauscht werden.


1.2.1. Systemanalyse

In der Systemanalyse wird das System auf logischer Ebene beschrieben. Das entstehende logische Funktionsmodell kann simulierbar sein (z.B. in Matrix-X bzw. Ascet). Für Systemanalyse und Systemdesign werden die gleichen Strukturen (und damit auch die gleiche DTD) verwendet.
Funktionsanalyse
Die Funktionsanalyse enthält die Beschreibung des Kontexts, der Funktionen (hierarchisch, inkl. Diagnosefunktionen, Sicherheitsfunktionen, etc.) und der Informationsflüsse (informell). Je Funktion werden eine formale Definition, eine informelle Beschreibung, Applikationshinweise und Kundendiensthinweise dokumentiert (vgl Funktionsvariante).
Beschreibung der zeitlichen Abhängigkeiten
Die zeitlichen Abhängigkeiten können mittels RT-Analyse, Zustandsdiagrammen, Petri-Netzen, etc. modelliert werden.


1.2.2. Analyse - Review

Der Inhalt des Analyse-Reviews kann durch firmeninterne Richtlinien bestimmt werden.
Review-Protokoll
Das Protokoll kann die Feststellung der Vollständigkeit, der Widerspruchsfreiheit, der Testbarkeit, etc. der geforderten Funktionen enthalten.

Review-Inhalte werden nicht modelliert. Man kann MSRREPORT.DTD mit dem Element <changes> auch für Review-Protokolle verwenden.


1.2.3. Systemdesign

Beim Systemdesign wird aus dem logischen Funktionsmodell das physikalische Funktionsmodell abgeleitet.
Physikalisches Funktionsmodell
Die Funktionsmodell enthält die Beschreibung des Kontexts, der implementierten Funktionen (hierarchisch, inkl. Diagnosefunktionen, Sicherheitsfunktionen, etc.) und der Informationsflüsse (informell).
Je Funktion werden eine formale Definition, eine informelle Beschreibung, Applikationshinweise und Kundendiensthinweise dokumentiert (vgl. Funktionsvariante).
Beschreibung der zeitlichen Abhängigkeiten
Beim Systemdesign werden z.B. Funktionen zu Tasks zusammengefaßt und Rechenebenen. zugeordnet (Scheduling-Tabellen)
MSRSW.DTD 1.1.0 besitzt außer bei Variablen keine expliziten Beschreibungsmittel für zeitliche Abhängigkeiten. Diese müssen daher informell bei der Funktionsbeschreibung (<sw-function-desc>) bzw. in <add-info> beschrieben werden..
Partitionierung in Hardware und Software
Die Partitionierung erfolgt unter Berücksichtigung von Resourcen und anderen Randbedingungen (z.B. Kosten, etc.).
Software-Architektur
Die Software-Architektur kann in der MSRSW.DTD beschrieben werden, in dem ein <sw-function> angelegt mit <sw-function-class> = architecture.
Hardware-Architektur
wird in MSRSYS.DTD beschrieben.
Testspezifikation
wird in MSRSYS.DTD beschrieben.


1.2.4. Design - Review

Der Inhalt des Design-Reviews kann durch firmeninterne Richtlinien bestimmt werden.
Review-Protokoll
Das Protokoll kann die Feststellung der Vollständigkeit, der Widerspruchsfreiheit, der Testbarkeit, etc. der geforderten Funktionen enthalten. Hierfür kann MSRREP.DTD verwendet werden.


1.2.5. Codierung

Funktionsmodule
Im Rahmen der Codierung werden die im Systemdesign definierten Funktionen implementiert. Diese Implementierung kann ggf. auch duch Codegeneratoren erfolgen.
In dieser Phase entstehen Details des Datenlexikons (<sw-data-dictionaries>) wie Kenngrößenstrukturen (<sw-params>), Variablen <sw-variables>, Umrechnungsformeln (<sw-compu-methods>). Darüber hinaus werden auch Quelltexte, Compilersteuerfiles u.s.w. erstellt.


1.2.6. Modultest

Formaler und funktionaler Test des codierten Software-ModulSoftware-Moduls unter Laborbedingungen.
Testbericht
Der Testbericht beschreibt das Umfeld, die Beaufschlagung sowie die Ergebnisse des Modultests. Hierfür kann MSRREP.DTD verwendet werden.


1.2.7. Integration

In dieser Phase werden die einzelnen Module zusammengeführt. Die Integration wird auf der Test- und/oder der Zielumgebung durchgeführt.
Datenstand
Das konkrete Ergebnis der Integration ist der ProgrammstandProgrammstand.


1.2.8. Applikation (Kalibrierung)

Bei der Applikation wird die Steuerungseinrichtung auf ein konkretes Fahrzeug bzw. einen konkreten Motor angepaßt. Dies geschieht durch Festlegung der jeweiligen Kenngrößeninhalte.
Datenstand
Das konkrete Ergebnis der Applikation ist der DatenstandDatenstand.


1.2.9. Systemtest

für die Erstellung des Testberichtes kann MSRREP.DTD verwendet werden.


1.3. Sprachebenen

Bei Software-Funktionen in Steuergeräten kann man zwischen verschiedenen Sprachebenen unterscheiden (siehe Sprachebenen). Insbesonders gibt es eine Standardisierungsebene, in der Software-technische Standards bzgl. Dokumentation, Variablen- und Kenngrößen-Spezifikation, C-Header, C-Source und Betriebssystem-Anweisungen angesiedelt sind.
Abbildung 2: Sprachebenen
Die Standardisierung auf dieser Ebene wird in mehreren Standardisierungs-Projekten wie MSR-AG MEDOC, MSR-AG Codegeneratoren und OSEK betrieben (siehe Standardisierungs-Projekte ).
Abbildung 3: Standardisierungs-Projekte
Auf unterster Ebene hat eine Standardisierung bereits stattgefunden: ASAP2-File und Hex-File.


2. Strukturierung

Strukturelle Grundlagen
2. Strukturierung

Inhalt dieses Kapitels:
  • 2.1. Allgemeines
  • 2.2. Inhaltsmodell Software
  • 2.3. Referenzen


2.1. Allgemeines

Inhalt dieses Kapitels:
  • 2.1.1. Verbindung zur MSRSYS
  • 2.1.2. Variantenbehandlung
  • 2.1.3. Ablage des Datenlexikons
  • 2.1.4. Ablage von Kenngrößeninhalten
  • 2.1.5. Namensräume
  • 2.1.6. Referenzen innerhalb der Software


2.1.1. Verbindung zur MSRSYS

In der MSRSYS.DTD kann das Verhalten einer Komponente als Funktionshierarchie beschrieben werden (<behaviour>). Diese Beschreibung ist unabhängig von der Implementierung in Hardware bzw. Software.
Für die Realisierung in Software dient die MSRSW.DTD. Diese ist funktionsorientiert [image] aufgebaut. Der Zusammenhang zwischen Funktionen in MSRSYS.DTD und MSRSW.DTD kann über Referenzierung (<sw-fulfils>) hergestellt werden.

Objektorientierte Strukturen sind für eine spätere Version vorgesehen.


2.1.2. Variantenbehandlung

Bzgl. Varianten wurden folgende Szenarien betrachtet:
interne Varianten | Diese Varianten werden vom SG ohne massive Umprogrammierung beherrscht. Das Steuergeräte-Programm kann zwischen mehreren Varianten allein duch Umprogrammierung eines Codewortes (i.A. über Diagnoseleitung am Bandende) oder gar durch Anlegen von Steckerbrücken umschalten. Diese Variantenart ist letztlich eine Funktion der Software selbst.
externe Varianten | Diese Varianten betreffen Geräte, die sich sehr ähnlich sind, jedoch immer nur eine Variante beinhalten. Variantenaustausch geschieht durch weitgehende Umprogrammierung. In der Regel werden sowohl die unterschiedlichen programmierten Varianten als auch das unprogrammierte Steuergerät mit unterschiedlichen Sachnummern gehandhabt.
Variantenbschreibungen sind wichtig im Bereich der Funktionen (<sw-function-spec>) und der Kenngrößen-Inhalte (<sw-param-contents>).
Abbildung 4: Funktionsvariante


2.1.2.1. Variantenabhängige Kenngrößen

Die Beschreibung der <sw-param-contents> ist möglich in <sw-function-spec-variant> und in <sw-param-contents-spec>. Die implizite Variantenbehandlung <sw-param-content> ist an beiden Stellen durch die Tatsache gegeben, daß in <sw-param-content> auf <sw-param> referenziert wird. <sw-function-variant> enthält einen expliziten Variantenverweis. Die Zuordnung von <sw-param> zu den Varianten ergibt sich aus den <variant-def-ref>s der <sw-function-variant>s in denen diese referenziert werden (implizite Zuordnung).
Die Zuordnung von Kenngrößen zu Varianten geschieht also ausschließlich über die Verwendung in Funktionsvarianten. Für die automatische Prüfung auf widerspruchsfreie Variantenbeschreibung von Funktionen und Kenngrößen wäre eine explizite Zuordnung von Kenngrößen zu Varianten (durch <variant-def-refs> in <sw-param>) erforderlich. Dies wird zunächst zurückgestellt, da nicht geklärt ist, ob die dadurch entstehende Komplexität erforderlich und gerechtfertigt ist [image] .

Die derzeitige Arbeitsweise der Anwender entspricht der ausschließlich implizen Variantenzuordnung.


2.1.2.2. Variantenabhängige Umrechnungsformeln

Umrechnungsformeln werden von der Hardware beeinflußt (Signalaufbereitung usw). Daher kann es vorkommen, daß unterschiedliche HW-Varianten auch unterschiedliche Umrechnungsformeln bedingen. Beispiel hierfür kann das Auswechseln eines Sensors sein, welcher gar nicht im SG eingebaut ist. Dies soll zunächst aber nicht explizt durch unser Daten/Dokumentationsmodell unterstützt werden. Die Behandlung dieses Falles geschieht vielmehr wie folgt:
  • für jede Variante wird falls erforderlich eine eigene <sw-compu-method> angelegt, die sich dann mindestens durch ihren <short-name> und auch durch <long-name> unterscheiden müssen.
  • Die variantenspezifischen <sw-compu-method>s werden referenziert in variantenspezifischen <sw-param>s bzw. <sw-variable>s. Diese müssen sich wiederum im <short-name> und <long-name> unterscheiden und können ihrerseits in <sw-function-variant> referenziert werden. Damit erfolgt die Variantenbehandlung nicht im Verborgenen (d.h. durch Aufbereitung in der DTD) sondern ausschließlich durch den Benutzer definiert.


2.1.3. Ablage des Datenlexikons

Das Datenlexikon kann sowohl global (unter <msrsw>) wie auch funktionslokal (unter <sw-function-variant>) im Dokument verteilt eingetragen werden. Es ist allerdings als ein logisches Lexikon zu behandeln. Diese Flexibilität erlaubt die Anwendung der MSRSW.DTD in verschiedenen Prozeßphasen, Prozeßmodellen. Darüberhinaus kann diese Flexibilität genutzt werden, um sich an die Möglichkeiten verschiedener Werkzeuge und deren Exportfilter anzupassen.


2.1.4. Ablage von Kenngrößeninhalten

Kenngrößeninhalte (<sw-param-contents>, vgl. 2.2.5. Spezifikation von Kenngrößeninhalten) können sowohl lokal innerhalb von <sw-function-variant> (2.2.4.1.6. Funktionsbezogene (lokale) Kenngrößeninhalte) als auch global innerhalb von <msrsw> 2.2.5. Spezifikation von Kenngrößeninhalten abgelegt werden.
Hierfür gelten folgende Konventionen:
  1. Die Zuordnung von Kenngrößen zu Funktionen geschieht ausschließlich über Referenzierung in den Funkionsbeschreibungen (<sw-param-ref> in <sw-function-variant>).
  2. Es ist möglich, in <sw-function-variant> <sw-param-content>s anzugeben. Darin dürfen nur <sw-param>s referenziert werden, die auch in <sw-function-variant> referenziert sind. Die Angabe von Kenngrößeninhalten in Funktionen muß also konsistent sein zur Zuordnung von Kenngrößen zu Funktionen.
  3. Wird für eine Kenngröße (<sw-param>) sowohl in <sw-function-variant> als auch in <sw-param-content-spec> ein Inhalt spezfiziert, hat letztere Angabe Vorrang.
  4. Werden in zwei verschiedenen Funktionen für die selbe Kenngröße Inhalte angegeben, so muß auch in <sw-param-content-spec> ein Eintrag enthalten sein. Damit kann die o.g. einfache Vorrangregel verwendet werden.
  5. Der Autor einer <sw-function-variant> hat durch Einfügung eines <sw-param-contents> die Möglichkeit zu steuern, welche Parameterinhalte er bei der Formatierung lokal mit angezeigt bekommt.
Da <sw-param-contents> sowohl bei den Funktionen als auch global für die gesamte Software (innerhalb von <msrsw> möglich ist, können verschiedene Prozesse mit der DTD betrieben werden. Es wird empfohlen:
  • Kenngrößeninhalte als Programmiervorgabe werden innerhalb von <sw-function-variant> angegeben. Damit bleibt diese Beziehung auch bei Fragmentierung auf Funktionsebene erhalten.
  • Kenngrößeninhalte als Ergebnis der Applikationsphase werden innerhalb von <msrsw> geschlossen funktionsübergreifend angegeben. <sw-param-contents> innerhalb <msrsw> (vgl. 2.2.5. Spezifikation von Kenngrößeninhalten) nimmt also einen Applikationsdatenstand auf.


2.1.5. Namensräume

Allgemein gilt, daß der <short-name> identifizierenden Charakter besitzt, insbesondere für Bezüge nach außen (z.B. ASAP). Daraus ergibt sich, daß der <short-name> innerhalb gegebener Namens (Definitions-)räume eindeutig sein muß. Diese Namensräume ergeben sich aus definierten Hierarchien in der DTD [image] . Einzelheiten finden sich in Concepts of MSR-DTD

Diese Hierarchien sind mit dem fixen Attribut f-namespace in der DTD begrenzt.


2.1.6. Referenzen innerhalb der Software

Innerhalb der Software treten an vielen Stellen Referenzen auf. Durch die Verwendung von Referenzen kann Redundanz vermieden werden.
Abbildung 5: Referenzen innerhalb der Software
Siehe Kapitel 2.3. Referenzen.
Referenzarten
Nr. | Bezeichnung | Quellelement | Zielelement | Bedeutung
1 | <sw-function-ref> | <msrsw> | <sw-function> | Verweis auf verwendete Funktion außerhalb <MSRSW> wie z.B. Betriebssystem- oder Netzwerkfunktion.
2 | <sw-variable-ref> | <sw-axis-individual> | <sw-variable> in <data-dictionary> | Verweis auf Eingangsvariable einer Kenngröße.
3 | <sw-compu-method-ref> | <sw-param-axis-values> | <sw-compu-method> | Weist den Achswerten einer Kenngröße eine Umrechnungsformel zu.
4 | <sw-compu-method-ref> | <sw-variable> | <sw-compu-method> | Weist einer Variablen eine Umrechnungsformel zu.
5 | <sw-param-ref> | <sw-param-content> | <sw-param> | Ordnet einen Parameterinhalt einem Parameter zu.
6 | <sw-variable-ref> | <sw-passing-variables> , <sw-local-variables> | <sw-variable> in <data-dictionary> | Verweis auf verwendete Variable einer Funktion.
7 | <sw-param-ref> | <sw-function-variant> | <sw-param> | Verweis auf verwenete Parameter einer Funktionsvariante.
8 | <variant-def> | <variant-def> | Variante in Projektdaten | Ordnet einer Funktionsvariante ein oder mehrere fiktive Varianten zu.
9 | <fulfills-ref> | part, sw-function | function | Ordnet einem Part oder einer Software-Funktion diejenigen (Verhaltens-)Funktionen (keine, eine oder mehrere) zu, die es bzw. sie realisiert.
10 | <sw-function-ref> | <sw-data-dictionary> | <sw-function> | Erlaubt es, ein Datenlexikon (fragment) einer bestimmten Funktion zuzuweisen. Damit kann man auch funktionsorientierte Datenlexika schreiben, wenn man <sw-function> nicht ausfüllt.
10 | <sw-function-ref> | <sw-param-contents> | <sw-function> | Erlaubt es, Dateninhalte einer bestimmten Funktion zuzuweisen auch wenn man <sw-function> nicht ausfüllt ist.
10 | <sw-function-ref> | <sw-param-content> | <sw-function> | Erlaubt es, den Inhalt einer Kenngröße einer bestimmten Funktion zuzuweisen auch wenn man <sw-function> nicht ausfüllt ist.
10 | <sw-function-ref> | <sw-decomposition> | <sw-function> | Hier werden Verweise auf verwendete Funktionen eingetragen.
11 | <sw-param-ref> | <sw-param-content> | <sw-param> | Ordnet einen Parameterinhalt einem Parameter zu.


2.2. Inhaltsmodell Software

Die Software umfaßt die folgenden Haupteile (siehe Softwarestruktur, oberste Ebene.) (Die Softwarestrukur wird nachfolgend in Form von Near&Far -Grafiken (vgl. B. Erklärung der Near&Far-Symbole) dargestellt).
Abbildung 6: Softwarestruktur, oberste Ebene.
<short-name> | Kurzname für das gesamte Dokument.
<project-data> | Projektdaten (2.2.2. Projektdaten)
<admin-data> | Verwaltungsdaten (E.1. Administrative Daten)
<introduction> | kurze Einführung (E.7. Introduction Einführung Introduction )
<sw-function-refs> | Verweis auf externe Software (2.2.1. Verweise auf "externe" Software)
<sw-data-dictionary-spec> | Globales Datenlexikon (2.2.3. Datenlexikon)
<sw-function-spec> | Detaillierte Spezifikation der Software-FunktionSoftware-Funktionen (2.2.4.1.1. Funktionsdefinition)
<sw-param-contents-spec> | Globale Parameterinhalte (2.2.5. Spezifikation von Kenngrößeninhalten)
<add-spec> | Zusatzliche, halbformale Spezifikationen (2.2.7. Zusätzliche Spezifikationen)
<sw-glossary> | Erlaubt die Erfassung eines Glossars (2.2.6. Glossar für das Dokument)
<locs> | Platzhalter für dokumentübergreifende Referenzierungen. Details siehe Concepts of MSR-DTD


2.2.1. Verweise auf "externe" Software

Mit Hilfe von <sw-function-refs> können Funktionen aus anderen Steuergeräten referenziert werden. Beispiele hierfür sind mehrfach verwendete Funktionen wie Betriebssystem- oder Netzwerkmanagementfunktionen.


2.2.2. Projektdaten

Hier können Informationen zum Projekt (<project-data>) eingetragen werden. Dies sind Angaben zur Firma, zu Mitarbeitern und allgemeine Projektdaten. In den allgemeinen Projektdaten können Angaben zu folgenden Punkten spezifiziert werden:
  • Auftragsbegründung
  • Ziele
  • Muster
  • Variantenspezifikation
  • Abgrenzung gegeenüber anderen Projekten
  • Parallelentwicklungen
  • Integrationsfähigkeit
  • Abnahmebedingungen
  • Terminpläne
  • Protokolle, Besprechungsnotizen
Abbildung 7: Projektdaten


2.2.3. Datenlexikon

Im Datenlexikon <sw-datadictionary-spec> werden die Datenstrukturen der beschriebenen Steuergerätesoftware.
Ein Datenlexikon (<sw-datadictionary>) umfaßt:
<desc> | Kurzbeschreibung
<sw-data-dictionary-class> | Dieses Element kann verwendet werden, um die Rolle des vorliegenden Datenlexikon im Prozeß zu kennzeichnen. So können z.B. alle geänderten Variablen in ein <sw-datadictionary> mit der Klasse changed abgelegt werden.
<sw-function-ref> | Erlaubt es, ein Datenlexikon einer bestimmten Funktion zuzuordnen (2.1.6. Referenzen innerhalb der Software)
<sw-units> | Maßeinheiten, die in der Dokumentation verwendet werden (2.2.3.1. Maßeinheiten)
<sw-physic-types> | Physikalische Datentypen (2.2.3.2. Physikalische Datentypen)
<sw-variables> | Variablen (2.2.3.3. Variablen)
<sw-params> | Strukturen von Kenngrößen (2.2.3.4. Kenngrößenstrukturen)
<sw-compu-methods> | Umrechnungsformeln (2.2.3.5. Umrechnungsformeln)
<sw-adressing-methods> | Adressierverfahren für Kenngrößen und Variablen (3.2. Beschreibung der Elemente)
<sw-param-record-layouts> | Vorschriften zur Ablage der Parameter im Steuergerätespeicher. Sie dienen zur Steuerung des Zugriffes von z.B. Applikationssystemen. (3.2. Beschreibung der Elemente)
<sw-code-syntaxes> | Vorschriften zur Generierung von Quellcode für den Compiler der Steuergerätesoftware (3.2. Beschreibung der Elemente)
Abbildung 8: Data-Dictionary


2.2.3.1. Maßeinheiten

Unter <sw-units> können Maßeinheiten beschrieben werden. Eine Maßeinheit besitzt eine Lang- und eine Kurzbezeichnung (<long-name> bzw. <short-name>). Mit dem Element <sw-unit-display> kann die formatierte Ausgabe bestimmt werden.
Zur Abbildung der <sw-unit> auf eine SI-Einheit wird das Element <si-unit> benutzt. Dieses Element besitzt ein Attribut für jede SI-Basiseinheit mit dem die zugehörigen Exponenten angegeben werden [image] . Dies wird benötigt wenn man mit Werkzeugen arbeitet, die mit SI-Einheiten rechnen können.
Diese Abbildung auf SI-Einheiten macht die verwendeten Maßeinheiten vergleichbar.
Es ist möglich, einen Bezug zu anderen Maßeinheiten (vorzugsweise SI-Einheiten) über <sw-unit-ref> herzustellen. Die Vorschrift zur Umrechnung auf diese Einheit steht in <sw-unit-to-ref-method>. Die Vorschrift zur Umrechnung von dieser Einheit steht in <sw-unit-from-method>. Diese Methoden werden als 6 parameter entsprechend <sw-asap-6-prm-method> spezifiziert.
Abbildung 9: Maßeinheiten
Folgendes Beispiel verdeutlicht die Zusmmenhänge:
<sw-units>
   <sw-unit>
      <long-name>Kilometer pro Stunde</long-name>
      <short-name>kmh</short-name>
      <sw-unit-display>km/h</sw-unit-display>
      <sw-unit-ref>mps</sw-unit-ref>
      <sw-unit-to-ref-method>0 1 0 0 3600 0</sw-unit-to-ref-method>
      <sw-unit-from-ref-method></sw-unit-from-ref-method>

   </sw-unit>
   <sw-unit>
      <long-name>Meter pro Sekunde</long-name>
      <short-name>mps</short-name>
      <si-unit length-expo = "1" time-expo = "-1"></si-unit>
      <sw-unit-display></sw-unit-display>
   </sw-unit>
</sw-units>

Das Element kann auch Text aufnehmen, weil grundsätzlich keine Elemente als leer definiert wurden. Eventuell vorhandener Text wird ignoriert.


2.2.3.2. Physikalische Datentypen

In den frühen Phasen der Entwicklung von Steuergerätesoftware wird unabhängig von von der Implementierung in physikalischen Größen gearbeitet. Zur Unterstützung dieser Phase können im Datenlexikon global physikalische Datentypen (<sw-physic-types>) definiert werden.
Bei der Definition von Variablen (<sw-variable>) kann auf die bereits im vorhandenen physikalischen Datentypen durch Referenzierung (<sw-physic-type-ref>) Bezug genommen werden werden.
Es besteht jedoch auch die Möglichkeit direkt bei der Variablen den physikalischen Datentyp zu definieren (<sw-physic-type-1>). Weitere Einzelheiten siehe Physikalische Datentypen .
Abbildung 10: Physikalische Datentypen
Folgendes Beispiel zeigt die Definition eines physikalischen Datentyps:
<sw-physic-type>
   <long-name>Drehzahl</long-name>
   <short-name>n</short-name>
   <desc></desc>
   <sw-unit-ref>Umin</sw-unit-ref>
   <sw-limits>
      <phys><phys-min>0</phys-min><phys-max>8000</phys-max></phys>
      <coded><coded-min>0</coded-min><coded-max>256></coded-max></coded
   </sw-limits>
   <sw-resolution>20</sw-resolution>
   <sw-data-type-scaling>8bit</sw-data-type-scaling>
   <sw-variable-sample-rate>10</sw-variable-sample-rate>
   <sw-var-init-value>0</sw-var-init-value>
   <sw-var-not-av-value></sw-var-not-av-value>
</sw-physic-type>


2.2.3.3. Variablen

Variablen werden im Datadictionary definiert (<sw-variables>). Sie sind grundsätzlich global zu behandeln, d.h. ihr <short-name> muß eindeutig sein.
Funktionen verwenden diese Variablen zum Austausch von Informationen. Dazu werden diese Variablen entsprechend ihrer Verwendung referenziert (<sw-function-variables>).
Variablen werden aber auch als Eingangsgrößen von Kenngrößen und als Zwischenwerte verwendet.
Variablen können mit <admin-data> versehen werden, um z.B. Bibliotheksmanagement zu unterstützen.
Die Struktur zur Beschreibung der Software-Variablen ist rekursiv. Dies ermöglicht den Aufbau von hierarchischen Variablenstrukturen, die z.B. ein STRUCT-Konstrukt (in der Programmiersprache C) abbilden können.
Die Struktur von<sw-variable> ist in Variable dargestellt. Beschreibung der Elemente siehe 3.2. Beschreibung der Elemente.
Abbildung 11: Variable
Bei der Beschreibung von Datentypen (Variablen und Kenngrößen) ist zu beachten, daß Daten stets eine interne (coded) und eine externe (physikalische) Darstellung besitzen (z.B. für eine Motordrehzahl intern 0..200: extern 0..2000 U/min, intern 201..254: nicht definiert und intern 255: Motordrehzahl nicht verfügbar). Zwischen diesen Darstellungen wird über die in <sw-compu-method-ref> referenzierte Umrechnungsformel konvertiert.
Daher kann <sw-limits> sowohl physikalisch (<phys>)als auch codiert (<phys>) angegeben werden.
Der interne Wert für nicht verfügbar wird in <sw-var-not-av-value> eingetragen. Dies ist der Wert, den die Variable annimmt, wenn der zugehörige externe Wert nicht verfügbar ist (sei es daß er noch nicht erfaßt ist, oder aber ein Fehler vorliegt). Einen externen Wert für nicht verfügbar kann es nicht geben, da er ja nicht verfügbar ist.
Nicht alle Variablen werden in einem Applikatinssystem für die Kalibrierung benötigt. Diese Tatsache wird durch das Attribut [calibration] dokumentiert Es kann die Werte calibration, no-calibration und not-in-memory annehmen. Dieses Attribut wird genauso bei Kenngrößen verwendet.
<sw-variable>
   <long-name>Motortemperatur</long-name>
   <short-name>tmot</short-name>
   <desc></desc>
   <sw-variable-implementation>
      <sw-base-type>ub</sw-base-type>
      <sw-addressing-method-ref>NearRamByte></sw-addressing-method-ref>
      <sw-compu-method-ref>rel_ub_b127p5</sw-compu-method-ref>
      <sw-code-syntax-ref>RamNearUb</sw-code-syntax-ref>
   </sw-variable-implementation>
</sw-variable>


2.2.3.4. Kenngrößenstrukturen

Ein Steuergeräte-Programm kann über Kenngrößen parametriert und quantitativ auf das jeweilige Zielfahrzeug angepaßt werden. Durch das Belegen dieser Kenngrößen mit geeigneten Werten wird das Steuergeräteprogramm an den zu bedienenden Motor in seinem Umfeld (z.B. Karosserie, Abgasgesetzgebung) angepaßt. Diesen Anpassungsvorgang nennt man Applikation bzw. Kalibrierung.
Es ist zu unterscheiden zwischen der Struktur einer Kenngröße und ihren Dateninhalten. Die Kenngrößenstrukturen werden im Datenlexikon unter <sw-params> (vgl. Parameter ) beschrieben. Die Kenngrößeninhalte stehen in <sw-param-contents>.
Abbildung 12: Parameter
Die Verwendung von Kenngrößen in Funktionen erfolgt durch Referenzierung (<sw-param-ref>). Dabei wird durch das Attribut [owns] mit dem möglichen Wert "noowns" [image] angegeben, ob die Kenngröße dieser Funktion zuzuordnen ist bzw. in dieser Funktion definiert wird.
Über ein Attribut [calibration] kann spezifiziert werden:
calibration | Die Inhalte der Kenngröße werden in der Applikationsphase ( vgl. 1.2.8. Applikation (Kalibrierung)) auf das jeweilige Zielfahrzeug angepaßt (appliziert).
no-calibration | Die Inhalte der Kenngröße können nicht durch Applikationssyteme usw. verändert, sondern nur gelesen werden.
not-in-memory | Diese Kenngröße wird nicht im EPROM des Steuergerätes abgelegt. Ihre Inhalte werden während der Software-Entwicklung verarbeitet (z.B. zur Konfiguration über Headerfiles). Sie sind daher in der Applikationsphase weder lesbar noch veränderbar.
Es gibt verschiedene Klassen von Kenngrößen. Diese werden einerseits durch die Belegung von <sw-param-class> unterschieden, andererseits durch entsprechende Ausprägung der Strukturen gebildet.
Man unterscheidet folgende Kenngrößenklassen:
Kennwert Ein Kennwert (<sw-param-single-value>) ist eine Kenngröße, die aus einem einzelnen Wert besteht. Hiermit kann beispielsweise eine Drehzahlgrenze abgebildet werden.

Die Struktur des Kennwertes ist in Kennwert dargestellt.
Systemkonstante Eine Systemkonstante ist ein spezieller Kennwert (<sw-param-single-value> gekennzeichnet durch [calibration]=not-in-memory), welcher z.B. zur Anpassung von Umrechungsformeln dient. Sie wird nicht im Steuergerät abgelegt.

Kenntext Ein Kenntext (<sw-param-text>) ist eine Kenngröße, die aus einem einzelnen Text besteht. Hiermit kann beispielsweise Meldungen für das Armaturenbrett dargestellt werden.

Kennlinie Bei einer Kennlinie (<sw-param-array-x>) wird die Ausgangsgröße in Abhängigkeit von einer Eingangsgröße durch das Steuergeräte-Programm berechnet. Mathematisch betrachtet ist die Kennlinie eine Funktion, bei der gilt: Ausgangswert = f(Eingangswert).

Diese Funktion ist dabei als Linienzug festgelegt, indem zu einer (durch <max-count> begrenzten) Anzahl von Stützstellen (<sw-param-axis-x>) der zugehörige Funktionswert (<sw-param-axis-value>) angegeben wird. Zwischen zwei Stützstellen wird im Steuergeräte-Programm üblicherweise linear interpoliert, außerhalb konstant extrapoliert.
Die Struktur der Kennline ist in Kennlinie dargestellt.
Festkennlinie Bei Festkennlinien können die Stützstellen nicht frei festgelegt werden, sondern werden durch shift (<shift>) und offset (<offset>) im Steuergeräte-Programm berechnet (<sw-axis-shift-offset>). Die Festkennlinie wird ebenfalls als <sw-param-array-x> dargestellt, wobei <sw-axis-shift-offset> verwendet wird.

Kennfeld Bei einem Kennfeld (<sw-param-array-xy>) wird die Ausgangsgröße in Abhängigkeit von zwei Eingangsgrößen durch das Steuergeräte-Programm berechnet. Ansonsten ist der Aufbau wie bei einer Kennlinie.

Festkennfeld Wie bei einer Festkennlinie können auch hier die Stützstellen nicht frei gewählt werden. Das Festkennfeld wird ebenfalls als <sw-param-array-xy> dargestellt, wobei für beide Achsen <sw-axis-shift-offset> verwendet wird.

Gruppenkennlinie Gruppenkennlinien haben keine eigenen Stützstellen, sondern benutzen gemeinsam mit anderen Gruppenkennlinien oder -feldern die gleichen Stützstellen (<sw-param-group-axis> referenziert in <sw-axis-grouped>). Das Gruppenkennline wird ebenfalls als <sw-param-array-x> dargestellt, wobei für die Achse <sw-axis-grouped> verwendet wird.

Gruppenkennfeld Gruppenkennfelder haben keine eigenen Stützstellen, sondern benutzen gemeinsam mit anderen Gruppenkennlinien oder -feldern die gleichen Stützstellen (Gruppenstützstellen). Das Gruppenkennfeld wird ebenfalls als <sw-param-array-xy> dargestellt, wobei für beide Achsen <sw-axis-grouped> verwendet wird (vgl. Beispiel für ein Gruppenkennfeld).

Kennwerteblock Ein Kennwerteblock <sw-param-value-block> faßt mehrere (<count>) identisch aufgebaute Kennwerte zu einem Block zusammen. So könnte z.B. ein Kennwert, der für jeden Zylinder des Motors einzeln anzulegen ist, als Kennwerteblock mit 4 Elementen dargestellt werden.

Alle Kennwerte im Block besitzen die gleichen Eigenschaften. Jeder Kennwert erhält jedoch eine eigene Bezeichnung (<label>), in der die Verwendung des Wertes beschrieben werden kann. Der Kennwerteblock wird immer geschlossen behandelt. Daher können die Komponenten des Kennwerteblockes nicht einzeln referenziert werden.
Kennwertestruktur Eine Kennwertestruktur (<sw-params> in <sw-param>) faßt mehrere verschieden aufgebaute Kenngrößen zusammen. Damit können z.B. die Parameter einer Reglerstruktur dargestellt werden (bgl. Beispiel für eine Kennwertestruktur:).

Gruppenstützstellen Gruppenstützstellen (<sw-param-group-axis>) legen die Stützstellen fest, die von mehreren Gruppenkennlinien oder Gruppenkennfeldern gemeinsam benutzt werden (<sw-param-ref> in <sw-axis-grouped>).

Durch <sw-param-class>wird festgelegt, um welche Kenngrößenart es sich handelt (z.B. Kennlinie). Hierfür sollen die normierten Bezeichnungen von ASAP verwendet werden. Dies sind [image] :
Belegung von <sw-param-class>
Wert | Bedeutung | Anmerkung
SYSTEM_CONSTANT | Systemkonstante | Entspricht strukturell einem Festwert mit [calibration]=not-in-memory
VALUE | Kennwert |
CURVE_INDIVIDUAL | Kennlinie |
MAP_INDIVIDUAL | Kennfeld |
CURVE_FIXED | Festkennlinie |
MAP_FIXED | Festkennfeld |
CURVE_GROUPED | Gruppenkennlinie |
MAP_GROUPED | Gruppenkennfeld |
ASCII | Kenntext |
STRUCTURE | Kenngrößenstruktur |
VALUE_BLOCK | Kennwerteblock |
AXIS_VALUES | Gruppenstützstellen |
Beispiel für einen Kennwert
Die Struktur eines Kennwertes ist in Kennwert dargestellt.
Abbildung 13: Kennwert
Folgendes Beispiel illustriert die Anwendung:
<sw-param>
   <long-name></long-name>
   <short-name>KUP_FEN</short-name>
   <sw-param-class>value</sw-param-class>
   <desc></desc>
   <sw-param-single-value>
      <sw-param-axis-values>
         <sw-compu-method-ref>TEMPQ</sw-compu-method-ref>
      </sw-param-axis-values>
   </sw-param-single-value>
   <sw-addressing-method-ref>offset</sw-addressing-method-ref>
   <sw-param-record-layout-ref>DAMOS_KW0</sw-param-record-layout-ref>
   <sw-code-syntax-ref>cSyKwByte</sw-code-syntax-ref>
</sw-param>
Beispiel für eine Kennlinie
Die Struktur der Kennlinie ist in Kennlinie dargestellt.
Abbildung 14: Kennlinie
Nachfolgendes Beispiel illustriert die Anwendung:
<sw-param>
   <long-name></long-name>
   <short-name>etalam</short-name>
   <sw-param-class>curve_individual</sw-param-class>
   <desc></desc>
   <sw-param-array-x>
      <sw-param-axis-x>
         <sw-axis-individual>
            <sw-variable-ref>lambas</sw-variable-ref>
            <max-count>10</max-count>
         </sw-axis-individual>
      </sw-param-axis-x>
      <sw-param-axis-values>
         <sw-compu-method-ref>rel_ub-b127b5</sw-compu-method-ref>
      </sw-param-axis-values>
   <sw-addressing-method-ref>NearRomByte</sw-addressing-method-ref>
   <sw-param-record-layout-ref>KlAUbSstUbWUb</sw-param-record-layout-ref>
   <sw-code-syntax-ref>KlNearAUbSstUbUb</sw-code-syntax-ref>
</sw-param>
Beispiel für ein Gruppenkennfeld
<sw-param>
   <long-name></long-name>
   <short-name>KFAVG</short-name>
   <sw-param-class>map_grouped</sw-param-class>
   <desc></desc>
   <sw-param-array-xy>
      <sw-param-axis-x>
         <sw-axis-grouped>
            <sw-param-ref>STADGN</sw-param-ref>
      </sw-axis-grouped>
      </sw-param-axis-x>
      <sw-param-axis-y>
         <sw-axis-grouped>
            <sw-param-ref>STADGTL</sw-param-ref>
         </sw-axis-grouped>
      </sw-param-axis-y>
      <sw-param-axis-values>
         <sw-compu-method-ref>FKT256</sw-compu-method-ref>
      </sw-param-axis-values>
   </sw-param-array-xy>
   <sw-addressing-method-ref>Vek</sw-addressing-method-ref>
   <sw-param-record-layout-ref>DAMOS_GKF0</sw-param-record-layout-ref>
   <sw-code-syntax-ref>cSyGKf</sw-code-syntax-ref>
</sw-param>
Beispiel für eine Kennwertestruktur:
<sw-params>
   <sw-param>
      <long-name></long-name>
      <short-name>mrw</short-name>
      <sw-param-class>structure</sw-param-class>

      <sw-addressing-method-ref>dir</sw-addressing-method-ref>
      <sw-code-syntax-ref>cSyKggByte</sw-code-syntax-ref>

      <sw-params>

         <sw-param>
            <long-name></long-name>
            <short-name>KUP_FEN</short-name>
            <sw-param-class>value</sw-param-class>
            <desc></desc>
            <sw-param-single-value><sw-param-axis-values><sw-compu-method-ref>TEMPQ</sw-compu-method-ref>
            </sw-param-axis-values>
            </sw-param-single-value>
            <sw-addressing-method-ref>offset</sw-addressing-method-ref>
            <sw-param-record-layout-ref>DAMOS_KW0</sw-param-record-layout-ref>
            <sw-code-syntax-ref>cSyKwByte</sw-code-syntax-ref>

         </sw-param>

      </sw-params>

   </sw-param>

</sw-params>

   .
   .
   .

<sw-param-contents>

   <sw-param-content>
      <sw-param-ref>KUP_FEN</sw-param-ref>
      <sw-param-class>value</sw-param-class>
      <sw-param-content-v>
         <sw-param-values-phys>
            <v>1</v>
         </sw-param-values-phys>
      </sw-param-content-v>
   </sw-param-content>

</sw-param-contents>

folgt ASAP
Für Arrays kann "_ARRAY" angehängt werden. Bei ASAP ist das in Form von "VALUE_BLOCK_ARRAY" der Fall.
In einer künftigen DTD-Version ist vorgesehen, auch den Wert "owns" zuzulassen, und diesen als Default zu setzen.


2.2.3.5. Umrechnungsformeln

In <sw-compu-methods> wird die Abildung von physikalischen Werten in Steuergeräte-interne Werte und umgekehrt definiert (vgl. Umrechnungsformeln). Man unterscheidet vier verschiedene Umrechnungsmethoden:
Polynomdarstellung Die Umsetzung wird durch sechs Parameter (<sw-asap-6-prm-method>) spezifiziert (vgl. Beispiel für Polynomdefinition). Die werden durch Leerzeichen getrennt und bilden folgende Formel ab:

int = (a × x2 + b × x1 + c ) / ( d × x2 + e × x1 + f)
Tabellarische Definition Die Umsetzung wird in <sw-compu-method-table> tabellarisch definiert (vgl. Beispiel für eine tabellarische Umrechnungsformel). Pro Wertepaar (<sw-compu-method-value-pair>) wird der Steuergeräteinterne Wert (<cmt-int>) [image] und der physikalische Wert (<cmt-phys>) angegeben.

Die Art der Interpolation wird in [interpolation-style] spezifiziert.
textuelle Darstellung Diese Umsetzung (<sw-compu-method-text>) bildet einen steuergeräteinternen (<cmt-int>) Wert in einen Text (<cmt-text>) (z.B. einen Zustandsbezeichner) ab. Pro Wertepaar wird ein <sw-compu-method-text-pair> angelegt (vgl. Beispiel für eine textuelle Umsetzung).

Programmcode Unter <prog-code> kann die Umrechung in der Notation einer Programmiersprache spezifiziert werden. Programmiersprache ([prog-lang]), Programmiersprachendialekt ([lang-subset]) und verwendete Bibliotheken ([used-libs]) werden als Attribute angegeben.

Mathematische Darstellung Die Umsetzung wird als allgemeiner math. Ausdruck (<sw-compu-generic-math>) spzeifizert. Der Inhalt ist noch offen, d.h. bilateral zu vereinbaren.

Abbildung 15: Umrechnungsformeln
Beispiel für Polynomdefinition
   <sw-compu-method>
      <long-name>Dezimalzahl in Hexzahl</long-name>
      <short-name>DEZ</short-name>
      <sw-unit-ref>dezhex</sw-unit-ref>
      <sw-asap-6-prm-method>0 1 0 0 0 1</sw-asap-6-prm-method>
   </sw-compu-method>
Beispiel für eine tabellarische Umrechnungsformel
   <sw-compu-method>
      <long-name></long-name>
      <short-name>LAMPTAB</short-name>
      <sw-unit-ref>digital</sw-unit-ref>
      <sw-compu-method-table>
         <sw-compu-method-value-pair>
            <cmt-int>0</cmt-int>
            <cmt-phys>0</cmt-phys>
         </cmt-compu-method-value-pair>
         <sw-compu-method-value-pair>
         <cmt-int>16</cmt-int>
            <cmt-phys>16</cmt-phys>
         </cmt-compu-method-value-pair>
      </sw-compu-method-table>
   </sw-compu-method>
Beispiel für eine textuelle Umsetzung
   <sw-compu-method>
   <long-name></long-name>
      <short-name>vkSpezial</short-name>
      <sw-unit-ref></sw-unit-ref>
      <sw-compu-method-text>
         <sw-compu-method-text-pair>
            <cmt-int>0</cmt-int>
            <cmt-text>Heck</cmt-text>
         </cmt-compu-method-text-pair>
         <sw-compu-method-text-pair>
            <cmt-int>16</cmt-int>
            <cmt-text>16</cmt-text>
         </cmt-compu-method-text-pair>
      </sw-compu-method-text>
   </sw-compu-method>

In einer Pilotanwendung wurde Angabe im "C-Stil" verwendet.
"int" steht nicht für "integer" sondern für "intern". Es könnten auch Fließkommazahlen sein.


2.2.3.6. Adressierverfahren

Die Kenngrößen und Variablen können im Steuergerät auf verschiedene Weise angesprochen werden. Die möglichen Adressierverfahren können unter <sw-adressing-methods> mit einem formalen Namen und einer informellen Beschreibung (<sw-adressing-method-desc>) aufgeführt werden. Damit können formale Verweise (<sw-adressing-method-ref>) aufgebaut werden. Weitere Einzelheiten siehe 3. Beschreibung der Elemente und der Attribute


2.2.3.7. Speicherlayouts

Die Kenngrößen und Variablen können im Steuergerät auf verschiedene Weise abgelegt werden. Die möglichen Ablageschemata können unter <sw-param-record-layout> mit einem formalen Namen und einer informellen Beschreibung (<sw-param-record-layout-desc>) aufgeführt werden. Damit können formale Verweise (<sw-param-record-layout-ref>) aufgebaut werden. Weitere Einzelheiten siehe 3. Beschreibung der Elemente und der Attribute.


2.2.3.8. Code-Syntaxen

Die Kenngrößen und Variablen können von Codegeneratoren in die Quelltexte für den Compiler eingebaut werden. Zur Steuerung dieser Codegeneratoren werden Code-Syntaxen verwendet. Die möglichen Adressierverfahren können unter <sw-code-syntaxes> mit einem formalen Namen und einer informellen Beschreibung (<sw-code-syntax-desc>) aufgeführt werden. Damit können formale Verweise (<sw-adressing-method-ref>) aufgebaut werden. Weitere Einzelheiten siehe 3. Beschreibung der Elemente und der Attribute


2.2.3.9. Abgleich mit ASAP

Der Umfang des Datenlexikons wurde wesentlich durch einen Abgleich mit den Inhalten von ASAP2 bestimmt. Dies betrifft vor allem:
  • <sw-variable>
  • <sw-param>
  • und die Einführung von <sw-compu-method>.
Folgende Tabelle zeigt die bei ASAP verwendeten Begriffe und die MSR Entsprechungen.
Gegenüberstellung ASAP-/MSR-Begriffe
ASAP | MSR
characteristics | Parameter/Kenngrößen (<sw-param>)
measurement | Variable (<sw-variable>)
compu-method | Umrechnungsformel (<sw-compu-method>)
Die Elementnamen werden angelehnt an die in MSR verwendeten Begriffe gewählt, um Überschneidungen mit bereits exisiterenden MSR-Elementnamen (Characteristic, Measurement) zu vermeiden. Parameter/Kenngrößen (<sw-param>), Variable (<sw-variable>). Für die Umrechnungsformel wird <sw-compu-method> verwendet.


2.2.4. Funktionen

Eine Funktion ist eine bestimmte Anforderung oder Eigenschaft des Gesamtsystems, die durch Hardware und/oder Software realisiert werden kann. Eine Funktion ist aber auch die Lösung einer Steuerungs-, Regelungs- oder Anzeige-Aufgabe. Man kann solche Funktionen auch als Anwendungsfunktionen bezeichnen (vgl. Anwendungsfunktionen).
Abbildung 16: Anwendungsfunktionen
Die in Software realisierten Funktionen werden in <sw-function-spec> beschrieben. Diese Funktionen werden in Klassen eingeteilt (<sw-function-class>). Die Funktionen können variantenspezifisch beschrieben werden. Für jede Funktion muß mindestens eine Funktionsvariante existieren (<sw-function-variant>).
Abbildung 17: Funktionsspezifikation


2.2.4.1. Funktionsvarianten

Die Funktionsvariante (<sw-function-variant>) wird in folgenden Einzelheiten beschrieben (vgl. Funktionsvariante):
Variantenkennung Unter <variant-def-refs> werden Verweise auf die Varianten angegeben, für die die vorliegende Beschreibung gilt (vgl. 2.1.2. Variantenbehandlung).

Funktionsdefinition Unter <sw-function-def> wird eine semiformale Definition der Funktion gegeben. Dieses Element wird i.d.R. aus Systementwurfswerkzeugen automatisch beschickt. Die obligatorischen Bilder sind zur Aufnahme von Diagrammen aus dem Systementwurfswerkzeug vorgesehen(vgl. 2.2.4.1.1. Funktionsdefinition).

Funktionsbeschreibung Unter <sw-function-desc> wird eine informelle Beschreibung der Funktion abgelegt (vgl. 2.2.4.1.2. Funktionsbeschreibung). Diese wird in aller Regel manuell erstellt.

Anforderungsverweis Unter <sw-fulfils> wird (dokumentübergreifend) auf die Systemfunktion in der MSRSYS.DTD verwiesen (vgl. 2.2.4.1.3. Verweis auf Komponentenverhalten).

Funktionsvariablen Unter <sw-function-variables> werden die in der Funktion verwendeten Variablen aufgeführt. Dabei wird auch die Art der Verwendung spezifiziert (vgl. 2.2.4.1.4. Funktionsvariablen).

Funktionskenngrößen Unter <sw-param-refs> werden die in der Funktion verwendeten Kenngrößen aufgeführt. Dabei wird über das Attribut [owns] auch die Art der Verwendung spezifiziert (vgl. 2.2.4.1.5. Funktionskenngrößen).

Lokales Datenlexikon Unter <sw-data-dictionary-spec> wird ein funktionslokales Datenlexikon angelegt (vgl. 2.2.3. Datenlexikon).

Lokale Kenngrößeninhalte Unter <sw-param-contens-spec> werden funktionslokale Kenngrößeninhalte abgelegt (vgl. 2.2.4.1.6. Funktionsbezogene (lokale) Kenngrößeninhalte).

Testspezifikationen Unter <sw-test-spec> können Testspezifikationen abgelegt werden (vgl. 2.2.4.1.7. Testspezifikation).

Applikationshinweise Unter <sw-application-notes> können Hinweise zur Kalibrierung (Applikation) der vorliegenden Funktion gegeben werden (vgl. 2.2.4.1.8. Applikationshinweise).

Kundendiensthinweise Unter <sw-maintenance-notes> können Kundendiensthinweise mit Bezug auf die vorliegende Funktion gegeben werden (vgl. 2.2.4.1.9. Kundendiensthinweise).

CARB-Dokumentation Unter <sw-carb-doc> kann die Dokumentation für CARB (california air resource board) beschrieben werden (vgl. 2.2.4.1.10. CARB-Dokumentation).

Funktionszerlegung Unter <sw-decomposition> kann die Zerlegung der aktuellen Funktion in Teilfunktionen angegeben werden. Daraus kann eine Übersicht über die gesamte Funktionshierarchie generiert werden (vgl. 2.2.4.1.11. Funktionszerlegung).

Notizobjekte Unter <annotations> können Informationen im Prozeß weitergereicht werden (vgl. 3. Beschreibung der Elemente und der Attribute).

zusätzliche Informationen Unter <add-info> können Informationen und Beschreibungen abgelegt werden, für die es keine expliziten Strukturen in MSRSW.DTD gibt (vgl. E.4. Zusätzliche Informationen Ergänzende Angaben Additional Info ).

Abbildung 18: Funktionsvariante


2.2.4.1.1. Funktionsdefinition

Für jede Software-Funktion kann in <sw-function-def> eine Definition mit formalen Anteilen (z.B. ein regelungstechnisches Blockschaltbild) dokumentiert werden. Dieses Element wird in der Regel durch die Ausgabe eines CASE-Tools bzw. Systementwurfswerkzeugs beschickt werden.
Dazu müssen die Report-Fähigkeiten der CASE-Tools genutzt werden. Die Ausgabe kann sowohl Grafiken als auch freie Texte umfassen.
Im Interesse reproduzierbarer Prozesse sollte dieses Element entweder voll manuell gepflegt werden, oder aber keine manuellen Eingaben enthalten.


2.2.4.1.2. Funktionsbeschreibung

In <sw-function-desc> kann eine detaillierte Beschreibung der Funktion erfolgen. Diese wird i.d.R. manuell erstellt. Formale, automatisch erstellte Anteile sollten in <sw-function-def> abgelegt werden. Unter <prms> können auch formale Parameter eingegeben werden, welche dann auch maschinell prüfbar sind. Dies betrifft Randbedingungen, Eigenschaften einer Funktion, welche nicht in <sw-param> spezifiziert werden, weil sie fest im Programm codiert sind, oder sich gar aus der Implementierungstechnik ergeben.


2.2.4.1.3. Verweis auf Komponentenverhalten

In dem Element <sw-fulfils> können Verhaltens-Funktionen des Steuergerätes referenziert werden, die durch die Software-Funktion realisiert werden. Dadurch ist es möglich, Funktionen zunächst implementierungsunabhängig (in einer MSRSYS.DTD - Instanz) zu beschreiben, und im Rahmen der Partitionierung die Korrespondenz zwichen Verhalten und Software-Funktion herzustellen.


2.2.4.1.4. Funktionsvariablen

In <sw-function-variables> werden die Variablen aufgeführt die von der Software-Funktion gelesen oder manipuliert werden. Die eigentliche Variablenbeschreibung befindet sich dabei im Datadictionary (<sw-variables>); dorthin wird referenziert. Bei den Variablen wird zwischen der Definition von Variablen und dem Zugriff auf Variable unterschieden.
Wenn eine Funktion eine Variable definiert, d.h. eine Variable bzw. den Wert zur Verfügung stellt, so so ist sie unter <sw-function-export-variables> aufzuführen.
In <sw-function-import-variables>) werden Variablen aufgeführt, die importiert bzw. von anderen Funktionen definiert werden. <sw-function-local-variables> legt fest, daß es sich nicht um eine Übergabevariable, sondern um eine lokale Variable handelt.
In <sw-function-modelonly-variables> werden Variablen aufgeführt, die nur im Modell (z.B. zur Vereinfachung der Dokumentation) existieren. Diese erscheinen nicht in der Implementierung im Steuergerät.
Hinsichtlich des Zugriffs auf Variable wird zwischen lesend (<sw-variable-read>), schreibend (<sw-variables-write>) und lesend und schreibend (<sw-variables-readwrite>) unterschieden.
Im nachfolgenden Beispiel wird die Verwendung von Variablen und Kenngrößen in Funktionen gezeigt.
<sw-function-spec>
   <sw-functions>
      <sw-function>
         <long-name></long-name>
         <short-name>test</short-name>
         <sw-function-class></sw-function-class>
         <sw-function-variants>
            <sw-function-variant>
               <sw-function-variables>
               <sw-function-export-variables>
                  <sw-function-variables-readwrite>
                        <sw-variable-ref>TMOT</sw-variable-ref>
                     </sw-function-variables-readwrite>
                     </sw-function-export-variables>
                  <sw-function-import-variables>
                     <sw-function-variables-read>
                        <sw-variable-ref>TL</sw-variable-ref>
                     </sw-function-variables-read>
                  </sw-function-import-variables>
                  <sw-function-local-variables>
                     <sw-function-variables-readwrite>
                        <sw-variable-ref>NDEL</sw-variable-ref>
                     </sw-function-variables-readwrite>
                  </sw-function-local-variables>
                  <sw-function-modelonly-variables>
                     <sw-variable-ref>Tloc</sw-variable-ref>
                  </sw-function-modelonly-variables>
            <sw-param-refs>
                  <sw-param-ref >FAGRM</sw-param-ref>
                  <sw-param-ref >KFAGR</sw-param-ref>
                  <sw-param-ref owns="noown">kgr_a</sw-param-ref>
                  <sw-param-ref owns="noown">KWBLOCK1</sw-param-ref>
                  <sw-param-ref owns="noown">N40_KR</sw-param-ref>
               </sw-param-refs>

            </sw-function-variant>
         </sw-function-variants>
      </sw-function>
   </sw-functions>


2.2.4.1.5. Funktionskenngrößen

Die zugehörigen Kenngrößen der Software-Funktion werden in <sw-param-refs> aufgeführt. Die Kenngrößen werden durch Referenzierung (<sw-param-ref>) den Funktionen zugeordnet. Durch das Attribut [noown] kann bestimmt werden, ob eine Funktion eine Kenngröße definiert (die Kenngröße also zu der Funktion gehört oder ob die Funktion eine Kenngröße importiert (owns="noown") [image] .

Fehlt dieses Attribut, dann definiert die Funktion diese Kenngröße. In einer späteren Version der DTD wird auch der Wert "own" erlaubt.


2.2.4.1.6. Funktionsbezogene (lokale) Kenngrößeninhalte

In <sw-param-contents> können innerhalb von <sw-function-variant> Kenngrößeninhalte spezifiziert werden. Sie werden dann als lokale Kenngrößeninhalte bezeichnet (vgl. 2.1.4. Ablage von Kenngrößeninhalten).
Einzelheiten zur Kenngrößeninhalte sind unter 2.2.5. Spezifikation von Kenngrößeninhalten beschrieben.


2.2.4.1.7. Testspezifikation

Unter <sw-test-spec> können für jede Funktionsvariante die Testverfahren spezifiziert werden.


2.2.4.1.8. Applikationshinweise

Unter <sw-application-notes> können Hinweise auf Besonderheiten zur Applikation (Kalibrierung) der Funktion beschrieben werden.


2.2.4.1.9. Kundendiensthinweise

Unter <sw-maintenance-notes> können Informationen abgelegt werden, welche später z.B. in die Kundendienstunterlagen übernommen werden.


2.2.4.1.10. CARB-Dokumentation

Unter <sw-carb-doc> wird die für CARB benötigte Dokumentation eingetragen.


2.2.4.1.11. Funktionszerlegung

Die Software-Funktionen werden flach beschrieben. Die Zerlegung (<sw-decomposition>) der Software-Funktion in Details kann durch Referenzierung auf andere Software-Funktionen durchgeführt werden. Damit wird eine Mehrfachverwendung von Subfunktionen unterstützt [image] .

dieses Verfahren entspricht der Komponentenstruktur in MSRSYS.DTD


2.2.5. Spezifikation von Kenngrößeninhalten

Kenngrößeninhalte können unter <msrsw> global (vgl. 2.1.4. Ablage von Kenngrößeninhalten) beschrieben werden (<sw-param-contents>). Durch <sw-function-ref> kann ein Kenngrößeninhalt einer Funktion zugeordnet werden. Eine Klassifizierung des Kenngrößeninhalts ist durch <sw-param-contents-class> möglich, z.B.: "Testdaten", "Rohapplikationsdaten". Ein Kenngrößeninhalt kann mehrfach angegeben werden. Das ist sinnvoll, wenn für eine Kenngröße z.B mehrere Testdaten angegeben werden sollen.
Der Inhalt selbst wird durch <sw-param-ref> einer Kenngröße zugeordnet. Kenngrößenstruktur (in <sw-param>) und Kenngrößeninhalt (in <sw-param-contents>) müssen strukturell übereinstimmen (d.h. z.B. die gleiche <sw-param-class> tragen).
Die Kenngrößeninhalte gliedern sich in bis zu drei Achsen (<sw-param-content-x>, <sw-param-content-y>, <sw-param-content-v> bzw. <sw-param-content-text>) um die Strukturen in 2.2.3.4. Kenngrößenstrukturen mit Daten befüllen zu können. Bei Kennfeldern werden alle Werte zeilenweise in <sw-param-content-v> abgelegt, wobei der Index für die X-Achse schneller läuft.
Pro Achse können die Daten in verschiedenen Formaten spezifizert werden:
<sw-param-values-phys> | Physikalische Werte, angegeben ggf. als Fließkommzahl
<sw-param-values-coded> | Steuergeräte-interne Werte, angegeben als Integer bzw. als Fließkommazahl
<sw-param-values-coded-hex> | Steuergeräte-interne Werte, angegeben als Hexadezimalzahl im "C"-Format (z.B. "0x7f2a")
<sw-param-values-adr> | Adresse des Wertes im Steuergerät angegeben als Hexadezimalzahl im "C"-Format (z.B. "0x7f2a"). Diese Adresse dient vorwiegend zur Dokumentation (z.B. Umprogrammierungsanleitung).
<sw-param-values-generic> | Hier können weitere Formate abgelegt werden. Die Formate selbst werden durch das Attribut [type] festgelegt.
Die Kenngrößeninhalte sind so konzipiert, daß sie auch ohne Datenlexikon verwendet werden können, um z.B. eine physikalische Archivierung vorzunehmen. Daher sind die Elemente <sw-param-ref>, <sw-param-class>, <sw-unit> optional nocheinmal vorhanden. Die dabei mögliche Redundanz wird in Kauf genommen, da diese Elemente ohnehin maschinell generiert werden. Der Verweis <sw-param-ref> kann nicht mehr über ID/IDREF geführt werden, da in der Instanz nur Kenngrößeninhalte und nicht die Parameterdefinition enthalten sein können. Es bleibt also nur die natürliche Adressierung [image] .
Abbildung 19: Parameterinhalte (Übersicht)
Abbildung 20: Parameterinhalte (Details)
Folgende Beispiele zeigen den Kenngrößeninhalt eines Kennwertes und einer Kennlinie:
<sw-param-content>
   <sw-param-ref>KUP_FEN</sw-param-ref>
   <sw-param-class>value</sw-param-class>
   <sw-param-content-v>
      <sw-unit-ref>grad C</sw-unit-ref>
      <sw-param-values-coded>
         <v>1</v>
      </sw-param-values-coded>
   </sw-param-content-v>
</sw-param-content>

<sw-param-content>
   <sw-param-ref>FAGRM</sw-param-ref>
   <sw-param-class>curve_individual</sw-param-class>
   <sw-param-content-x>
      <sw-unit-ref>grad C</sw-unit-ref>
      <sw-param-values-coded>
         <v>1</v><v>2</v><v>3</v><v>4</v><v>5</v><v>6</v>
      </sw-param-values-coded>
   </sw-param-content-x>
   <sw-param-content-v>
      <sw-param-values-coded>
         <v>1</v><v>2</v><v>3</v><v>4</v><v>5</v><v>6</v>
      </sw-param-values-coded>
   </sw-param-content-v>
</sw-param-content>

Hierfür ist muß die DTD geeignet konfiguriert werden.


2.2.6. Glossar für das Dokument

Es kann ein Glossar für das entsprechende Dokument angelegt werden (<sw-glossary>).


2.2.7. Zusätzliche Spezifikationen

<add-spec> erlaubt die Erfassung zusätzlicher Spezifikationen, die in der DTD nicht explizit vorgesehen sind (beipielsweise ein Abkürzungsverzeichnis).


2.3. Referenzen

Zwischen den oben aufgeführten Elementen werden zusätzliche Beziehungen eingeführt, die als Referenzen implementiert werden. Die folgende Tabelle enthält eine Auflistung aller in diesem Kontext zu betrachtenden Referenzarten, inklusive der bereits existierenden.
Referenzarten
Nr. | Bezeichnung | Quellelement | Zielelement | Bedeutung
1 | <system-ref> | <requirements>, <product-spec> | <part-type> | Legt für jede der beiden Sichten den obersten Part-Type (genau einen) als System fest.
2 | <part-type-ref> | <part> | <part-type> | Ordnet einem Part den eigenen Part-Type (genau einen) zu.
3 | <sw-function-ref> | <software> | <sw-function> | Ordnet der Software eines Part-Type Software-Funktionen (keine, eine oder mehrere) zu, die innerhalb der Software eines anderen Part-Types beschrieben sind, z.B. mehrfach verwendete Funktionen wie Betriebssystem- oder Netzwerkmanagementfunktionen.
4 | <sw-function-ref> | <sw-function> | <sw-function> | Ordnet einer Software-Funktion Software-Funktionen (keine, eine oder mehrere) innerhalb derselben Softwarebeschreibung zu, welche die Dekomposition der erstgenannten darstellen.
5 | <fulfills-ref> | part, sw-function | function | Ordnet einem Part oder einer Software-Funktion diejenigen (Verhaltens-)Funktionen (keine, eine oder mehrere) zu, die es bzw. sie realisiert.
6 | <function-view-ref> | function | function | Ordnet einer spezifizierten (Verhaltens-) Funktion in der Sicht Zusage diejenige geforderte (Verhaltens-)Funktion in der Sicht Vorgabe zu, welche durch erstgenannte realisiert wird.
Die folgende Abbildung stellt die Referenzarten exemplarisch dar (mit Ausnahme der Nr. 6).
Abbildung 21: Erweiterte Struktur mit Referenzen

Die Umsetzung dieser Referenz wird zurückgestellt bis zur Konzeption eines Requirements Tracing.


3. Beschreibung der Elemente und der Attribute

Strukturelle Grundlagen
3. Beschreibung der Elemente und der Attribute

Inhalt dieses Kapitels:
  • 3.1. Klassen-Elemente
  • 3.2. Beschreibung der Elemente
  • 3.3. Beschreibung der Attribute


3.1. Klassen-Elemente

In der Software-DTD werden folgende Klassen-Elemente verwendet:
  • sw-addressing-method-class
  • sw-data-dictionary-class
  • sw-function-class
  • sw-param-class
  • sw-param-contents-class
  • sw-param-record-layout-class
  • sw-code-syntax-class
Alle Klassen-Elemente haben als Endung des Elementnamens "-class". Die Klassen sind nicht normiert bzw. nicht in der DTD definiert. Es wird jedoch empfohlen, bestimmte Klassenbezeichnungen z.B. entsprechend ASAP zu verwenden. Hierfür wurden Vorschläge gemacht. Siehe <sw-param-class>, z.B. "value". Die Klassenbezeichnungen sind zwischen den Projektpartnern zu vereinbaren.


3.2. Beschreibung der Elemente

Nachfolgend werden die Elemente der Software-DTD beschrieben. Die Beschreibung eines Elementes besteht aus: Beschreibung des Elements, Angabe der Attribute, Angabe des Kontextes und einem Beispiel.
Es gibt Elemente, die allgemeingültig sind und einer Anwendungsarchitektur zuzuordnen sind, sie haben im Elementnamen nicht den Vorspann "sw-". Diese Elemente werden in allen DTD's, die einer bestimmten Anwendungsarchitektur entsprechen, verwendet. Deshalb werden sie hier nicht alle nochmals aufgeführt. Sie werden in dem Dokument "Concepts of the DTD" beschrieben.
Es gibt ein Attribut s (Signatur), das in allen Elementen vorkommt. Deshalb wird dieses Attribut nicht mehr aufgeführt.
Bei den Beispielen werden zur Übersichtlichkeit teilweise auch fixe Attribute aufgeführt (z.B. [f-namespace]). Bei einer Instanz aufgrund der Software-DTD tauchen die fixen Attribute nicht mehr auf, d.h. die Instanz ist nur zusammen mit der DTD vollständig.
<abs>
Beschreibung Absolutwert bei Parametercharakteristik. Siehe Parametermodell (<sw-prm>).

Attribute
[s] Signatur

Enthalten in <prm-char>

Beispiel
<prm>
   <long-name>Langbezeichnung</long-name>
   <short-name>Kurzbezeichnung</short-name>
   <prm-char>
      <abs>10</abs>
      <tol>5<tol>
      <unit>oC</unit>
   </prm-char>
</prm>
<prm>
   <long-name>Langbezeichnung</long-name>
   <short-name>Kurzbezeichnung</short-name>
   <prm-char>
      <min>0</min>
      <typ>5<typ>
      <max>0</max>
      <unit>oC</unit>
   </prm-char>
</prm>
<add-info>
Beschreibung Zusätzliche Hinweise. In einer Funktion könnte beispielsweisemit Hilfe dieses Elementes die verwendete Programmiersprache dokumentiert.

Attribute
-

Enthalten in <sw-function-variant>,< sw-param>, <sw-variable-implementation>

Beispiel
<sw-function-variant>
     ...
   <add-info>
      <prms>
         <prm>
            <long-name>program-language</long-name>
            <short-name>program-language</short-name>
            <prm-char><text>ASS</text>
            </prm-char>
         </prm>
      </prms>
   </add-info>
</sw-function-variant>
<add-spec>
Beschreibung

Attribute
-

Enthalten in <general-project-data>

Beispiel
<admin-data>
Beschreibung Innerhalb der Struktur dieses Elementes können Angaben zur separaten Verwaltung von Teilinstanzen gemacht werden. Deshalb existiert dieses Element an all den Stellen, die poteniell für Export und Import zur separaten Verwaltung vorgesehen sind auf.

Attribute
[f-child-type] Für Anwendungen, um unterschiedliche "child-types" zu ermöglichen(Typprüfung). Z.B. "language:selection", d.h. das Kindelement language ist vom Typ selection, kann also aus einer Auswahlliste ausgewählt werden.

[s] Signatur

Enthalten in Allen Elementen, die für eine Fragmentierung vorgesehen sind.

Beispiel
<admin-data>
   <language>de</language>
   <doc-revisions>
      <doc-revision>
         <company-revision-infos>
            <company-revision-info>
               <company-ref></company-ref>
               <revision-label>10.4</revision-label>
               <state></state>
            </company-revision-info>
         </company-revision-infos>
         <team-member-ref></team-member-ref>
         <date></date>
         <modifications>
            <modification type="part-related">
               <change></change>
               <reason></reason>
            </modification>
         </modifications>
      </doc-revision>
   </doc-revisions>
</admin-data>
<annotation>
Beschreibung Im Laufe eines Prozesses können verschiedene Informationen entstehen, (z.B. Bearbeitungsinformationen, Notizen usw.) die an die Variablen, Kenngrößen bzw. Funktion zu koppeln und im Prozeß weiterzureichen sind. Derartige Informationen werden in <annotation> abgelegt.

Attribute
-

Enthalten in <annotations>

Beispiel
<arraysize>
Beschreibung Bei Variablen kann es vorkommen, daß sie nicht als Einzelelement, sonder als array angelegt werden. Dann gibt dieser Wert die Größe des arrays an. Bei mehrdimensionalen arrays Trennung der Dimensionen durch Leerzeichen.

Es können ebenso Kenngrößen-Felder/-arrays angelegt werden.
Attribute
[S] Signatur

Enthalten in <sw-param>, <sw-variable-implementation>

Beispiel
<sw-param>
   <long-name></long-name>
   <short-name>kgr_a</short-name>
   <sw-param-class>curve_individual</sw-param-class>
   <desc></desc>
   <sw-param-array-x>
      <sw-param-axis-x>
         <sw-axis-individual>
            <sw-variable-ref>TMOT</sw-variable-ref>
            <max-count></max-count>
         </sw-axis-individual>
      </sw-param-axis-x>
      <sw-param-axis-values>
         <sw-compu-method-ref>DEZ</sw-compu-method-ref>
      </sw-param-axis-values>
   </sw-param-array-x>
   <arraysize>0x3</arraysize>
   <sw-addressing-method-ref>Vek</sw-addressing-method-ref>
   <sw-param-record-layout-ref>DAMOS_KL0</sw-param-record-layout-ref>
   <sw-code-syntax-ref>csyKLuw</sw-code-syntax-ref>
</sw-param>
<bit-base-name>
Beschreibung In<sw-bit-representation> in <sw-variable>. Name der Variablen, in der das Bit liegt.

Attribute
-

Enthalten in <sw-bit-representation>

Beispiel
<sw-bit-representation>
   <bit-base-name>variable-short-name</bit-base-name>
   <bit-base-type>w<bit-base-type>
   <bit-count>1</>
   <bit-pos>5</>
</sw-bit-pos>
<bit-base-type>
Beschreibung In<sw-bit-representation> in <sw-variable>. Typ (byte, word, long) der Variablen, in der das Bit liegt.

Attribute
-

Enthalten in <sw-bit-representation>

Beispiel
<sw-bit-representation>
   <bit-base-name>variable-short-name</bit-base-name>
   <bit-base-type>w<bit-base-type>
   <bit-count>1</>
   <bit-pos>5</>
</sw-bit-pos>
<bit-count>
Beschreibung In<sw-bit-representation> in <sw-variable>. Anzahl der zusammengehörigen Bits.

Attribute
-

Enthalten in <sw-bit-representation>

Beispiel
<sw-bit-representation>
   <bit-base-name>variable-short-name</bit-base-name>
   <bit-base-type>w<bit-base-type>
   <bit-count>1</>
   <bit-pos>5</>
</sw-bit-pos>
<bit-pos>
Beschreibung In<sw-bit-representation> in <sw-variable>. Postion des Bits in der Basis-Größe.

Attribute
-

Enthalten in <sw-bit-representation>

Beispiel
<sw-bit-representation>
   <bit-base-name>variable-short-name</bit-base-name>
   <bit-base-type>w<bit-base-type>
   <bit-count>1</>
   <bit-pos>5</>
</sw-bit-pos>
<change>
Beschreibung Element, in dem die Art einer Änderung beschrieben werden kann.

Attribute
-

Enthalten in <Modification>

Beispiel
<modification>
   <change>Änderung ...</change>
   <reason></reason>
</modification>
<chapter>
Beschreibung In einem Kapitel können informelle, nicht anwendungsstrukturierte Informationen beschrieben werden. Kapitel können hierarchisch aufgebaut sein. Ein Kapitel kann Paragraphen, Tabellen, Grafiken, Listen, usw. enthalten.

Attribute
-

Enthalten in

Beispiel
<chapter id="ch1" help-entry="chapter">
   <long-name>kapitel1</long-name>
   <short-name></short-name>
   <p></p>
   <figure id="fig1" help-entry="übersichtsbild"><
      long-name>prinzipschaltbild</long-name>
      <short-name>psb</short-name>
      <graphic filename="bild.eps" notation="eps"></graphic>
   </figure>
   <chapter id="ch11">
      <long-name>kapitel 1.1</long-name>
      <short-name></short-name>
      <p></p>
      <p></p>
   </chapter>
</chapter>
<cmt-int>
Beschreibung Interner Wert bei einer Umrechnungsformel

Attribute
-

Enthalten in <sw-compu-method-text-pair>, <sw-compu-method-value-pair>

Beispiel
<sw-compu-method-text>
   <sw-compu-method-text-pair>
      <cmt-int>0</cmt-int>
      <cmt-text>Heck</cmt-text>
   </cmt-compu-method-text-pair>
</sw-compu-method-text>
<cmt-phys>
Beschreibung Physikalischer Wert bei einer Umrechnungsformel.

Attribute
[s] Signatur

Enthalten in <sw-compu-method-value-pair>

Beispiel
<sw-compu-method-table>
   <sw-compu-method-value-pair>
      <cmt-int>0</cmt-int>
      <cmt-phys>11</cmt-phys>
   </cmt-compu-method-value-pair>
</sw-compu-method-table
<cmt-text>
Beschreibung Textueller Wert bei einer Umrechnungsformel.

Attribute
-

Enthalten in <sw-compu-method-text-pair>

Beispiel
<sw-compu-method-text>
   <sw-compu-method-text-pair>
      <cmt-int>0</cmt-int>
      <cmt-text>Heck</cmt-text>
   </cmt-compu-method-text-pair>
</sw-compu-method-text>
<code>
Beschreibung

Attribute
-

Enthalten in <variant-char>, <variant-char-value>,<variant-def>

Beispiel
<coded>
Beschreibung Codierte/interne Werte bei limits.

Attribute
-

Enthalten in <sw-limits>

Beispiel
<sw-limits>
   <coded>
      <coded-min>0</coded-min>
      <coded-max>255</coded-max>
   </coded>
   <phys>
      <phys-min>0</phys-min>
      <phys-max>90</phys-max></phys>
</sw-limits>
<coded-max>
Beschreibung Maximaler codierter Grenzwert

Attribute
-

Enthalten in <coded>

Beispiel
<coded-max>255</coded-max>
<coded-min>
Beschreibung Minimaler codierter Grenzwert.

Attribute
-

Enthalten in <coded>

Beispiel
<coded-min>0</coded-min>
<companies>
Beschreibung Firmenspezifische Angaben, bestehend aus 1 .. n Firmen.

Attribute
-

Enthalten in <project>

Beispiel
<companies>
   <company role="supplier" id="rb"></company>
   <company role="manufacturer" id="db"></company>
</companies>
<company>
Beschreibung Firmenspezifische Angaben für eine am Projekt beteiligte Firma.

Attribute
[f-child-type] Für Anwendungen, um unterschiedliche "child-types" zu ermöglichen.

[f-id-class]

[f-name-space]

[id]

[role] Rolle, der am Projekt beteiligten Firma. "Manufacturer", "supplier".

Enthalten in <companies>

Beispiel
<company role="supplier" id="rb">
   <long-name>Robert Bosch GmbH</long-name>
   <short-name>rb</short-name>
   <team-members>
      <team-member id="ge"></team-member>
   </team-members><
   general-project-data></general-project-data>
</company>
<company-doc-info>
Beschreibung

Attribute
-

Enthalten in <company-doc-infos>

Beispiel
<company-doc-info>
   <company-ref company="rb"></company-ref>
   <doc-label>Programmstand</doc-label>
   <private-codes>1.1</private-codes>
   <entity-name>P11.sgm</entity-name>
</company-doc-info>
<company-doc-infos>
Beschreibung Firmenspezifische Angaben bei den administrativen Daten

Attribute
-

Enthalten in <admin-data>

Beispiel
<comany-ref>
Beschreibung Verweis auf eine Firma.

Attribute
-

Enthalten in <company-doc-info>, <company-revision-info>

Beispiel
<company-revision-info>
   <company-ref company="rb">rb</company-ref>
    ...
</company-revision-info>
<company-revision-info>
Beschreibung Firmenspezifische Angaben zu einer bestimmten Revision/Variante.

Attribute
[f-child-type]

Enthalten in <company-revision-infos>

Beispiel
<company-revision-info>
   <company-ref company="rb">rb</company-ref>
   <revision-label>15.4</revision-label>
   <state>freigegeben</state>
</company-revision-info>
<company-revision-infos>
Beschreibung Revsions- bzw. Variantenangaben zu einer Instanz oder Fragment.

Attribute
[s] Signatur

Enthalten in <doc-revision>

Beispiel
<cond>
Beschreibung Bedingung bei Parametern.

Attribute
-

Enthalten in <prm-char>

Beispiel
<prm>
   <long-name>Langbezeichnung</long-name>
   <short-name>Kurzbezeichnung</short-name>
   <prm-char>
      <cond><p>gültig wenn x <  20</p></cond>
      <abs>10</abs>
      <tol>5<tol>
      <unit>oC</unit>
   </prm-char>
</prm>
<count>
Beschreibung Anzahl der Elemente bei einem Kenngrößenblock.

Attribute
-

Enthalten in <sw-param-value-block>

Beispiel
<sw-param-value-block>
   <sw-param-axis-values>
      <sw-compu-method-ref sw-compu-method="dez">
      </sw-compu-method-ref>
   </sw-param-axis-values>
   <count>4</count>
</sw-param-value-block>
<date>
Beschreibung Datumsangabe, mehrsprachig möglich.

Attribute
[s] Signatur

Enthalten in <doc-revision>, <schedule>

Beispiel
<date-1>
Beschreibung Datumsangabe, nicht mehrsprachig möglich.

Attribute
[s] Signatur

Enthalten in <std>, <xdoc>

Beispiel
<demarcation-other-project>
Beschreibung Abgrenzung zu anderen Projekten

Attribute
-

Enthalten in <general-project-data>

Beispiel
<department>
Beschreibung Abteilung

Attribute
-

Enthalten in <team-member>

Beispiel
<desc>
Beschreibung Beschreibungselement

Attribute
-

Enthalten in <figure>, <overall-project>, <prm>, <project>, <sw-data-dictionary>, <sw-param>, <sw-param-content>, <sw-param-contents>, <sw-physic-type-contents>, <sw-variable>, <tbd>

Beispiel
<sw-variable calibration="no-calibration" f-id-class="sw-variable" f-namespace="sw-variable">
   <long-name>Motortemperatur</long-name>
   <short-name>tmot</short-name>
   <desc>In dieser Variablen wird die Motortemperatur gespeichert</desc>
   ...
</sw-variable>
<doc-label>
Beschreibung

Attribute
-

Enthalten in <company-doc-info>

Beispiel
<doc-revision>
Beschreibung

Attribute
[f-child-type]

Enthalten in <doc-revisions>

Beispiel
<doc-revisions>
Beschreibung

Attribute
-

Enthalten in <admin-data>

Beispiel
<entity-name>
Beschreibung

Attribute
-

Enthalten in <company-doc-info>

Beispiel
<figure>
Beschreibung Durch dieses Element können Grafiken eingebunden werden.

Attribute
-

Enthalten in

Beispiel
<file>
Beschreibung Angabe eines Filenamens, um auf ein externes File, einen Standard zu verweisen.

Attribute
[filename] Name des Files.

[notation] Typ des Files, z.B. "wmf", "cgm".

[tool] Werkzeug, mit dem das File angezeigt oder bearbeitet werden kann.

[tool-version] Version des Werkzeugs, mit dem das File erzeugt wurde.

Enthalten in <std>, <xdoc>, <xfile>

Beispiel
<file filename="agr.eps" notation="eps" tool="ascet" tool-version="sd"></file>
<function-ref>
Beschreibung Verweis auf Funktion bzw. Requirements-Funktion.

Attribute
-

Enthalten in <sw-fulfils>

Beispiel
<general-project-data>
Beschreibung Allgemeine Projektdaten.

Attribute
-

Enthalten in <company>

Beispiel
<generic-math>
Beschreibung Mathematische Formel.

Attribute
-

Enthalten in <formula>

Beispiel
<graphic>
Beschreibung Angabe eines Grafikfiles.

Attribute
[category]

[filename]

[fit]

[height]

[notation]

[scale]

[width]

Enthalten in <ml-graphic>

Beispiel
<graphic filename="ggub.eps" notation="eps"></graphic>
<ie>
Beschreibung

Attribute
[type]

Enthalten in <mixed-content-4>, <ml-data-1>, <ml-data2>, <ml-data-4>

Beispiel
<introduction>
Beschreibung Einführungsteil bzw. Einführungskapitel.

Attribute
-

Enthalten in <company-revision-info>, <general-project-data>, <info>, <msrsw>, <sample-spec>, <sw-data-dictionary-spec>, <sw-glossary>, <sw-param-contents-spec>, <variant-spec>

Beispiel
<label>
Beschreibung Ein label ist eine Bezeichnung für ein Objekt, das nicht referenziert werden muß und kann, also keinen< short-name> und keine [id] besitzt.

Ein <label> bei <sw-param-value-block> ist eine Langbezeichnung für die Kennwerte eines Kennwerteblocks.
Attribute
-

Enthalten in <annotation>, <labels>, <overall-project>, <prms>

Beispiel
<sw-param-value-block>
   <sw-param-axis-values>
      <sw-compu-method-ref sw-compu-method="dez">
         </sw-compu-method-ref>
         <labels>
            <label>Sensor hinten links</label>
            <label>Sensor hinten rechts</label>
            <label>Sensor vorne links</label>
            <label>Sensor vorne rechts</label>
         <l/abels>
   </sw-param-axis-values>
   <count>4</count>
</sw-param-value-block>
<labels>
Beschreibung Menge der labels bei Achswerten.

Attribute
-

Enthalten in <sw-param-axis-values>

Beispiel
<locs>
Beschreibung Dieses Element wird für dokumenten-/instanzübergreifende Referenzierung verwendet (HighTime-Referenzierungskonzept über namelocs)

Attribute
-

Enthalten in <msrsw>

Beispiel
<language>
Beschreibung Bezeichnet die Masterlanguage bei <admin-data>

Attribute
-

Enthalten in <admin-data>

Beispiel
<long-name>
Beschreibung Langbezeichnung , z.B. "Motortemperatur".

Attribute
-

Enthalten in

Beispiel
<sw-variable id="tmot">
   <long-name>Motortemperatur</long-name>
   <short-name>tmot</short-name>
   <desc></desc>
    ...
</sw-variable>
<max>
Beschreibung Maximalwert bei einer Parametercharakteristik.

Attribute
-

Enthalten in <prm-char>

Beispiel
<max-count>
Beschreibung Maximale Anzahl Stützstellen.

Attribute
-

Enthalten in <sw-axis-individual>, <sw-axis-shift-offset>

Beispiel
<min>
Beschreibung Minimalwert bei prm-char

Attribute
-

Enthalten in <prm-char>

Beispiel
<modification>
Beschreibung

Attribute
[type] content-related, doc-related

Enthalten in <modifications>

Beispiel
<modifications>
Beschreibung

Attribute
-

Enthalten in <doc-revision>

Beispiel
<msrsw>
Beschreibung Wurzelelement

Attribute
[f-namespace]

[f-pubid] Fixes Attribut: -//MSR//DTD MSR SOFTWARE DTD:V1.1.0:MSRSW.DTD//EN

[HyTime]

[pubid] -//MSR//DTD MSR SOFTWARE DTD:V1.1.0:MSRSW.DTD//EN

Enthalten in -

Beispiel
<na>
Beschreibung Falls gewisse Angaben nicht relevant sind, wird dieses Element anstelle von Teilstrukturen verwendet ("not applicable").

Attribute
-

Enthalten in <general-project-data>, <info>, <sample-spec>, <sw-data-dictionary-spec>, <sw-functions-spec>, <sw-glossary>, <sw-param-contents-spec>

Beispiel
<sw-param-contents-spec>
   <na></na>
</sw-param-contents-spec>
<ncoi-1>
Beschreibung Dies ist ein allgemeines Element, das informelle und nicht softwarespezifischen Strukturen enthält ("none coded information").

Attribute
-

Enthalten in <info>, <sample>, <sw-function-def>, <sw-glossary>

Beispiel
<offset>
Beschreibung Bei Festkennlinien, -feldern werden die Stützstellen üer einen Algorithmus festgelegt. Beispiel für einen Algorithmus: Stützstelle[i] = ( ... shift ) * x + offset

Attribute
-

Enthalten in <sw-axis-shift-offset>

Beispiel
<sw-axis-shift-offset>
   <sw-variable-ref>var1</sw-variable-ref>
   <max-count>4</max-count>
   <shift>2</shift>
   <offset>3</offset>
<sw-axis-shift-offset></sw-axis-shift-offset>
<p>
Beschreibung Paragraph. Ein Paragraph kann aus Text und aus den Elementen tt (technischer Benennung), xref (Querverweis), e (Textattribut, wie Fettdruck), ft (Fußnote), sup (hochgestellt), sub (tiefgestellt), ie (Indexeintrag), std (Standard), xdoc (externes Dokument), xfile (externes File) in beliebiger, jedoch nicht hierarchisierter Reihenfolge bestehen.

Attribute
[help-entry] Eintrag für ein Hilfesystem

Enthalten in add-info, annotation-text, chapter, cond, def, introduction, ncoi-1, p-level-elements, sw-addressing-method-desc, sw-application-notes, sw-carb-doc, sw-code-syntax-desc, sw-function-desc, sw-maintenance-notes, sw-param-record-layout-desc, sw-test-spec

Beispiel
<sw-function-desc>
   <p>Diese Funktion beschreibt die <ie>Abgasrückführung</ie>. Siehe <std> ... </std></p>
</sw-function-desc>
<private-code>
Beschreibung

Attribute
<type> -

Enthalten in <private-codes>

Beispiel
<private-codes>
   <private-code> TYPE="generated_by_ASCET-SD">$generated_by_ASCET-SD:2.2.0$ </private-code>
   <private-code> TYPE="Implementierung xy">Implementierung xy</private-code>
</private-codes>
<private-codes>
Beschreibung

Attribute
-

Enthalten in <company-doc-infos>

Beispiel
<company-doc-infos>
   <private-codes>
   <private-codes>
      <private-code> TYPE="generated_by_ASCET-SD">$generated_by_ASCET-SD:2.2.0$ </private-code>

   </private-codes>
</company-doc-infos>
<prm>
Beschreibung In MSR wurde ein Parametermodell implementiert. Hierbei gibt es 2 Möglichkeiten. Ein Parameter kann entweder durch Angabe von <abs>,<tol> oder durch Angabe von <min>, <typ> und<max> spezifiziert werden.

Attribute
[f-id-class]

[id]

Enthalten in prms

Beispiel
<prms>
Beschreibung Liste von Parametern.

Attribute
-

Enthalten in <add-info>, <chapter>, <ncoi-1>, <sw-addressing-method-desc>, <sw-application-notes>, <sw-carb-doc>, <sw-function-desc>, <sw-maintenance-notes>, <sw-param-record-layout-desc>, <sw-test-spec>, <topic-1>

Beispiel
<prm-char>
Beschreibung Beschreibung der Parametercharakteristik eines Parameters.

Attribute
-

Enthalten in <prm>

Beispiel
<sw-prm>
   <long-name>Langbezeichnung</long-name>
   <short-name>Kurzbezeichnung</short-name>
   <min>10</min>
   <typ>45</typ>
   <max>90</max>
   <unit>oC</unit>
</sw-prm>
<prog-code>
Beschreibung Beschreibung von Umrechnungsformeln in Programmiersprachennotation.

Attribute
[lang-subset]

[prog-lang] Programmiersprache

[used-libs] Benutzte Bibliotheken

Enthalten in sw-compu-method

Beispiel
<project>
Beschreibung Angaben zu einem Projekt.

Attribute
-

Enthalten in <project-data>

Beispiel
<project-data>
Beschreibung Projektdaten

Attribute
-

Enthalten in <msrsw>

Beispiel
<shift>
Beschreibung Bei Festkennlinien, -feldern werden die Stützstellen üer einen Algorithmus festgelegt. Beispiel für einen Algorithmus: Stützstelle[i] = ( ... shift ) * x + offset

Attribute
-

Enthalten in <sw-axis-shift-offset>

Beispiel
<sw-axis-shift-offset>
   <sw-variable-ref>var1</sw-variable-ref>
   <max-count>4</max-count>
   <shift>2</shift>
   <offset>3</offset>
<sw-axis-shift-offset></sw-axis-shift-offset>
<short-name>
Beschreibung Kurzbezeichnung, z.B. "TMOT". Der <short-name> besitzt identifizierenden Charakter insbesondere für Bezüge nach außen (z.B. ASAP, ASCET).

Attribute
-

Enthalten in chapter, company, def-item, figure, formula, msrsw, namloc, prm, sample, std, sw-addressing-method, sw-code-syntax, sw-compu-method, sw-function, sw-param, sw-param-record-layout, sw-physic-type, sw-unit, sw-variable, team-member, topic-1, topic-2, variant-char, variant-def, xdoc, xfile

Beispiel
<si-unit>
Beschreibung Bei Maßeinheiten gibt es SI-Maßeinheiten. STEP (ISO/DIS 10303-41. S96ff) stützt sich bzgl. SI-Einheiten auf auf sieben Basis-Einheiten ab ( length, mass, time, electric_current, thermodynamic_temperature, amount_of_substance, luminous_intensity). Diese Basiseinheiten wurden über Attribute realisiert.

Attribute
[amount-ofsubstance-expo]

[electric-current-expo]

[length-expo]

[luminous-intensity-expo]

[mass-expo]

[thermodynamic-temperature-expo]

[time-expo]

Enthalten in <sw-unit>

Beispiel
<sw-unit>
      <long-name>Meter pro Sekunde</long-name>
      <short-name>mps</short-name>
      <si-unit length-expo = "1" time-expo = "-1"></si-unit>
      <sw-unit-display></sw-unit-display>
   </sw-unit>
<reason>
Beschreibung

Attribute
-

Enthalten in <modification>

Beispiel
<revision-label>
Beschreibung Revision

Attribute
-

[]

Enthalten in <company-revison-info>

Beispiel
<company-revision-info>
    <company-ref></company-ref>
    <revision-label>10.4</revision-label>
    <state></state>
</company-revision-info>
<state>
Beschreibung

Attribute
-

Enthalten in <company-revision-info>

Beispiel
<std>
Beschreibung

Attribute
[f-child-type] date1:date

[f-id-class] std

[id]

Enthalten in

Beispiel
<std>
   <long-name-1>ISO/DIS 10303-41 Maßeinheiten</long-name-1>
   <short-name>ISO/DIS 10303-41</short-name>
   <subtitle>Si-Maßeinheiten</subtitle>
   <state-1></state-1>
   <date-1></date-1>
   <file>ISO10303-41.std</file>
   <position>S96ff</position>
</std>
<sw-addressing-method>
Beschreibung Beschreibt das Addressierschema. Es wird beschrieben, wie eine Kenngröße oder eine RAM-Größe vom Steuergerät adressiert wird. Beispiele für unterschiedliche Adressierungsarten sind die direkte Adressierung und die indirekte Adressierung über Vektor. Über das Adressierschema kann aber auch festgelegt werden, in welchem RAM-Bereich eine RAM-Größe liegt (z.B. im internen oder externen RAM). Adressierschemata können von Kenngrößen und RAM-Größen benutzt werden.

Dieses Element ist eine Namensreferenz auf eine Zugriffsmethode, welche in nachfolgenden Systemen (z.B. Verstellystemen) nachgebildet werden muß. Die Verbindung zwischen MSR-Instanz und nachfolgenden Systemen erfolgt über diesen Namen.
Adressierschemas sind nicht standardisiert bzw. in der DTD vordefiniert. Sie sind auch nicht ausmodelliert und werden in <sw-addressing-method-desc> lediglich textuell beschrieben.
Attribute
[f-id-class]

[id]

Enthalten in <sw-addressing-methods>

Beispiel
<sw-addressing-method-class>
Beschreibung Gibt die Klasse des Adressierschemas an. Kenngrößen bzw. Variable können nur Adressierschemas einer bestimmten Klasse verwenden. Dies kann jedoch nicht mit SGML-Mitteln sichergestellt werden, es muß die Anwendung tun.

Adressierschema-Klassen sind nicht standardisiert bzw. in der DTD vordefiniert.
Attribute
-

Enthalten in <sw-addressing-method>

Beispiel
<sw-addressing-method-desc>
Beschreibung Textuelle Beschreibung des Adressierschemas.

Attribute
-

Enthalten in <sw-addressing-method>

Beispiel
<sw-addressing-method-ref>
Beschreibung Verweis auf Adressierschema, z.B. durch Angabe des short-names.

Attribute
[HyNames]

[HYTIME]

[sw-addressing-method] idref

Enthalten in <sw-param>, <sw-variable-implementation>

Beispiel
<sw-addressing-method-ref>defaultAdrS</sw-addressing-method-ref>
<sw-addressing-methods>
Beschreibung In <sw-data-dictionary> werden alle Adressierschemas definiert.

Attribute
-

Enthalten in <sw-data-dictionary>

Beispiel
<sw-application-notes>
Beschreibung Applikationshinweise

Attribute
-

Enthalten in <sw-function-variant>

Beispiel
<sw-array-index>
Beschreibung Verweis auf die entsprechende Teilstruktur bei Parameterstrukturen.

Attribute
-

Enthalten in <sw-param-content>

Beispiel
<sw-asap-6-prm-method>
Beschreibung 6-Parameterformel entsprechend ASAP (Polynomdarstellung. Angabe der Elemente der Formel durch white spaces getrennt. Formel: int = (a × x2 + b × x1 + c ) / ( d × x2 + e × x1 + f)

Attribute
-

Enthalten in <sw-compu-method>

Beispiel
<sw-asap-6-prm-method>0 1 0 0 0 0.698 </sw-asap-6-prm-method>
<sw-axis-grouped>
Beschreibung Mehrere Kennlinien haben aus Laufzeitgründen diesselben Stützstellen auf die über Name referenziert wird.

Attribute
-

Enthalten in <sw-param-axis-x>, <sw-param-axis-y>

Beispiel
<sw-axis-individual>
Beschreibung Beschreibung einer Achse, deren Stützstellen individuell festgelegt werden können. Jede Kennlinie oder jedes Kennfeld hat die eigenen, privaten Stützstellenwerte (im Gegensatz zu Gruppenkennlinie).

Attribute
-

Enthalten in <sw-param-axis-x>, <sw-param-axis-y>, <sw-param-group-axis>

Beispiel
<sw-param>
   <long-name></long-name>
   <short-name>etalam</short-name>
   <sw-param-class>curve_individual</sw-param-class>
   <desc></desc>
   <sw-param-array-x>
      <sw-param-axis-x>
         <sw-axis-individual>
            <sw-variable-ref>lambas</sw-variable-ref>
            <max-count>10</max-count>
         </sw-axis-individual>
      </sw-param-axis-x>
       ...
</sw-param>
<sw-axis-shift-offset>
Beschreibung Spezielle aus Laufzeitoptimierungsgründen verwendete Form der Stützstellen. Die Stützstellen berechnen sich nach folgendem Algorithmus: Stützstelle[i] = ... + Offset.

Attribute
[]

Enthalten in <sw-param-axis-x>, <sw-param-axis-y>

Beispiel
<sw-base-type>
Beschreibung Basistyp der sw-variable (z.B. char, integer).

Attribute
-

Enthalten in <sw-param>, <sw-variable-implementation>

Beispiel
<sw-variable-implementation>
   <sw-base-type>UBIT</sw-base-type>
</sw-variable-implementation>
<sw-bit-representation>
Beschreibung Dieses optionale Element enthält Informationen zur Bit-Darstellung in Form von Elementen (Bitanzahl, Bitposition, Bitbasisname, Bitbasistyp) bei Variablen mit dem Datentyp "bit".

Attribute
-

Enthalten in <sw-variable-implementation>

Beispiel
<sw-bit-representation>
   <bit-base-name>variable-short-name</bit-base-name>
   <bit-base-type>w<bit-base-type>
   <bit-coutn>1</>
   <bit-pos>5</>
</sw-bit-pos>
<sw-carb-doc>
Beschreibung CARB-Dokumentation.

Attribute
-

Enthalten in <sw-function-variant>

Beispiel
<sw-code-syntax>
Beschreibung Namensreferenz auf eine Codesyntax. Durch die Codesyntax wird die Darstellung der RAM-Größen und Kengrößen in der Datenquelldatei festgelegt. Die Codesyntaxen werden im <sw-data-dictionary> beschrieben. Diese dort definierten Codesyntaxen können von Variablen und Kenngrößen durch Referenzierung verwendet werden.

Der Inhalt einer Codesyntax ist nicht ausmodelliert, d.h. die Codesyntax wird nur textuell in <sw-code-syntax-desc> beschrieben. Für die Codesyntax gibt es keine standardisierten bzw. in der DTD vordefinierten Werte.
Attribute
[f-id-class]

[id]

Enthalten in <sw-code-syntaxes>

Beispiel
<sw-code-syntax>
   <long-name>CodeSyntax-Objekt für Systemkonstanten</long-name>
   <short-name>cSyKgsSys</short-name>
   <sw-code-syntax-desc>
      <verbatim>CodeSyntax:       cSyKgsSys       CodeSyntax-Objekt für Systemkonstanten
          ... z.B. C-Code

      </verbatim>
   </sw-code-syntax-desc>
</sw-code-syntax>
<sw-code-syntax-class>
Beschreibung Gibt die Klasse der Codesyntax an. Kenngrößen bzw. Variable können nur die Codesyntax einer bestimmten Klasse verwenden. Dies kann jedoch nicht mit SGML-Mitteln sichergestellt werden, es muß die Anwendung tun. Eine Codesyntax ist zum Beispiel für eine Kenngröße oder eine Variable geeignet, oder auch nur für eine Kennline. Durch die Klasse könnte auch die Kombierbarkeit einer bestimmten Codesyntax mit einem bestimmten Ablageschema ausgedrückt werden.

Für die Codesyntax-Klassen gibt es keine standardisierten bzw. in der DTD vordefinierten Werte.
Attribute
-

Enthalten in <sw-code-syntax>

Beispiel
<sw-code-syntax-desc>
Beschreibung Beschreibung der Code-Syntax

Attribute
-

Enthalten in <sw-code-syntax>

Beispiel
<sw-code-syntax-ref>
Beschreibung Innerhalb einer RAM-Größe oder einr Kenngröße kann optional auf eine Code-Syntax verwiesen werden.

Attribute
[HyNames]

[HYTIME]

[sw-code-syntax]

Enthalten in <sw-param>, <sw-variable-implementation>

Beispiel
</sw-variable-implementation>
    ...
   <sw-code-syntax-ref>csyRAMub</sw-code-syntax-ref>
    ...
</sw-variable-implementation>
<sw-code-syntaxes>
Beschreibung Liste der Code-Syntaxen.

Attribute
-

Enthalten in <sw-data-dictionary>

Beispiel
<sw-compu-generic-math>
Beschreibung Die Umrechnungsformel wird durch einen allgemeinen math. Ausdruck beschrieben.

Attribute
-

Enthalten in <sw-compu-method>

Beispiel
<sw-compu-method>
Beschreibung Umrechnungsformel. Rechenvorschrift, nach der eine Steuergeräte-intern verwendete Größe in ihren physikalischen Wert umgerechnet werden kann. Die Umrechnungsformel muß umkehrbar sein.

Attribute
[f-id-class]

[fid]

Enthalten in <sw-compu-methods>

Beispiel
<sw-compu-method-ref>
Beschreibung Verweis auf eine Umrechnungsformel

Attribute
[HyNames]

[HYTIME]

[sw-compu-method]

Enthalten in <sw-param-axis-values>

Beispiel
<sw-compu-method-table>
Beschreibung Bei dieser Form der Umrechnungsformel wird der Zusammenhang zwischen interner und physikalischer Darstellung durch eine Tabelle von int-phys-Wertepaaren angegeben. Es gibt ein Attribut interpolation-style, das die Werte interpolation (default) und discrete annehmen kann.

Attribute
[interpolation-style] Mögliche Werte: interpolation, no-interpolation, discrete. Default: interpolation.

Enthalten in <sw-compu-method>

Beispiel
<sw-compu-method-text>
Beschreibung Die Umrechnungsformel wird in textueller Form beschrieben. Im Gegensatz zu den übrigen Umrechnungstypen stellt die physikalische Seite nicht eine Zahl dar, sondern einen Text. Anwendungen sind denkbar bei Schaltern ("ein"/"aus") oder Länderkennungen ( "D", "F", "US").

Attribute
-

Enthalten in <sw-compu-method>

Beispiel
<sw-compu-method-text>
   <sw-compu-method-text-pair>
      <cmt-int>0</cmt-int>
      <cmt-text>Heck</cmt-text>
   </cmt-compu-method-text-pair>
   <sw-compu-method-text-pair>
      <cmt-int>16</cmt-int>
      <cmt-text>16</cmt-text>
   </cmt-compu-method-text-pair>
</sw-compu-method-text>
<sw-compu-method-text-pair>
Beschreibung Enthält bei textartigen Umrechnunsformeln einen internen und einen textuellen Wert.

Attribute
-

Enthalten in <sw-compu-method-text>

Beispiel
<sw-compu-method-text-pair>
   <cmt-int>0</cmt-int>
   <cmt-text>Heck</cmt-text>
</cmt-compu-method-text-pair>
<sw-compu-method-value-pair>
Beschreibung Enthält bei tabellenartigen Umrechnungsformeln einen internen und einen physikalischen Wert.

Attribute
-

Enthalten in <sw-comput-method-table>

Beispiel
<sw-compu-methods>
Beschreibung Liste der Umrechnungsformeln.

Attribute
-

Enthalten in <sw-data-dictionary>

Beispiel
<sw-data-dictionaries>
Beschreibung Menge der Datadictionaries.

Attribute
-

Enthalten in <sw-data-dictionary-spec>

Beispiel
<msrsw>
   <short-name></short-name>
   <sw-data-dictionary-spec>
      <sw-data-dictionaries>
         <sw-data-dictionary>
                    ...
                  </sw-data-dictionary>
      </sw-data-dictionaries>
   </sw-data-dictionary-spec>
   </msrsw>
<sw-data-dictionary>
Beschreibung Datenlexikon. Hier können Datentypen, Variablen, Parameter, Maßeinheiten, Adressierschemas, Ablageschemas, Codesyntaxen und Umrechnungsformeln beschrieben werden.

Attribute
-

Enthalten in <sw-data-dictionaries>

Beispiel
<msrsw>
   <short-name></short-name>
   <sw-data-dictionary-spec>
      <sw-data-dictionaries>
         <sw-data-dictionary>
                     <sw-datadictionary-class> ... </sw-datadictionary-class>
                     <sw-funtion-ref> ... </sw-funtion-ref>
            <sw-units> ... </sw-units>
            <sw-physic-types> ... </sw-physic-types>
            <sw-variables> ... </sw-variables>
                     <sw-params> ... </sw-params>
                     <sw-compu-methods> ... </sw-compu-methods>
            <sw-addressing-methods> ... </sw-addressing-methods>
                     <sw-param-record-layouts> ... </sw-param-record-layouts>
            <sw-code-syntaxes> ... </sw-code-syntaxes>
                  </sw-data-dictionary>
      </sw-data-dictionaries>
   </sw-data-dictionary-spec>
   </msrsw>
<sw-data-dictionary-spec>
Beschreibung Datadictionary-Spezifikation.

Attribute
-

Enthalten in <msrsw>

Beispiel
<msrsw>
   <short-name></short-name>
   <sw-data-dictionary-spec>
      <sw-data-dictionaries>
         <sw-data-dictionary>
                      ...
                  </sw-data-dictionary>
      </sw-data-dictionaries>
   </sw-data-dictionary-spec>
   </msrsw>
<sw-data-dictionary-class>
Beschreibung In diesem Element können Angaben zur Entstehung, zur Änderung von Datadictionaries gemacht werden, z.B. "Datadictionary von Firma xy".

Attribute
-

Enthalten in <sw-data-dictionary>

Beispiel
<sw-data-type-scaling>
Beschreibung Quantisierung einer Variablen. Beispiel: "16 Bit".

Attribute
-

Enthalten in <sw-physic-type-contents>

Beispiel
<sw-decomposition>
Beschreibung Bildung von Funktionshierarchien durch Referenzierung von eingebauten bzw. verwendeten Funktionen.

Attribute
-

Enthalten in <sw-function-variant>

Beispiel
<sw-function id="funktion">
   <long-name>abgasrückführung</long-name>
   <short-name>agr</short-name>
   <sw-function-class></sw-function-class>
   <sw-function-variants>
      <sw-function-variant>
         <sw-function-desc></sw-function-desc>
         <sw-decomposition>
            <sw-function-ref sw-function="verwendete funktion"></sw-function-ref>
         </sw-decomposition>
       </sw-function-variant>
   </sw-function-variants>
</sw-function>
<sw-fullfils>
Beschreibung Ordnet einer Software-Funktion diejenige bzw. diejenigen (Verhaltens-)Funktionen zu, die sie realisiert.

Attribute
-

Enthalten in <sw-function-variant>

Beispiel
<sw-function>
Beschreibung Software Funktion

Attribute
[f-id-class]

[id]

Enthalten in <sw-functions>

Beispiel
<sw-function id="AGR">
   <long-name>Abgasrückführung</long-name>
   <short-name>AGR</short-name>
   <sw-function-class>nur Dokumentation</sw-function-class>
   <sw-function-variants>
      <sw-function-variant></sw-function-variant>
   </sw-function-variants>
</sw-function>
<sw-function-class>
Beschreibung Funktionsklasse. Die Funktionen können in verschiedene Klassen aufgeteilt werden. Es könnten beispielsweise Funktion, die nur in der Dokumentation/Analysephase auftreten, zu einer Klasse zusammengefaßt werden.

Attribute
-

Enthalten in <sw-function>

Beispiel
<sw-function id="test">
   <long-name></long-name>
   <short-name></short-name>
   <sw-function-class>nur Dokumentation</sw-function-class>
   <sw-function-variants>
      <sw-function-variant></sw-function-variant>
   </sw-function-variants>
</sw-function>
<sw-function-def>
Beschreibung Jede Funktion wird in geeigneter Darstellungsart kurz beschrieben. In der Regel wird eine grafische und eine kurze textuelle Darstellung verwendet. Beispiel: ASCET-Funktionsmodelle, Zustandsdiagramme, SA/SD-Diagramme.

Attribute
-

Enthalten in <sw-function-variant>

Beispiel
<sw-function-variant>
   <sw-function-def>
      <figure id="ascet-bild">
         <long-name></long-name>
         <short-name></short-name>
         <graphic filename="ascet-modell" notation="cgmbin"></graphic>
      </figure>
        ...
      <ncoi-1><p> ... </p></ncoi-1>
       ...
   </sw-function-def>
</sw-function-variant>
<sw-function-desc>
Beschreibung Ausführliche textuelle Beschreibung der Funktion.

Attribute
-

Enthalten in <sw-function-variant>

Beispiel
<sw-function-variant>
   <sw-function-desc>
        ...
      <chapter>
         <p>Das ABS ist eine add-on-Funkiton eines konventionellen Bremssystems.
                     Es besteht aus einem ABS-Hydroaggregat mit integriertem elektronischem
                     Steuergerät und 4 Drehzahlfühlern zur Sensierung des Geschwindigkeitsverhaltens
                     der Räder.
         </p>
      </chapter>
   </sw-function-desc>
    ...
</sw-function-variant>
<sw-function-export-variables>
Beschreibung List der exportierten Variablen. Wenn eine Funktion eine Variable definiert, d.h. eine Variable bzw. den Wert zur Verfügung stellt, so ist sie hier aufzuführen.

Attribute
-

Enthalten in <sw-function-variables>

Beispiel
  <sw-funtion-variables></>
      <sw-function-export-variables>
          <sw-variables-read>
             <sw-variable-ref sw-variable="tmot">tmot</sw-variable-ref>
             <sw-variable-ref sw-variable="b_max_flr">b_max_flr</sw-variable-ref>
          </sw-variables-read>
          <sw-variables-write>
             <sw-variable-ref sw-variable="..."> ... </sw-variable-ref>
          </sw-variables-write>
          <sw-variables-readwrite>
             <sw-variable-ref sw-variable="..."> ... </sw-variable-ref>
          </sw-variables-readwrite>
      </sw-function-export-variables>

   </sw-function-variables>
<sw-function-import-variables>
Beschreibung Liste der importierten Variablen. Hier werden Variablen aufgeführt, die von anderen Funktionen zur Verfügung gestellt werden.

Attribute
-

Enthalten in <sw-function-variables>

Beispiel
<sw-function-local-variables>
Beschreibung Liste der lokalen Variablen, d.h. keine Übergabevariable.

Attribute
-

Enthalten in <sw-function-variables>

Beispiel
<sw-function-modelonly-variables>
Beschreibung Liste der Variablen, die nur im Modell existieren und in der Implementierung nicht mehr vorkommen.

Attribute
-

Enthalten in <sw-function-variables>

Beispiel
<sw-function-ref>
Beschreibung In <msrsw>Verweis auf verwendete Funktionen, die außerhalb von SW beschrieben sind. In <sw-decomposition> Verweis auf Funktionen, die innerhalb <msrsw>beschrieben sind.

Attribute
[HyNames]

[HYTIME]

[sw-function]

Enthalten in <sw-data-dictionary>, <sw-decomposition>, <sw-functions-refs>, <sw-param-content>, <sw-param-contents>,

Beispiel
<sw-function-refs>
Beschreibung Verweise auf verwendete Funktionen, die außerhalb des Dokumentes beschrieben werden. Z.B. Betriebssystemfunktionen, Netzwerkservices.

Attribute
-

Enthalten in <msrsw>

Beispiel
<sw-function-spec>
Beschreibung Funktionsspezifikation. Eine Funktionsspezifikation kann mehrere Funktionen enthalten. Die Funktionen können hierarchisiert sein, indem über <sw-decomposition> auf eine Funktion referenziert wird.

Attribute
-

Enthalten in <msrsw>

Beispiel
<sw-function-variables>
Beschreibung Liste der von der Funktion verwendeten Variablen

Attribute
-

Enthalten in <sw-function-variant>

Beispiel
<sw-function-variant>
    ...
   <sw-funtion-variables></>
      <sw-function-export-variables>
          <sw-variables-read>
             <sw-variable-ref sw-variable="tmot">tmot</sw-variable-ref>
             <sw-variable-ref sw-variable="b_max_flr">b_max_flr</sw-variable-ref>
          </sw-variables-read>
          <sw-variables-write>
             <sw-variable-ref sw-variable="..."> ... </sw-variable-ref>
          </sw-variables-write>
          <sw-variables-readwrite>
             <sw-variable-ref sw-variable="..."> ... </sw-variable-ref>
          </sw-variables-readwrite>
      </sw-function-export-variables>
      <sw-function-import-variables> ... </sw-function-import-variables>
      <sw-function-local-variables> ... </sw-function-local-variables>
      <sw-function-modelonly-variables> ... </sw-function-modelonly-variables>
   </sw-function-variables>
    ...
</sw-function-variant>
<sw-function-variant>
Beschreibung Funktionsvariante. Falls keine Funktionsvarianten verwendet werden, ist trotzdem mindestens eine anzugeben. In der Implementierung V1.1.0 muß jede Funktionsvariante komplett beschrieben werden, d.h. es gibt keine Wiederverwendung.

Mittels< variant-def-ref> kann auf eine Merkmalsleiste in <project-data> ... <var-def> (Funktionsschalter) referenziert werde.
Attribute
-

Enthalten in <sw-function-variants>

Beispiel
<sw-function id="AGR">
   <long-name>Abgasrückführung</long-name>
   <short-name>AGR</short-name>
   <sw-function-class>nur Dokumentation</sw-function-class>
   <sw-function-variants>
      <sw-function-variant>

         <variant-def-refs>
            <variant-def-ref variant-def="v1.2"></variant-def-ref>
            <variant-def-ref variant-def="v1.3"></variant-def-ref>
         </variant-def-refs>
         <sw-function-def> ...</sw-function-def>
         <sw-function-desc> ... </sw-function-desc>
         <sw-function-variables> ... </sw-function-variables>
         <sw-param-refs> ... </sw-param-refs>
         <sw-test-spec> ... </sw-test-spec>
         <sw-application-notes> ... </sw-application-notes>
         <sw-maintenance-notes> ... </sw-maintenance-notes>
         <sw-carb-doc> ... </sw-carb-doc>
         <sw-decomposition> ... </sw-decomposition>
         <add-info></add-info>

      </sw-function-variant>
   </sw-function-variants>
</sw-function>
<sw-function-variants>
Beschreibung Menge der Funktionsvarianten.

Attribute
-

Enthalten in <sw-function>

Beispiel
<sw-functions>
Beschreibung Menge der Funktionen in der Funktionsspezifikation/in dem Dokument. Hüllelement.

Attribute
-

Enthalten in <sw-function-spec>

Beispiel
<sw-glossary>
Beschreibung Glossar

Attribute
-

Enthalten in <msrsw>

Beispiel
<sw-glossary>
   <ncoi-1>
      <def-list>
         <def-item id="gid1">
            <long-name>Interpolationsmethoden</long-name>
            <def><p>Bei Kenngrößen wird zwischen den Stützstellen linear interpoliert.</p></def>
         </def-item>
      </def-list>
   </ncoi-1>
</sw-glossary>
<sw-interpolation-method>
Beschreibung Interpolationsmethode bei Kenngrößen. Die Methoden sind nicht normiert bzw. in der DTD definiert. Die Methoden werden textuell beschrieben.

Attribute
-

Enthalten in <sw-param>

Beispiel
<sw-param>
    ...
   <sw-interpolation-method>linear</sw-interpolation-method>
    ...
</sw-param>
<sw-limits>
Beschreibung Hier werden minimale und maximale Werte für die physikalischen und die Steuergeräte-interne Werten angegeben.

Attribute
-

Enthalten in <sw-axis-individual>, <sw-param-axis-values>, <sw-physic-type-contents>, <sw-variable-implementation>

Beispiel
<sw-variable-implementation>
   <sw-base-type>UBYTE</sw-base-type>
   <sw-limits>
      <phys>
         <phys-min>40.000000</phys-min>
         <phys-max>4000.000000</phys-max>
      </phys>
   </sw-limits>
      ...
</sw-variable-implementation>
<sw-maintenance-notes>
Beschreibung Kundendiensthinweise.

Attribute
-

Enthalten in <sw-function-variant>

Beispiel
<sw-param>
Beschreibung Software-Parameter. Software-parameter sind Kenngrößen ( in ASAP characteristics): Kennlinien, Kennfelder u. Festwerte.

In der Regel sind Kenngrößen im EPROM des Steuergerätes abgelegt. Sie sind applizierbar, d.h. sie können mittels Applikationswerkzeugen im Rahmen der Plausibilität und im Rahmen gesetzter Zugriffsschutzattribute gelesen oder verändert werden. Ausnahmen: z.B. Zylinderzahl, nicht im EPROM, nicht applizierbar. Es gibt ein Attribut calibration mit den möglichen Atributwerten calibration (default), no-calibration u. not-in-memory.
Attribute
[calibration] Mögliche Werte: calibration(default), no-calibration, not-in-memory

[f-child-type]

Enthalten in <sw-params>

Beispiel
<sw-param>
   <long-name></long-name>
   <short-name>etalam</short-name>
   <sw-param-class>curve_individual</sw-param-class>
   <desc></desc>
   <sw-param-array-x>
      <sw-param-axis-x>
         ...
      </sw-param-axis-x>
      <sw-param-axis-values>
         <sw-compu-method-ref>rel_ub-b127b5</sw-compu-method-ref>
      </sw-param-axis-values>
   <sw-addressing-method-ref>NearRomByte</sw-addressing-method-ref>
   <sw-param-record-layout-ref>KlAUbSstUbWUb</sw-param-record-layout-ref>
   <sw-code-syntax-ref>KlNearAUbSstUbUb</sw-code-syntax-ref>
</sw-param>
<sw-param-array-x>
Beschreibung Kennlinie

Attribute
-

Enthalten in <sw-param>

Beispiel
<sw-param-array-x>
   <sw-param-axis-x>
      <sw-axis-individual>
         <sw-variable-ref>N40</sw-variable-ref>
         <max-count></max-count>
      </sw-axis-individual>
   </sw-param-axis-x>
   <sw-param-axis-values>
      <sw-compu-method-ref>FKT256</sw-compu-method-ref>
      <sw-param-noeffect-value>0.04567</sw-param-noeffect-value>
   </sw-param-axis-values>
</sw-param-array-x>
<sw-param-array-xy>
Beschreibung Kennfeld

Attribute
-

Enthalten in <sw-param>

Beispiel
<sw-param>
   <long-name>Kennfeld Abgasrückführung</long-name>
   <short-name>KFAGR</short-name>
   <sw-param-class>map_individual</sw-param-class>
   <desc></desc>
   <sw-param-array-xy>
      <sw-param-axis-x>
         <sw-axis-individual>

            ...
         </sw-axis-individual>
      </sw-param-axis-x>
      <sw-param-axis-y>
         <sw-axis-individual>
            ...
         </sw-axis-individual>
      </sw-param-axis-y>
         <sw-param-axis-values>
         <sw-compu-method-ref>PCENT</sw-compu-method-ref>
         <sw-param-noeffect-value>0.000000</sw-param-noeffect-value>
      </sw-param-axis-values>
   </sw-param-array-xy>
   <sw-addressing-method-ref>Vek</sw-addressing-method-ref>
   <sw-param-record-layout-ref>KF0</sw-param-record-layout-ref>
   <sw-code-syntax-ref>cSyKfVk</sw-code-syntax-ref>
</sw-param>
<sw-param-axis-values>
Beschreibung Werteachse. Beschreibung eines Kennwertes oder der Werte einer Kennlinie oder Kennfeldes.

Attribute
-

Enthalten in <sw-param-array-x>, <sw-param-array-xy>, <sw-param-single-value>, <sw-param-value-block>

Beispiel
<sw-param-axis-values>
   <sw-compu-method-ref>DEZ</sw-compu-method-ref>
   <sw-param-noeffect-value>0.000000</sw-param-noeffect-value>
</sw-param-axis-values>
<sw-param-axis-x>
Beschreibung Beschreibt die x-Achse einer Kenngröße (<sw-param>). Diese Beschreibung besteht aus der Eingangsgröße (als Referenz auf Variable), min, max, max-count (max. Anzahl Stütztstellen).

Attribute
-

Enthalten in <sw-param-array-x>, <sw-param-array-xy>

Beispiel
<sw-param-axis-x>
   <sw-axis-individual>
      <sw-variable-ref>N40</sw-variable-ref>
      <max-count></max-count>
   </sw-axis-individual>
</sw-param-axis-x>
<sw-param-axis-y>
Beschreibung Beschreibt die y-Achse einer Kenngröße (<sw-param>). Diese Beschreibung besteht aus der Eingangsgröße (als Referenz auf Variable), min, max, max-count (max. Anzahl Stütztstellen).

Attribute
-

Enthalten in <xs-param-array-xy>

Beispiel
<sw-param-axis-y>
   <sw-axis-individual>
      <sw-variable-ref>TL</sw-variable-ref>
      <max-count>4</max-count>
   </sw-axis-individual>
</sw-param-axis-y>
<sw-param-class>
Beschreibung Gibt die Art einer Kenngröße an (Kennlinie, Kennfeld, Kennwert, Festkennlinie, Gruppenkennlinie, Festkennfeld).

Attribute
-

Enthalten in <sw-param>, <sw-param-content>

Beispiel
<sw-param>
   <long-name>Kennfeld Abgasrückführung</long-name>
   <short-name>KFAGR</short-name>
   <sw-param-class>map_individual</sw-param-class>
    ...
</sw-param>
<sw-param-content>
Beschreibung Kenngrößenwerte

Attribute
-

Enthalten in <sw-param-contents>

Beispiel
<sw-param-contents-spec>
   <sw-param-contents>
      <sw-param-contents-class>msr-test-values</sw-param-contents-class>

      <sw-param-content>
         <sw-param-ref>DLIP</sw-param-ref>
         <sw-param-class>curve_fixed</sw-param-class>
         <sw-param-content-x>
            <sw-unit-ref>Upm</sw-unit-ref>
            <sw-param-values-phys>
                <v>0.000000</v><v>10.000000</v>
            </sw-param-values-phys>
         </sw-param-content-x>
         <sw-param-content-v>
            <sw-unit-ref>kg/h pro sec</sw-unit-ref>
            <sw-param-values-phys>
               <v>3.780000</v><v>32.90000</v>
            </sw-param-values-phys>
         </sw-param-content-v>
      </sw-param-content>

   </sw-param-contents>
</sw-param-contents-spec>
<sw-param-contents-class>
Beschreibung Gibt die Art der Dateninhalte/Datensätze an, z.B.: "Testdaten", "Rohapplikationsdaten".

Die Kenngrößenklassen sind nicht normiert bzw. in der DTD definiert.
Attribute
-

Enthalten in <sw-param-contents>

Beispiel
<sw-param-contents-class>Testdaten</>
<sw-param-content-text>
Beschreibung Hier stehen die Werte eines Textparameters (sw-param-text).

Attribute
-

Enthalten in <sw-param-content>

Beispiel
<sw-param-content-text>EIN</sw-param-content-text>
<sw-param-content-v>
Beschreibung Hier steht bei einem Kennwert ein einzelner Wert. Bei einer Kennlinie stehen hier die Werte der v-Achse. Bei einem Kennfeld stehen hier die Werte der v-Achse. Dabei gilt die Konvention: Index der x-Achse läuft schneller. Werte sind durch Leerzeichen oder Zeilenvorschübe getrennt.

Attribute
-

Enthalten in <sw-param-content>

Beispiel
<sw-param-content-v>
   <sw-unit-ref>dez</sw-unit-ref>
      <sw-param-values-phys>
         <v>1.000000</v><v>2.000000</v><v>3.000000</v><v>4.000000</v><v>5.000000</v><v>6.000000</v>
   </sw-param-values-phys>
</sw-param-content-v>
<sw-param-content-x>
Beschreibung Hier stehen die physikalischen, internen, ... Werte der x-Achse.

Attribute
-

Enthalten in <sw-param-content>

Beispiel
<sw-param-content-x>
   <sw-param-values-phys>
      <v>-30.5</v><v>-20.0</v><v>30</v>
   </sw-param-values-phys>
<sw-param-content-x>
<sw-param-content-y>
Beschreibung Hier stehen die physikalischen, internen, ... Werte der y-Achse.

Attribute
-

Enthalten in <sw-param-content>

Beispiel
<sw-param-content-y>
   <sw-param-values-phys>
      <v>-30.5</v><v>-20.0</v><v>30</v>
   </sw-param-values-phys>
<sw-param-content-y>
<sw-param-contents-spec>
Beschreibung Spezifikation der Kenngrößeninhalte.

Attribute
-

Enthalten in <msrsw>, <sw-function-variant>

Beispiel
<sw-param-contents-spec>
   <sw-param-contents>
      <sw-param-contents-class>msr-test-values</sw-param-contents-class>

      <sw-param-content>
         ...
      </sw-param-content>
      <sw-param-content>
         ...
      </sw-param-content>

   </sw-param-contents>
</sw-param-contents-spec>
<sw-param-group-axis>
Beschreibung Gruppenkennlinie

Attribute
-

Enthalten in <sw-param>

Beispiel
<sw-param>
   <long-name></long-name>
   <short-name>N40</short-name>
   <sw-param-class>axis_points</sw-param-class>
   <desc></desc>
   <sw-param-group-axis>
      <sw-axis-individual>
         <sw-variable-ref>N40</sw-variable-ref>
         <max-count></max-count>
      </sw-axis-individual>
   </sw-param-group-axis>
     ...
</sw-param>
<sw-param-noeffect-value>
Beschreibung Wert, der die Wirkung einer Kenngröße aufhebt (typischerweise 0 oder 1).

Attribute
-

Enthalten in <sw-param-axis-values>

Beispiel
<sw-param>
   <long-name>Kennfeld Abgasrückführung</long-name>
   <short-name>KFAGR</short-name>
   <sw-param-class>map_individual</sw-param-class>
   <desc></desc>
   <sw-param-array-xy>
      <sw-param-axis-x>
        ...
      </sw-param-axis-x>
      <sw-param-axis-y>
            ...
         </sw-axis-individual>
      </sw-param-axis-y>
         <sw-param-axis-values>
         <sw-compu-method-ref>PCENT</sw-compu-method-ref>
         <sw-param-noeffect-value>0.000000</sw-param-noeffect-value>
      </sw-param-axis-values>
   </sw-param-array-xy>
    ...
</sw-param>
<sw-param-record-layout>
Beschreibung Ablageschema (in ASAP record layout). Ein Ablageschema beschreibt die Form der Ablage einer Kenngröße im Eprom. Über das Ablageschema wird die Reihenfolge der Bestandteile der Kenngröße und deren Datentyp bestimmt. So könnte ein Ablageschema für eine Kennlinie festlegen, daß zuerst die Adresse der Eingangsgröße als byte, dann die Stützstellenanzahl als unsigned byte, dann die Stützstellen als signed word und als letztes die Werte der Kennlinie als unsigned word abzulegen sind.

Dieses Element ist eine Namensreferenz auf ein Ablageschema. Dieses Ablageschema benennt den Aufbau des Speicherobjekts im Speicher des Steuergerätes. Nachfolgende Systemen (z.B. Verstellysteme) müssen diese Ablageschemata auswerten. Die Verbindung zu derartigen Systemen geschieht über diesen Namen.
Codesyntax-Objekte beschreiben die Darstellung eines Objektes in einer Programmiersprache, die Ablageschema-Objekte ihre Ablage im Eprom. Codesyntax-Objekte und Ablageschema-Objekte müssen konsistent sein. D.h. eine Kenngröße kann bei dem Ablageschema nicht Wort-Ablage und bei der Code-Syntax Byte-Ablage verwenden.
Das Ablageschema ist nicht ausmodelliert. Das eigentliche Ablageschema kann textuell in <sw-param-record-layout-desc> beschrieben werden.
Attribute
[f-id-class]

[id]

Enthalten in <sw-param-record-layouts>

Beispiel
<sw-param-record-layout>
   <long-name>Ablageschema DAMOS_KF0</long-name>
   <short-name>DAMOS_KF0</short-name>
   <sw-param-record-layout-desc>
      <verbatim>Ablageschema:           DAMOS_KF0
          ...
          Werte spaltenweise      Unsigned Byte
      </verbatim>
   </sw-param-record-layout-desc>
</sw-param-record-layout>
<sw-param-record-layout-class>
Beschreibung Gibt die Klasse des Ablageschemas an. Kenngrößen bzw. Variable können nur Ablageschemas einer bestimmten Klasse verwenden. Dies kann jedoch nicht mit SGML-Mitteln sichergestellt werden, es muß die Anwendung tun. Die Ablageklassen sind nicht standardisiert und nicht in der DTD definiert.

Attribute
-

Enthalten in <sw-param-record-layout>

Beispiel
<sw-param-record-layout-desc>
Beschreibung Hier kann das Ablageschema textuell bechrieben werden.

Attribute
-

Enthalten in <sw-param-record-layout>

Beispiel
<sw-param-record-layout-desc>
   <verbatim>Ablageschema:           FKF0
      Element                 Datentyp
      -----------------------------------------------
      Abl-Element-Liste
      Sst-X aequidist.        nicht im EPROM
      Sst-Y aequidist.        nicht im EPROM
      Werte spaltenweise      Unsigned Byte
   </verbatim>
</sw-param-record-layout-desc>
<sw-param-ref>
Beschreibung Verweis auf <sw-param> Kenngröße. Ist bei <sw-param-ref> in <sw-function-variant> das Attribut owns nicht definiert, so bedeutet das, daß die Kenngröße in der Funktion definiert wird und ihr somit gehört.

Attribute
[HyNames]

[HYTIME]

[owns]

[sw-param]

Enthalten in <sw-axis-grouped>, <sw-param-content>, <sw-param-refs>

Beispiel
<sw-function-variant>
    ...
   <sw-param-refs></sw-param-refs>
      <sw-param-ref  owns="noown" sw-param="lamx">lamx</sw-param-ref>
   </sw-param-refs>
    ...
</sw-function-variant>
<sw-param-single-value>
Beschreibung Applizierbare Einzelgröße. Eine Einzelgröße wird wie eine Kennlinie mit einem Element behandelt. Die Kenngröße wird in< sw-param> definiert, der Wert steht in <sw-param-content>. Die Zuordnung geschieht durch Referenzierung in<sw-param-ref> von <sw-param-content> auf <sw-param>.

Attribute
-

Enthalten in <sw-param>

Beispiel
<sw-param>
   <long-name></long-name>
   <short-name>KUP_SIG_G</short-name>
   <sw-param-class>value</sw-param-class>
   <desc></desc>
   <sw-param-single-value>
      <sw-param-axis-values>
         <sw-compu-method-ref>TEMPQ</sw-compu-method-ref>
      </sw-param-axis-values>
   </sw-param-single-value>
   <sw-addressing-method-ref>offset</sw-addressing-method-ref>
   <sw-param-record-layout-ref>KW0</sw-param-record-layout-ref>
   <sw-code-syntax-ref>cSyKwByte</sw-code-syntax-ref>
</sw-param>

<sw-param-content>
   <sw-param-ref>KUP_SIG_G</sw-param-ref>
   <sw-param-class>value</sw-param-class>
   <sw-param-content-v>
      <sw-unit-ref>grad C</sw-unit-ref>
      <sw-param-values-phys>
         <v>-88.3456</v>
      </sw-param-values-phys>
   </sw-param-content-v>
</sw-param-content>
<sw-param-target>
Beschreibung Referenz auf Name einer Variablen/RAM-Zelle in welcher das Ergebnis der Interpolation stehen soll.

Attribute
-

Enthalten in <sw-param-group-axis>

Beispiel
<sw-param-group-axis>
      <sw-axis-individual>
         <sw-variable-ref>N40</sw-variable-ref>
         <max-count></max-count>
      </sw-axis-individual>
      <sw-param-target>
         <sw-variable-ref><sw-variable-ref>
      </sw-param-target>
   </sw-param-group-axis>
<sw-param-text>
Beschreibung Hier können Kenngrößen beschrieben werden, die als Werte Texte haben. Beispiel: Meldungstext für Fahrerrückmeldungen. Die Werte stehen in <sw-param-content-text>.

Attribute
-

Enthalten in <sw-param>

Beispiel
<sw-param>
   <long-name></long-name>
   <short-name>EIN</short-name>
   <sw-param-class>ASCII</sw-param-class>
   <desc></desc>
   <sw-param-text></sw-param-text>
</sw-param>
<sw-param-value-block>
Beschreibung Ein Kenngrößenblock besteht aus einem array von gleichartigen Kennwerten. Die Anzahl wird in <count> angegeben.

Attribute
-

Enthalten in <sw-param>

Beispiel
<sw-param>
   <long-name></long-name>
   <short-name>KWBLOCK1</short-name>
   <sw-param-class>value_block</sw-param-class>
   <desc></desc>
   <sw-param-value-block>
      <sw-param-axis-values>
         <sw-compu-method-ref>TIQ</sw-compu-method-ref>
      </sw-param-axis-values>
      <count>2</count>
   </sw-param-value-block>
   <sw-addressing-method-ref>dir</sw-addressing-method-ref>
   <sw-param-record-layout-ref>KWB0</sw-param-record-layout-ref>
   <sw-code-syntax-ref>cSyKwb</sw-code-syntax-ref>
</sw-param>

<sw-param-content>
   <sw-param-ref>KWBLOCK1</sw-param-ref>
   <sw-param-class>value_block</sw-param-class>
   <sw-param-content-v>
      <sw-unit-ref>ms/Umdr.</sw-unit-ref>
      <sw-param-values-phys><v>0.012345</v><v>0.099999</v></sw-param-values-phys>
    </sw-param-content-v>
</sw-param-content>
<sw-param-values-adr>
Beschreibung Dieses Element enhält die Adressen von Kenngrößen. Die Werte stehen in dem Subelement <v>, das bei einem einzelnen Kennwert einmal und bei Kenngrößen mehrfach vorkommt.

Attribute
-

Enthalten in <sw-param-content-v>, <sw-param-content-x>, <sw-param-content-y>

Beispiel
<sw-param-values-coded>
Beschreibung Dieses Element enhält die Werte von Kenngrößen in codierter Form. Die Werte stehen in dem Subelement <v>, das bei einem einzelnen Kennwert einmal und bei Kenngrößen mehrfach vorkommt.

Attribute
-

Enthalten in <sw-param-content-v>, <sw-param-content-x>, <sw-param-content-y>

Beispiel
<sw-param-values-coded-hex>
Beschreibung Dieses Element enhält die Werte von Kenngrößen in hexadezimaler codierter Form. Die Werte stehen in dem Subelement <v>, das bei einem einzelnen Kennwert einmal und bei Kenngrößen mehrfach vorkommt.

Attribute
-

Enthalten in <sw-param-content-v>, <sw-param-content-x>, <sw-param-content-y>

Beispiel
<sw-param-values-generic>
Beschreibung Hier können Werte in einem nicht direkt unterstützten Format abgelegt werden. Dieses Format wird im Attribut [type] angegeben. Die Verwendung dieses Elementes ist prozeßspezifisch.

Attribute
[type]

Enthalten in <sw-param-content-v>, <sw-param-content-x>, <sw-param-content-y>

Beispiel
<sw-param-values-phys>
Beschreibung Dieses Element enhält die Werte von Kenngrößen in physikalischer Form. Die Werte stehen in dem Subelement <v>, das bei einem einzelnen Kennwert einmal und bei Kenngrößen mehrfach vorkommt.

Attribute
-

Enthalten in <sw-param-content-v>, <sw-param-content-x>, <sw-param-content-y>

Beispiel
<sw-params>
Beschreibung Liste der Kenngrößen (Hüllelement).

Attribute
-

Enthalten in <sw-data-dictionary>

Beispiel
<sw-params>
   <admin-data>  ... </admin-data>
   <sw-param><admin-data>  ... </admin-data> ... </sw-param>
     ...
   <sw-param><admin-data>  ... </admin-data> ... </sw-param>
</sw-params>
<sw-physic-type>
Beschreibung Definition eines physikalischen, implementierungsunabhängigen und wiederverwendbaren Datentyps. Physikalische Datentypen werden in den frühen Phasen der Steuergerätesoftwareentwicklung definiert.

Attribute
[f-id-class]

[id]

Enthalten in <sw-physic-types>

Beispiel
<sw-physic-type>
   <long-name>Drehzahl</long-name>
   <short-name>n</short-name>
   <desc></desc>
   <sw-unit-ref>Umin</sw-unit-ref>
   <sw-limits>
      <phys><phys-min>0</phys-min><phys-max>8000</phys-max></phys>
   </sw-limits>
   <sw-resolution>20</sw-resolution>
   <sw-data-type-scaling>8bit</sw-data-type-scaling>
   <sw-variable-sample-rate>10</sw-variable-sample-rate>
   <sw-var-init-value>0</sw-var-init-value>
   <sw-var-not-av-value></sw-var-not-av-value>
</sw-physic-type>
<sw-physic-type-1>
Beschreibung Physikalische Datentypen können bei <sw-physic-types> im Datadictionary und auch direkt bei der Variblendefinition definiert werden. Die direkt bei der Variablen definierten physikalischen Eigenschaften haben keinen <long-name> und keinen <short-name> und sind nicht referenzierbar.

Attribute
-

Enthalten in <sw-variable>

Beispiel
<sw-physic-type-1>
   <desc></desc>
   <sw-unit-ref>Umin</sw-unit-ref>
   <sw-limits>
      <phys><phys-min>0</phys-min><phys-max>8000</phys-max></phys>
      </sw-limits>
   <sw-resolution>20</sw-resolution>
   <sw-data-type-scaling>8bit</sw-data-type-scaling>
   <sw-variable-sample-rate>10</sw-variable-sample-rate>
   <sw-var-init-value>0</sw-var-init-value>
   <sw-var-not-av-value></sw-var-not-av-value>
</sw-physic-type-1>
<sw-physic-type-contents>
Beschreibung Beschreibung eines physikalischen Datentyps.

Attribute
-

Enthalten in <sw-physic-type>, <sw-physic-type-1>

Beispiel
<sw-physic-type-ref>
Beschreibung Verweis/Verwendung eines physikalischen Datentyps durch eine Variable.

Attribute
[HyNames]

[HYTIME]

[sw-physic-type]

Enthalten in <sw-variable>

Beispiel
<sw-variable id="tmot">
   <long-name>motortemperatur</long-name>
   <short-name>tmot</short-name>
   <desc></desc>
   <sw-physic-type-ref sw-physic-type="temp">n</sw-physic-type-ref>
   <sw-variable-implementation></sw-variable-implementation>
</sw-variable>
<sw-physic-types>
Beschreibung Menge der physikalischen Datentypen.

Attribute
-

Enthalten in <sw-data-dictionary>

Beispiel
<sw-data-dictionary>
    ...
   <sw-physic-types>
      <sw-physic-type>
         ...
      </sw-physic-type>
      <sw-physic-type>
         ...
      </sw-physic-type>
   </sw-physic-types>
    ...
</sw-data-dictionary>
<sw-resolution>
Beschreibung Auflösung, z.B: "100 U/m/s". Wobei nur "100" anzugeben ist, "U/m/s" ist die Einheit, die in <sw-unit> steht.

Attribute
-

Enthalten in <sw-physic-type-contents>

Beispiel
<sw-physic-type>
   <long-name>Drehzahl</long-name>
   <short-name>n</short-name>
    ...
   <sw-unit-ref>Umin</sw-unit-ref>
       ...
   <sw-resolution>20</sw-resolution>
       ...
</sw-physic-type>
<sw-unit>
Beschreibung Definition einer Maßeinheit.

Attribute
[f-id-class]

[id]

Enthalten in <sw-units>

Beispiel
<sw-units>
   <sw-unit>
      <long-name>Kilometer pro Stunde</long-name>
      <short-name>kmh</short-name>
      <sw-unit-display>km/h</sw-unit-display>
      <sw-unit-ref>mps</sw-unit-ref>
      <sw-unit-to-ref-method>0 1 0 0 3600 0</sw-unit-to-ref-method>
      <sw-unit-from-ref-method></sw-unit-from-ref-method>

   </sw-unit>
   <sw-unit>
      <long-name>Meter pro Sekunde</long-name>
      <short-name>mps</short-name>
      <si-unit length-expo = "1" time-expo = "-1"></si-unit>
      <sw-unit-display></sw-unit-display>
   </sw-unit>
</sw-units>
<sw-unit-display>
Beschreibung Angabe, wie die Maßeinheit auf einem Ausgabemedium dargestellt werden soll.

Attribute
-

Enthalten in <sw-unit>

Beispiel
<sw-units>
   <sw-unit>
      <long-name>Kilometer pro Stunde</long-name>
      <short-name>kmh</short-name>
      <sw-unit-display>km/h</sw-unit-display>
          ....
   </sw-unit>
</sw-units>
<sw-unit-ref>
Beschreibung Verweis auf eine bereits definierte Maßeinheit zur Verwendung.

Attribute
[HyNames]

[HYTIME]

[sw-unit]

Enthalten in <sw-compu-method>, <sw-param-content-v>, <sw-param-conten-x>, <sw-param-content-y>, <sw-physic-type-contents>

Beispiel
<sw-compu-method>
    ...
   <sw-unit-ref>dez</sw-unit-ref>
    ...
</sw-comput-method><>
<sw-var-init-value>
Beschreibung Initialisierungswert einer Variablen.

Attribute
-

Enthalten in <sw-physic-type-contents>, <sw-variable-implementation>

Beispiel
<sw-variable>
   <long-name></long-name>
   <short-name>N40</short-name>
   <desc></desc>
   <sw-variable-implementation>
    ...
      <sw-var-init-value>100.000000</sw-var-init-value>
    ...
   </sw-variable-implementation>
</sw-variable>
<sw-var-not-av-value>
Beschreibung Interner Wert für nicht verfügbar, externen Wert kann es nicht geben.

Attribute
-

Enthalten in <sw-physic-type-contents>

Beispiel
<sw-physic-type>
   <long-name>Drehzahl</long-name>
   <short-name>n</short-name>
   <desc></desc>
      ...
   <sw-var-init-value>0</sw-var-init-value>
   <sw-var-not-av-value></sw-var-not-av-value>
    ...
</sw-physic-type>
<sw-variable>
Beschreibung Variable ( in ASAP "measurement"). Variable Größe, die für den Algorithmus einer Steuergerätefunktion benötigt wird. Variablen werden in der Regel im RAM abgelegt. Man unterscheidet zwischen Eingangs-, Zwischen- (lokale) und Ausgangsgrößen.

Attribute
[calibration]

[f-id-class]

[f-namespace]

[id]

Enthalten in <sw-variables>

Beispiel
<sw-variables>
   <sw-variable>
      <long-name></long-name>
      <short-name>N40</short-name>
      <desc></desc>
      <sw-variable-implementation>
            ...
      </sw-variable-implementation>
   </sw-variable>
    ...
</sw-variables>
<sw-variable-implementation>
Beschreibung Element bei sw-variable, bei dem Implementierungshinweise eingetragen werden können ( nicht manuell zu füllen).

Attribute
-

Enthalten in <sw-variable>

Beispiel
<sw-variables>
   <sw-variable>
      <long-name></long-name>
      <short-name>N40</short-name>
      <desc></desc>
      <sw-variable-implementation>
         <sw-base-type>UBYTE</sw-base-type>
         <sw-limits>
            <phys>
               <phys-min>10.000000</phys-min>
               <phys-max>3000.000000</phys-max>
            </phys>
         </sw-limits>
         <sw-var-init-value>160.000000</sw-var-init-value>
         <sw-addressing-method-ref>defaultAdrS</sw-addressing-method-ref>
         <sw-compu-method-ref>NQ40</sw-compu-method-ref>
         <sw-code-syntax-ref>csyRAMub</sw-code-syntax-ref>
      </sw-variable-implementation>
   </sw-variable>
    ...
</sw-variables>
<sw-variable-kind>
Beschreibung z.B. Datenfluß, Kontrollfluß.

Attribute
-

Enthalten in <sw-variable-implementation>

Beispiel
<sw-variable-ref>
Beschreibung Verweis auf <sw-variable> / RAM-Größe.

Attribute
[HyNames]

[HYTIME]

[sw-variable]

Enthalten in <sw-axis-individual>, <sw-axis-shift-offset>, <sw-function-modelonly-variables>, <sw-param-target>, <sw-variables-read>, <sw-variables-readwrite>, <sw-variables-write>

Beispiel
<sw-variable-sample-rate>
Beschreibung Abtastrate bzw. zeitliche Auflösung (z.B. Kurbelwellensynchron, alle 10 ms).

Attribute
-

Enthalten in sw-physic-type-contents

Beispiel
<sw-variables>
Beschreibung Menge der Variablen eines Datadictionaries. Die Struktur zur Beschreibung der Variablen ist rekursiv, somit können hierarische Variblenstrukturen aufgebaut werden (z.B. Struct-Konstrukt in C).

Attribute
-

Enthalten in <sw-data-dictionary>, <sw-variable-implemenation>

Beispiel
<SW-VARIABLES>
   <SW-VARIABLE ID="sw1">
      <LONG-NAME></LONG-NAME>
      <SHORT-NAME></SHORT-NAME>
      <DESC></DESC>
                 ...
      SW-VARIABLE-IMPLEMENTATION>
         <SW-VARIABLES>
            <SW-VARIABLE ID="sw2"></SW-VARIABLE>
         </SW-VARIABLES>
      </SW-VARIABLE-IMPLEMENTATION>
</SW-VARIABLE></SW-VARIABLES>
<sw-variables-read>
Beschreibung Variablen, auf die von einer Funktion lesend zugegriffen werden.

Attribute
-

Enthalten in <sw-function-export-variables>, <sw-function-import-variables>

Beispiel
<sw-function-import-variables>
   <sw-variables-read>
      <sw-variable-ref>TL</sw-variable-ref>
      <sw-variable-ref>TMOT</sw-variable-ref>
   </sw-variables-read>
</sw-function-import-variables>
<sw-variables-readwrite>
Beschreibung Variablen, auf die von einer Funktion lesend und schreibend zugegriffen werden.

Attribute
-

Enthalten in <sw-function-export-variables>, <sw-function-import-variables>, <sw-function-local-variables>

Beispiel
<sw-function-import-variables>
   <sw-variables-readwrite>
      <sw-variable-ref>TL</sw-variable-ref>
      <sw-variable-ref>TMOT</sw-variable-ref>
   </sw-variables-readwrite>
</sw-function-import-variables>
<sw-variables-write>
Beschreibung Variablen, auf die von einer Funktion schreibend zugegriffen werden.

Attribute
-

Enthalten in <sw-function-export-variables>, <sw-function-import-variables>

Beispiel
<team-member-ref>
Beschreibung Verweis auf ein team-member

Attribute
[HyNames]

[HYTIME]

[team-member]

Enthalten in <team-members>

Beispiel
<doc-revision>
      ...
   <team-member-ref team-member="team-member-not-available">team-member-not-available
   </team-member-ref>
   <date>08.12.1997</date>
 ...
</doc-revision>
<tbd>
Beschreibung "to be defined"

Attribute
-

Enthalten in <general-project-data>, <info>, <sample-spec>, <sw-data-dictionary-spec>, <sw-function-spec>, <sw-glossary>, <sw-param-contents-spec>, <variant-spec>

Beispiel
<sw-param-contents-spec><tbd></tbd></sw-param-contents-spec>
<tbr>
Beschreibung "to be resolved"

Attribute
-

Enthalten in <general-project-data>, <info>, <sample-spec>, <sw-data-dictionary-spec>, <sw-function-spec>, <sw-glossary>, <sw-param-contents-spec>, <variant-spec>

Beispiel
<topic-1>
Beschreibung Kapitelstruktur. Im Gegensatz zu chapter erscheint es jedoch nicht als eigenständiges Kapitel im Inhaltsverzeichnis.

Attribute
[f-id-class] topic

[help-entry]

[id]

Enthalten in <add-info>, <chapter>, <ncoi-1>, <sw-addressing-method-desc>, <sw-application-notes>, <sw-carb-doc>, <sw-code-syntax-desc>, <sw-function-desc>, <sw-maintenance-notes>, <sw-param-record-layout-desc>, <sw-test-spec>

Beispiel
<topic-2>
Beschreibung Einführungskapitel, Kapitelstruktur. Gleich mit topic-1, nur keine prms. Im Gegensatz zu chapter erscheint es jedoch nicht als eigenständiges Kapitel im Inhaltsverzeichnis.

Attribute
[f-id-class] topic

[help-entry]

[id]

Enthalten in <introduction>

Beispiel
<used-languages>
Beschreibung Liste der verwendeten Sprachen bei <admin-data>. Die Mastersprache wird in <language> angegeben.

Attribute
-

Enthalten in <admin-data>

Beispiel
<admin-data>
   <languages>de</language>
   <used-languages>de ge fr</used-languages>
</admin-data>
<variant-char>
Beschreibung Hier können die Variantenmerkmale beschrieben werden.

Attribute
[id]

[f-id-class]

[type] REQUIRED: new-part-number, no-new-part-number

Enthalten in <variant-chars>

Beispiel
<variant-chars>
   <variant-char id="sprache" type="new-part-number">
      <long-name></long-name>
      <short-name>sprache</short-name>
      <code></code>
   </variant-char>
   <variant-char id="getriebeart" type="new-part-number">
      <long-name></long-name>
      <short-name>getriebeart</short-name>
      <code></code>
   </variant-char>
   <variant-char id="zylinderzahl" type="new-part-number">
      <long-name></long-name>
      <short-name>zylinderzahl</short-name>
      <code></code>
   </variant-char>
</variant-chars>
<variant-def>
Beschreibung Beschreibung der Variantendefinitionen, auf die in <sw-funtion-variant> referenziert werden kann. Bei einer Variantendefiniton werden hier einer Varianten die entsprechenden Variantenmerkmale (<variant-def>) zugeordnet und es findet die Zuordnung von Variantenmerkmal zu Merkmalswert (<variant-char-value>, <value>) statt.

Attribute
-

Enthalten in <variant-defs>

Beispiel
<variant-defs>
   <variant-def id="V1">
   <long-name>Variante  6-Zylinder Automatik Deutsch</long-name>
   <short-name>V1</short-name>
   <code></code>
   <variant-char-assigns>
      <variant-char-assign>
         <variant-char-ref variant-char="Sprache">Sprache</variant-char-ref>
         <variant-char-value>
            <value>de</value>
            <code></code>
         </variant-char-value>
      </variant-char-assign>
      <variant-char-assign>
         <variant-char-ref variant-char="Zylinderart">Zylinderart</variant-char-ref>
         <variant-char-value>
            <value>en</value>
            <code></code>
         </variant-char-value>
      </variant-char-assign>
      <variant-char-ref variant-char="Getriebeart">getriebeart</variant-char-ref>
         <variant-char-value>
            <value>automatik</value>
            <code></code>
         </variant-char-value>
      </variant-char-assign>
   </variant-char-assigns>
</variant-def>
<variant-def-ref>
Beschreibung

Attribute
[HyNames]

[HYTIME]

[variant-def]

Enthalten in <variant-def-refs>

Beispiel
<sw-function-variant>
   <variant-def-refs>
      <variant-def-ref variant-def="V1">V1</variant-def-ref>
      <variant-def-ref variant-def="V2">V2</variant-def-ref>
   /variant-def-refs>
</sw-function-variant>
<variant-def-refs>
Beschreibung

Attribute
-

Enthalten in <sw-function-variant>

Beispiel
<sw-function-variant>
   <variant-def-refs>
      <variant-def-ref variant-def="V1">V1</variant-def-ref>
      <variant-def-ref variant-def="V2">V2</variant-def-ref>
   /variant-def-refs>
</sw-function-variant>


3.3. Beschreibung der Attribute

[amount-of-substance-exp]
Beschreibung Mole; quantity, compared to the number of atoms in 0.012 kilogram of carbon 12.

Mögl. Werte

Default IMPLIED

Enthalten in si-unit

Beispiel
[calibration]
Beschreibung Beschreibt die Kalibrierbarkeit einer Kenngröße (<sw-param>) oder einer Variablen.

Mögl. Werte calibration, no-calibration, not-in-memory

Default calibration

Enthalten in sw-param

Beispiel
[category]
Beschreibung Typ einer Grafik

Mögl. Werte barcode, conceptual, engineering, flowchart, graph, logo, schematic, waveform

Default IMPLIED

Enthalten in graphic

Beispiel
[electric-current-expo]
Beschreibung Electric current (ampere).

Mögl. Werte

Default IMPLIED

Enthalten in si-unit

Beispiel
[ext-id-class]
Beschreibung Externe Id-Klasse

Mögl. Werte

Default IMPLIED

Enthalten in xref

Beispiel
[f-child-type]
Beschreibung

Mögl. Werte

Default

Enthalten in xref, std, xdoc, company, roles, sample, admin-data, doc-revision, company-revision-info

Beispiel
[f-id-class]
Beschreibung Alle Objekte, die einen Namen tragen/einen <short-name> haben und damit eine [id] haben, werden durch das Attribut [f-id-class] markiert. Der Wert von [f-id-class] wird gleich dem Elementnamen des Objekts gewählt.

Mögl. Werte chapter, company, def-item, figure, formula, prm, sample, std, sw-function, sw-unit, sw-physic-type, sw-variable, sw-param, sw-compu-method, sw-addressing-method, sw-record-layout, sw-code-syntax, table, team-member, topic, variant-char, variant-def, xdoc, xfile, external

Default REQUIRED

Enthalten in xref

Beispiel
<xref id-ref="agr" id-class="sw-function"></xref>
[idref]
Beschreibung

Mögl. Werte

Default REQUIRED

Enthalten in

Beispiel
[f-namespace]
Beschreibung Um z.B. unterschiedliche Teilbäume ohne Namenskonflikte zusammenfügen zu können, werden Namensraumgrenzen eingeführt. Diese Namensraumgrenzen werden durch das Attribut [f-namespace] markiert, dessen Wert mit dem Attribut [f-id-class] des jeweiligen Objekttyps übereinstimmt. Alle Objekte eines Typs müssen innerhalb dieses Teilbaumes verschieden benannt werden.

Mögl. Werte

Default

Enthalten in

Beispiel
[f-pubid]
Beschreibung

Mögl. Werte

Default -//MSR//DTD MSR SOFTWARE DTD:V1.1.0:MSRSW.DTD//EN

Enthalten in msrsw

Beispiel
[id]
Beschreibung Identifier

Mögl. Werte

Default REQUIRED

Enthalten in chapter, company, def-item, figure, formula, nameloc, prm, sample, std, sw-addressing-method, sw-function, sw-param, sw-param-record-layout, sw-physic-type, sw-unit, sw-variable, table, team-member, topic-1, topic-2, variant-char, variant-def, xdoc, xfile

Beispiel
[interpolation-style]
Beschreibung Art der Interpolation bei einer Umrechnungstabelle.

Mögl. Werte interpolation, no-interpolation, discrete

Default interpolation

Enthalten in sw-compu-method-table

Beispiel
[length-expo]
Beschreibung Length in metre.

Mögl. Werte

Default IMPLIED

Enthalten in si-unit

Beispiel
[luminous-intensity-expo]
Beschreibung Luminous intensity in candela.

Mögl. Werte

Default IMPLIED

Enthalten in si-unit

Beispiel
[mass-expo]
Beschreibung Mass in gram.

Mögl. Werte

Default IMPLIED

Enthalten in si-unit

Beispiel
[owns]
Beschreibung In <sw-param-ref> mit möglichen Attributwerten "noown".

Mögl. Werte noown

Default IMPLIED

Enthalten in sw-param-ref

Beispiel
<sw-param-ref owns="noown" sw-param="lamx">lamx<sw-param-ref>
[s]
Beschreibung Signature. Anhand der Signatur kann festgestellt werden, was sich beim Austausch in einer Instanz geändert hat. Die Signatur wird durch ein Werkzeug erzeugt (z.B. timestamp).

Mögl. Werte

Default IMPLIED

Enthalten in Allen Elementen.

Beispiel
[sw-compu-method]
Beschreibung In <sw-compu-method-ref> Verweis auf Umrechnungsformel.

Mögl. Werte

Default REQUIRED

Enthalten in sw-compu-method-ref

Beispiel
[sw-function]
Beschreibung In <sw-function-ref> Verweis auf Funktion

Mögl. Werte

Default REQUIRED

Enthalten in sw-function-ref

Beispiel
[sw-param]
Beschreibung In <sw-param-ref> Verweis auf Parameter.

Mögl. Werte

Default REQUIRED

Enthalten in sw-param-ref

Beispiel
[termodynamic-temperature-expo]
Beschreibung Temperature in kelvin.

Mögl. Werte

Default IMPLIED

Enthalten in sw-unit

Beispiel
[time-expo]
Beschreibung Time in seconds.

Mögl. Werte

Default IMPLIED

Enthalten in si-unit

Beispiel


4. Übersicht Changes

Strukturelle Grundlagen
4. Übersicht Changes

[SSW] MSR DOC Strukturelle Grundlagen Bereich Software


4.1. Übersicht zu Zustand nach Abgleichung mit ASAP

geplant für 26.04.96


4.2. Übersicht zu Zweite Überarbeitung

geplant für 29.04.96


4.3. Übersicht zu Bereinigung

geplant für 03.06.96
Requests zu Bereinigung
Name | Art | Thema | Status | Prio | MT | geplant für | S.
owns | enh | sw-param-ref owns="owns" | OPEN | A 2 |  |  | 5.1. [owns] sw-param-ref owns="owns"
paramunit | enh | Parameterinhalte brauchen eine Maßeinheit | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 5.2. [paramunit] Parameterinhalte brauchen eine Maßeinheit
paramhex | enh | Parameterinhalte auf Integer/HEX/Adressniveau | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 5.3. [paramhex] Parameterinhalte auf Integer/HEX/Adressniveau
paramfunc | enh | Parameterinhalte müssen Funktionen zuordenbar sein | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 5.4. [paramfunc] Parameterinhalte müssen Funktionen zuordenbar sein
kgrhierachie |  | Unterstützung von Kenngrößenhierarchien | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 5.5. [kgrhierachie] Unterstützung von Kenngrößenhierarchien
kgarray | bug | Kenngrößeninhalte für arrays | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 5.6. [kgarray] Kenngrößeninhalte für arrays
sprmref | enh | SW-param-ref in Kenngrößeninhalten semantisch | PASSED vgl. semantische Referenz in |  |  | 4.3. Übersicht zu Bereinigung | 5.7. [sprmref] SW-param-ref in Kenngrößeninhalten semantisch
annot | enh | Notizobjekte | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 5.8. [annot] Notizobjekte
ndim-array | enh | Unterstützung mehrdimensionaler arrays | PASSED abgeschlossen | SW 09 |  |  | 5.9. [ndim-array] Unterstützung mehrdimensionaler arrays
unknown-SW | enh | Behandlung bisher nicht betrachteter Software Parameterformen | REJECTED |  |  |  | 5.10. [unknown-SW] Behandlung bisher nicht betrachteter Software Parameterformen
cleanup-sw-datatypes | enh | SW-Datatypes sollte bereinigt werden | PASSED | 10 |  |  | 5.11. [cleanup-sw-datatypes] SW-Datatypes sollte bereinigt werden
prog-code | enh | prog-code in sw-compu-method | IN-PROCESS abgeschlossen | B1 |  |  | 5.12. [prog-code] prog-code in sw-compu-method
sw-gen-math | enh | sw-compu-generic-math | OPEN H. Rauleder verfolgt diesen Punkt weiter. |  |  |  | 5.13. [sw-gen-math] sw-compu-generic-math
Osek | enh | OSEK-Aspekte | OPEN H. Bless kümmert sich um eine Element-Liste |  |  |  | 5.14. [Osek] OSEK-Aspekte
diagnose | enh | Behandlung von Diagnose/Diagnosestand | OPEN |  |  |  | 5.15. [diagnose] Behandlung von Diagnose/Diagnosestand
literatur | doc | Literaturverzeichnis vervollständigen | OPEN |  |  |  | 5.16. [literatur] Literaturverzeichnis vervollständigen
security | enh | Sicherheitsrelevanz von SW-Funktionen behandeln | OPEN |  |  |  | 5.17. [security] Sicherheitsrelevanz von SW-Funktionen behandeln
glosssar | doc | Glossar abstimmen | OPEN | C1 |  |  | 5.18. [glosssar] Glossar abstimmen
schedule | enh | Beschreibung von zeitlichen Abhängigkeiten | OPEN |  |  | 4.3. Übersicht zu Bereinigung | 5.19. [schedule] Beschreibung von zeitlichen Abhängigkeiten
va-sample |  | Implementierung bei Variablen erweitern | IN-PROCESS abgeschlossen |  |  |  | 5.20. [va-sample] Implementierung bei Variablen erweitern
param-basic |  | Basistyp bei Kenngrößen einführen | IN-PROCESS abgeschlossen |  |  |  | 5.21. [param-basic] Basistyp bei Kenngrößen einführen
msrsw | enh | Root-Element sw in msrsw umbenennen | IN-PROCESS abgeschlossen | C1 |  |  | 5.22. [msrsw] Root-Element sw in msrsw umbenennen
fktvars | enh | Funktionsvariable optional | IN-PROCESS abgeschlossen | C1 |  |  | 5.23. [fktvars] Funktionsvariable optional
label | enh | Platzhalter für Long-name bei param-content einführen | IN-PROCESS | A1 |  |  | 5.24. [label] Platzhalter für Long-name bei param-content einführen
admin-in-pcont |  | Administrative Daten bei Kenngrößeninhalten | PASSED |  |  |  | 5.25. [admin-in-pcont] Administrative Daten bei Kenngrößeninhalten
fref-in-pcont |  | Funktionsreferenz bei Kenngrößeninhalte | OPEN |  |  |  | 5.26. [fref-in-pcont] Funktionsreferenz bei Kenngrößeninhalte
list-adr |  | Listen von Adressierschemas, Ablageschemas und Codesyntaxen. | IN-PROCESS |  |  |  | 5.27. [list-adr] Listen von Adressierschemas, Ablageschemas und Codesyntaxen.
glosopt |  | Glossar optional | OPEN |  |  |  | 5.28. [glosopt] Glossar optional
units |  | Maßeinheiten | OPEN open |  |  |  | 5.29. [units] Maßeinheiten
variables |  | Variable | OPEN open |  |  |  | 5.30. [variables] Variable
Lösungen in Bereinigung
Name | Art | Thema | Status | Prio | MT | aufgetreten in | S.
paramunit | enh | Parameterinhalte brauchen eine Maßeinheit | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 5.2. [paramunit] Parameterinhalte brauchen eine Maßeinheit
paramhex | enh | Parameterinhalte auf Integer/HEX/Adressniveau | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 5.3. [paramhex] Parameterinhalte auf Integer/HEX/Adressniveau
paramfunc | enh | Parameterinhalte müssen Funktionen zuordenbar sein | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 5.4. [paramfunc] Parameterinhalte müssen Funktionen zuordenbar sein
kgrhierachie |  | Unterstützung von Kenngrößenhierarchien | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 5.5. [kgrhierachie] Unterstützung von Kenngrößenhierarchien
kgarray | bug | Kenngrößeninhalte für arrays | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 5.6. [kgarray] Kenngrößeninhalte für arrays
sprmref | enh | SW-param-ref in Kenngrößeninhalten semantisch | PASSED vgl. semantische Referenz in |  |  | 4.3. Übersicht zu Bereinigung | 5.7. [sprmref] SW-param-ref in Kenngrößeninhalten semantisch
annot | enh | Notizobjekte | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 5.8. [annot] Notizobjekte
schedule | enh | Beschreibung von zeitlichen Abhängigkeiten | OPEN |  |  | 4.3. Übersicht zu Bereinigung | 5.19. [schedule] Beschreibung von zeitlichen Abhängigkeiten


5. Changes

Strukturelle Grundlagen
5. Changes

Inhalt dieses Kapitels:
  • 5.1. [owns] sw-param-ref owns="owns"
  • 5.2. [paramunit] Parameterinhalte brauchen eine Maßeinheit
  • 5.3. [paramhex] Parameterinhalte auf Integer/HEX/Adressniveau
  • 5.4. [paramfunc] Parameterinhalte müssen Funktionen zuordenbar sein
  • 5.5. [kgrhierachie] Unterstützung von Kenngrößenhierarchien
  • 5.6. [kgarray] Kenngrößeninhalte für arrays
  • 5.7. [sprmref] SW-param-ref in Kenngrößeninhalten semantisch
  • 5.8. [annot] Notizobjekte
  • 5.9. [ndim-array] Unterstützung mehrdimensionaler arrays
  • 5.10. [unknown-SW] Behandlung bisher nicht betrachteter Software Parameterformen
  • 5.11. [cleanup-sw-datatypes] SW-Datatypes sollte bereinigt werden
  • 5.12. [prog-code] prog-code in sw-compu-method
  • 5.13. [sw-gen-math] sw-compu-generic-math
  • 5.14. [Osek] OSEK-Aspekte
  • 5.15. [diagnose] Behandlung von Diagnose/Diagnosestand
  • 5.16. [literatur] Literaturverzeichnis vervollständigen
  • 5.17. [security] Sicherheitsrelevanz von SW-Funktionen behandeln
  • 5.18. [glosssar] Glossar abstimmen
  • 5.19. [schedule] Beschreibung von zeitlichen Abhängigkeiten
  • 5.20. [va-sample] Implementierung bei Variablen erweitern
  • 5.21. [param-basic] Basistyp bei Kenngrößen einführen
  • 5.22. [msrsw] Root-Element sw in msrsw umbenennen
  • 5.23. [fktvars] Funktionsvariable optional
  • 5.24. [label] Platzhalter für Long-name bei param-content einführen
  • 5.25. [admin-in-pcont] Administrative Daten bei Kenngrößeninhalten
  • 5.26. [fref-in-pcont] Funktionsreferenz bei Kenngrößeninhalte
  • 5.27. [list-adr] Listen von Adressierschemas, Ablageschemas und Codesyntaxen.
  • 5.28. [glosopt] Glossar optional
  • 5.29. [units] Maßeinheiten
  • 5.30. [variables] Variable


5.1. [owns] sw-param-ref owns="owns"

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | Wl | OPEN | A 2 |  | 4.3. Übersicht zu Bereinigung |
Sache | Das Attribut [owns] in <sw-param-ref> muß auch den Wert "owns" zulassen.
Begründung | Sonst bleibt das Attribut implied, was die Verarbeitung erschwert.


5.2. [paramunit] Parameterinhalte brauchen eine Maßeinheit

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | Hünerfeld | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 4.3. Übersicht zu Bereinigung
Sache | Parameterinhalte <sw-param-contents> brauchen Maßeinheiten.
Begründung | Die Parameterinhalte werden verwendet, um physikalische Daten zu dokumentieren wie auch mit anderen Systemen auszutauschen. Bei einem derartigen Austausch ist ggf. nicht das ganze Datenlexikon verfügbar. Daher müssen die Maßeinheiten zumindest optional angebbar sein.
Beschlossene Lösung
Element <sw-unit> einführen.
Anmerkungen


5.3. [paramhex] Parameterinhalte auf Integer/HEX/Adressniveau

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | weichel | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 4.3. Übersicht zu Bereinigung
Sache | Die Parameterinhalte müssen nicht nur als Integergroessen darstellbar sein.
Begründung | Für die Dokumentation ist es sinnvoll, auch integer-Darstellungen wie auch Adressinformationen abzulegen.
Beschlossene Lösung
Die Kinder von <sw-param-content> (<sw-param-content-x> usw.) bekommen für jede Repräsentation (Binäre, Hex, Adresse usw). ein eigenes Element.
Anmerkungen


5.4. [paramfunc] Parameterinhalte müssen Funktionen zuordenbar sein

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | hünerfeld | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 4.3. Übersicht zu Bereinigung
Sache | Die Parameterinhalte sollten Funktionen zuordenbar sein - zumindest optional.
Begründung | Im Autonom-Betrieb kann man eine Funktionsorientierte Datenverwaltung aufsetzen
Beschlossene Lösung
<sw-param-content> bekommt die Möglichkeit, den Inhalt einer Funktion zuzuordnen, d.h. auf eine Funktion zu referenzieren (<sw-function-ref>)
Anmerkungen


5.5. [kgrhierachie] Unterstützung von Kenngrößenhierarchien

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | hünerfeld | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 4.3. Übersicht zu Bereinigung
Sache | Es müssen auch Kenngrößenstrukturen unterstützt werden können.
Begründung | Wenn man Variablenstrukturen bildet, muß das auch für Kenngrößen gehen. Solche Strukturen werden bereits eingesetzt.
Beschlossene Lösung
Rekursive Wiederholung von <sw-params> in <sw-param> können auch Kenngrößenhierarchien dargestellt werden.
Anmerkungen


5.6. [kgarray] Kenngrößeninhalte für arrays

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
bug | Hünerfeld | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 4.3. Übersicht zu Bereinigung
Sache | Kenngrößeninhalte müssen auch für Arrays spezifizierbar sein.
Begründung | Sonst ist die Sache unvollständig
Beschlossene Lösung
<arraysize> wird in <sw-param> eingeführt, ebenso <sw-array-index> in <sw-param-content>.
Anmerkungen


5.7. [sprmref] SW-param-ref in Kenngrößeninhalten semantisch

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | Hünerfeld Weichel | PASSED vgl. semantische Referenz in |  |  | 4.3. Übersicht zu Bereinigung | 4.3. Übersicht zu Bereinigung
Sache
<sw-param-ref> in <sw-param-contents> muß semantisch sein.
Begründung
  • Unterstützung von reinen Kenngrößeninhaltsdateien
  • ein Leser hat ggf. das Datenlexikon nicht zur Verfügung
Beschlossene Lösung
Wird im Rahmen der semantischen Referenzierung allgemein behandelt. Diese wird auf einer Hierarchie von <short-names> beruhen.
Anmerkungen


5.8. [annot] Notizobjekte

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | Hünerfeld | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung | 4.3. Übersicht zu Bereinigung
Sache
Aus dem Datenlexikon bzw. aus den Funktionsdefinitionen sollten Notizobjekte extrahierbar sein, welche in nachgeschalteten Systemen wieder angezeigt werden.
Begründung
Damit kann man aus der Spezifikation heraus Anzeigen in nachgeschalteten Systemen steueren. Solche Systeme können auch Informationen über in die Dokumentation zurückggeben. Diese Notizobjekte müssen vorhanden sein in:
  • Variablen
  • Kenngrößenstrukturen
  • Funktionen
  • Kenngrößeninhalten (Funktionszusammenfassung)
  • Kenngrößeninhalten (einzeln)
Beschlossene Lösung
Die Notizobjekte können in <annotations> angelegt werden.
Anmerkungen


5.9. [ndim-array] Unterstützung mehrdimensionaler arrays

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | ?? | PASSED abgeschlossen | SW 09 |  | 4.3. Übersicht zu Bereinigung 4.3. Übersicht zu Bereinigung |
Sache | Software-Variable sollte auch als mehrdimensionales Array auftreten können.
Begründung | Weil es vorkommen kann.
Beschlossene Lösung
Das Inhaltsmodell von arraysize ist #PCDATA. Bei mehrdimensionalen Arrays werden die Dimensionen als Integerzahlen getrennt durch Leerzeichen eingegeben.


5.10. [unknown-SW] Behandlung bisher nicht betrachteter Software Parameterformen

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | ?? | REJECTED |  |  | 4.3. Übersicht zu Bereinigung 4.3. Übersicht zu Bereinigung |
Sache | Einführung einer "Hintertür" für bislang nicht betrachtete Software-Parameter-Strukturen.
Begründung | Es könnte sein, daß eine Software-Parameterform erfunden wird, welche nicht zu den bisherigen paßt.
Lösungsansatz 1
Einführung einer <ncoi> als weitere Option
Pro | Nutzt vorhandene Elemente. Bietet bei der Erfassung die notwendige Freiheit.
Con | Software-Parameter-Strukturen werden sinnvollerweise nicht nur auf Papier ausgegeben, sondern auch maschinell im Entwicklungsprozeß bearbeitet. Diese wäre mit <NCOI> nicht mehr möglich.
Beschlossene Lösung
Dieser Fall wird zunächst nicht abgedeckt. Die Einführung weiterer Parameterformen hat Auswirkungen auf die gesamte Prozeßkette. Daher wäre es nicht ausreichend, hier eine Hintertür zu eröffenen.


5.11. [cleanup-sw-datatypes] SW-Datatypes sollte bereinigt werden

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | ?? | PASSED | 10 |  | 4.3. Übersicht zu Bereinigung |
Sache | <sw-datatype-scaling> <sw-resolution> sollten bereinigt werden.
Begründung | Diese Elemente scheinen redundant insbesondere bezogen auf <sw-compu-method>
Lösungsansatz 1
Man sollte versuchen, <sw-data-type> und <sw-compu-mehtod> generell zu verschmelzen.
Pro
Damit können weitere Überdeckungen behandelt werden.
Con
  • Es könnte sein, daß zwei gleichartige (d.h. vom gleichen Typ seiende) Variablen mit unterschiedlichen Umrechnungsformeln implementiert werden. In diesem Fall hätte man eine hohe Redundanz bei den Umrechnungsformeln.
  • Vielleicht braucht man mal einen allgemeineren Datentyp als nur einen, der auf Berechungsformeln basiert. In diesem Fall müßte man eine Pseudo-Umrechnungsformeln definieren.
  • Es kann Zwischengrößen geben, welche gar nicht mit Umrechungsformeln versehen werden. In diesem Fall müßte man eine Pseudo-Umrechnungsformel definieren [image] .
Beschlossene Lösung
Die Bereinigung ist ausgeführt. Die Elemente wurden konsequent getrennt nach frühen Phasen (<sw-physic-types> und <sw-varable-implementation>)

nicht der Fall bei Bosch


5.12. [prog-code] prog-code in sw-compu-method

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | AG-SW | IN-PROCESS abgeschlossen | B1 |  | 4.3. Übersicht zu Bereinigung |
Sache | Beschreibung von Umrechnungsformeln in Programiersprachennotation.
Begründung | Immer mehr Verarbeitungswerkzeuge unterstützen die Formulierung von Umrechnungformeln als Programmiersprachenfragment.
Beschlossene Lösung
<prog-code > wird parallel zu <sw-compu-method-text> eingeführt.


5.13. [sw-gen-math] sw-compu-generic-math

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | ?? | OPEN H. Rauleder verfolgt diesen Punkt weiter. |  |  | 4.3. Übersicht zu Bereinigung |
Sache | Auf SGML-Europe-96 wird ein semantisches Mathematik-Modell vorgestellt. Dieses sollte in MSR-DOC verwendet werden.
Begründung | Damit können proprietäre Ansätze überwunden werden.
Lösungsansatz 1


5.14. [Osek] OSEK-Aspekte

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | ?? | OPEN H. Bless kümmert sich um eine Element-Liste |  |  | 4.3. Übersicht zu Bereinigung 4.3. Übersicht zu Bereinigung |
Sache | OSEK-Belange sind ebenfalls in die MSR-DTD bzw. die Strukturellen Grundlagen Software aufzunehmen.
Begründung | Wenn OSEK-konform entwickelt wird, ist es notwendig, eine strukturierte Dokumentation zu haben. Wichtig sind hierbei insbesondere Generierungsparameter usw.
Lösungsansatz 1
Formulierung der Beschreibungssprache in SGML im Rahmen von Medoc.
Pro
Ist sicher konform zu MSR-DOC.
Man könnte mit Hilfe von SGML-Werkzeugen eine Eingabeumgebung realisieren.
Con
  • SGML-Editoren sind nicht notwendigerweise in die Codireungsumgebungen der Software-Entwickler eingebunden. Die OSEK-Anweisungen und Konfigurationsdateien stehen üblicherweise im Quelltext der Steuergeräte-Software (z.B. C-Editor).
Beschlossene Lösung


5.15. [diagnose] Behandlung von Diagnose/Diagnosestand

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | AG | OPEN |  |  | 4.3. Übersicht zu Bereinigung |
Sache | Es ist zu klären, inwieweit die Themen Diagnose und Diagnosestand durch die bisherige Modellierung abgedeckt.
Begründung | AG hat sich bislang nicht intensiv mit Diagnose befaßt.
Beschlossene Lösung


5.16. [literatur] Literaturverzeichnis vervollständigen

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
doc | Rauleder | OPEN |  |  | 4.3. Übersicht zu Bereinigung |
Sache | Das Literaturverzeichnis muß vervollständigt werden.
Begründung |
Beschlossene Lösung


5.17. [security] Sicherheitsrelevanz von SW-Funktionen behandeln

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | AG | OPEN |  |  | 4.3. Übersicht zu Bereinigung |
Sache | Es ist prinzipiell zu klären, wie Aspekte der Sicherheit bzw. Sicherheitsrelevanz bezogen auf Softwarefnktionen und allgemein abgebildet werden soll.
Begründung | Anwendung der msrsw.dtd auch für sicherheitsrelevante Systeme.
Beschlossene Lösung


5.18. [glosssar] Glossar abstimmen

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
doc | AG | OPEN | C1 |  | 4.3. Übersicht zu Bereinigung |
Sache | Das Glossar muß abgestimmt werden.
Begründung | Damit es stimmt.
Beschlossene Lösung


5.19. [schedule] Beschreibung von zeitlichen Abhängigkeiten

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | AG | OPEN |  |  | 4.3. Übersicht zu Bereinigung | 4.3. Übersicht zu Bereinigung
Sache | Die Beschreibungsmittel für zeitliche Abhängigkeiten und Scheduling-Informationen müssen analysiert und eingebaut werden.
Begründung | System und Designtools berücksichtigen zunehmend diese Informationen.
Siehe auch | OTHER: 5.14. [Osek] OSEK-Aspekte
Beschlossene Lösung
Anmerkungen


5.20. [va-sample] Implementierung bei Variablen erweitern

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | RB | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung |
Sache | <sw-variable-sample-rate> auch bei <sw-variable-implementation> aufnehmen.
Begründung | Bei den physikalischen Daten wird ein Minimalforderung angegeben, bei der Implementierung die tatsächliche Realisierung.


5.21. [param-basic] Basistyp bei Kenngrößen einführen

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | RB | IN-PROCESS abgeschlossen |  |  | 4.3. Übersicht zu Bereinigung |
Sache
Bei <sw-param> sollte<sw-base-type> (C-Datentyp) bzgl. des Wertes der Kenngröße optional eingeführt werden.


5.22. [msrsw] Root-Element sw in msrsw umbenennen

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | RB | IN-PROCESS abgeschlossen | C1 |  | 4.3. Übersicht zu Bereinigung |
Sache | Das Root-Element <sw> in <msrsw> umbenennen.
Begründung | Entsprechend allgemeiner Namensvergabe in DTDs.


5.23. [fktvars] Funktionsvariable optional

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | RB | IN-PROCESS abgeschlossen | C1 |  | 4.3. Übersicht zu Bereinigung |
Sache | <sw-function-variables> in <sw-function-variant> optional.
Begründung | Gleichbehandlung wie Kenngrößen.
Beschlossene Lösung
<sw-function-variables> wird optional.


5.24. [label] Platzhalter für Long-name bei param-content einführen

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
enh | RB | IN-PROCESS | A1 |  | 4.3. Übersicht zu Bereinigung |
Sache | Bei <sw-param-contents> und bei <sw-param-content> einen< label>l optional einführen. Der Label entspricht der Langbezeichnung der Funktion.
Begründung | Für die Kalibrierungsphase werden Kenngrößeninhalte ohne Datenlexikon ausgetauscht. Eine Langbezeichnung für die Funkiton ist wünschenswert.
Beschlossene Lösung
Das Element <label> könnte bei Softwareentwicklern zur Verwechslung mit Assembler-Labeln führen. Elemente, die eine Abbildung eines anderen Namen, z.B. eines anderen <long-name> darstellen oder die nur für Layoutzwecke z.B. zur Definition von Navigatoren in Panorama Pro eingeführt werden, sollen durch ein neues Element ausgedrückt werden. Dieses Element heißt <auto-text> .


5.25. [admin-in-pcont] Administrative Daten bei Kenngrößeninhalten

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | RB | PASSED |  |  | 4.3. Übersicht zu Bereinigung |
Sache | <admin-data> bei Kenngrößeninhalten einführen.
Begründung | In der Kalibrierungsphase werden verschiedene Versionenen von Kenngrößeninhalten erzeugt.


5.26. [fref-in-pcont] Funktionsreferenz bei Kenngrößeninhalte

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | RB | OPEN |  |  | 4.3. Übersicht zu Bereinigung |
Sache | Einführung von <sw-function-ref> in<sw-param-content>.
Begründung | Während der Kalibrierungsphase werden Instanzen mit funktionsbezogenen Kenngrößeninhalten ausgetauscht. Dieser Austausch erfolgt projektübergreifend und muß deshalb ohne Datenlexikon [image] erfolgen.

Das Datenlexikon ist in der Regel projektspezifisch.


5.27. [list-adr] Listen von Adressierschemas, Ablageschemas und Codesyntaxen.

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | RB | IN-PROCESS |  |  | 4.3. Übersicht zu Bereinigung |
Sache | Einführung von <sw-addressing-methods>, <sw-code-syntaxes> und <sw- record-layouts> in <sw-data-dictionary>.
Begründung | Normierung und Beschreibung der Objekte, Vorbereitung für Codegenerierung.


5.28. [glosopt] Glossar optional

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | RB | OPEN |  |  | 4.3. Übersicht zu Bereinigung |
Sache | .
Begründung |


5.29. [units] Maßeinheiten

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | RB | OPEN open |  |  | 4.3. Übersicht zu Bereinigung |
Sache | Einführung von Maßeinheiten im< sw-data-dictionary> Formale Referenzierung.
Begründung | Die Maßeinheiten gehen direkt in die Verwendtbarkeit von physikalischen Größen ein und müssen deshalb formal behandelt werden. Normierung der Maßeinheiten.
Lösungsansatz 1
Im Datadictionary werden die verwendeten Maßeinheiten mit Langbezeichnung, Kurzbezeichnung aufgeführt. Falls es sich nicht um eine SI-Einheit handelt, wird auf die entsprechende SI-Einheit verwiesen und die Umrechnung zur bzw. von der SI-Einheit angegeben. Zusätzlich wird eine layoutspezifische Darstellung angegeben. Bei einer SI-Einheit entfällt der Verweis auf eine SI-Einheit und die Umrechnungen. Das Element <sw-unit> wird durch <sw-unit-ref> ersetzt. Siehe folgendes Beispiel.


5.30. [variables] Variable

Art | Vorgeschlagen von | Status | Prio | Tage | Aufgetreten in | Geplant für
 | RB | OPEN open |  |  | 4.3. Übersicht zu Bereinigung |
Sache | Ändern des Inhaltsmodells von Variablen <sw-function-variables>.
Begründung | Bei Variablen muß zwischen der Definition einer Variablen und dem Zugriff auf eine Variable unterschieden werden.
Lösungsansatz 1
Variable, die von einer Funktion definiert werden, werden unter <sw-function-export-variables> aufgeführt. Wenn die Variable nur von der Funktion selbst benützt wird unter <sw-function-local-variables>. Variable, die von der Funktion benutzt bzw. gelesen oder geschrieben werden, aber nicht von der Funktion definiert werden, werden unter <sw-function-import-variables> aufgeführt.
Bezüglich des Zugriffs auf Variablen wird zwischen lesend (<sw-variables-read>), schreibend (<sw-variables-write>) und lesend + schreibend (<sw-variables-readwrite>) unterschieden.


A. Hinweise zum Processing

Strukturelle Grundlagen
A. Hinweise zum Processing

Zu jeder Software-Funktion sollen alle Software-Funktionen aufgelistet werden, die jene aufrufen. Dieser Zusammenhang ist in der obigen Struktur über die Software-Variablen und deren Richtung abgebildet.
In <sw-limits> werden Minimal- und Maximalwerte angegeben für die codierten (Steuergeräte-internen) und die physikalischen Werte. Ein Semanitk-Prüfer sollte die Konsistenz dieser Werte prüfen. Ggf. kann auch in einem nachgeschalteten Prozeß der eine aus dem andereren Wert errechnet werden, wenn dieser in der Lage ist, die Umrechnungsformeln auzuwerten.


B. Erklärung der Near&Far-Symbole

Strukturelle Grundlagen
B. Erklärung der Near&Far-Symbole

Abbildung 22: NearFar-Symbole


C. Glossar

Strukturelle Grundlagen
C. Glossar

Das Glossar enthält einige zentrale Begriffe. Die Erläuterungen nehmen z.T. Bezug auf Begrifflichkeiten innerhalb der MSRSYS.DTD.
add-info, add-spec
Elemente innerhalb der MSRSYS.DTD, die es ermöglichen, neben vorgegebenen Themen/Überschriften zusätzliche Spezifikationen (add-spec) und für Objekte neben der vorgegebenen Beschreibungsstruktur zusätzliche Informationen (add-info) freistrukturiert zu dokumentieren.
ASAP
Die ASAP-Schnittstellen wurden vom "Arbeitskreis zur Standardisierung von Applikationssystemen (ASAP)" vereinbart. Mitglieder dieses Arbeitskreises sind deutsche Automobilhersteller und Firmen der Zuliefererindustrie.
Daten
Inhalte der Software-Parameter (Kenngrößeninhalte)
Datenstand
Festgeschriebene Inhalte der Software-Parameter (Kenngrößeninhalte) zu einem bestimmten Zeitpunkt. Der Datenstand wird durch eine Versionsnummer gekennzeichnet.
Dekomposition
Zerlegung einer Software-Funktion in Unterfunktionen.
Funktion
Unter Funktion versteht man eine bestimmte Anforderung oder Eigenschaft des Gesamtsystems, die entweder durch Hardware, Software oder eine Kombination aus beidem realisiert werden kann.
Funktionsanalyse
Die Funktionsanalyse enthält die Beschreibung des Kontexts, der Funktionen (hierarchisch, inkl. Diagnosefunktionen, Sicherheitsfunktionen etc.) und der Informationsflüsse (informell). Je Funktion werden eine formale Definition, eine informelle Beschreibung, Applikationshinweise und Kundendiensthinweise dokumentiert.
Hardware-Funktion
Funktion innerhalb des Verhaltens, die in Hardware realisiert ist.
Hardware-Modul
Bestandteil einer Hardware-Komponente (Part-Type); ggf. auch die Komponente selbst.
Integration
Phase, in der die einzelnen Module zusammengelinkt werden. Die Integration kann auf der Test- und/oder der Zielumgebung durchgeführt werden.
Logische Funktion
Eine Funktion innerhalb der Verhaltensbeschreibung.
MSRDOCDTD
Innerhalb des Projekts MSR/MEDOC im Standard SGML (ISO 8879) definierte Austauschstruktur.
OSEK
OSEK steht für: "Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug" oder auf englisch: "Open Systems and the Corresponding Interfaces for Automotive Electronics". OSEK ist im Mai 1993 von Firmen der deutschen Automobilindustrie gegründet worden. Gründungspartner waren: BMW, Bosch, Daimler-Benz, Opel, Siemens und VW. Projektkoordinator ist das IIT an der Universität Karlsruhe (Institue of Industrial Information Sytems). 1994 kamen Peugot und Renault mit dem französischen Projekt VDX-approach (Vehicle Distribute eXecutive) hinzu. Es wurden die deutschen und die französichen Projekte in OSEK/VDX zusammengeführt. In OSEK/VDX werden die Themen Betriebssysteme, Kommunikation und Netzwerkmanagement behandelt. Siehe Proceedings of the 1st International Workshop on Open Systems in Automotive Networks
part-type, part
Zentrale Elemente innerhalb der MSRDOCDTD für die Beschreibung der Hardware-Komponentenstruktur.
Processing
Das Processing beschreibt (in dem Dokument "Processing Guide für die MSRDOCDTD") die Prozessierungs- und Layoutdefinitionen für die MSRDOCDTD. D.h. es wird beschrieben, wie eine SGML-Instanz dieser DTD durch einen Formatierer layouttechnisch in ein druckfähiges Dokument umgesetzt wird.
Programm
Ablauffähiger Teil der SoftwareSoftware im Steuergerät. Daten werden separat, also nicht als Bestandteil des Programmes behandelt, da sie in einem eigenen Prozeß entwickelt werden (vgl. 1.2.8. Applikation (Kalibrierung)).
Programmierbarkeit
Eigenschaft einer Komponente (z.B. eines Steuergeräts), die beschreibt, in welcher Form und in welchem Umfang die Komponente programmierbar ist (Bandende-, Offline- und Feldprogrammierbarkeit).
Programmstand
Ausführbarer Code im Steuergerat ohne Daten (Kenngrößen usw.)
Sicht
Die MSRSYS.DTD kann Daten in zwei Sichten (views) aufnehmen: "requirements" und "product-spec".
Software
Lauffähige Software, d.h. Programm und Daten in einem Steuergerät.
Software-Funktion
Eine in Software realisierte FunktionFunktion in einem Steuergerät.
Software-Modul
Eine durch einen Compiler übersetzbare Einheit, die auch mehrere Software-Funktionen umfassen kann.
Softwarestand
Kombination aus ProgrammstandProgrammstand und DatenstandDatenstand
Systemanalyse
In der Systemanalyse wird das System auf logischer Ebene beschrieben. Das entstehende logische Funktionsmodell kann simulierbar sein.
Systemdesign
Beim Systemdesign wird aus dem logischen Funktionsmodell das physikalische Funktionsmodell abgeleitet.


D. Literaturverzeichnis

Strukturelle Grundlagen
D. Literaturverzeichnis

Kurzbezeichnung | Bezeichnung | Stand | Index
OSEK/VDX, ISBN 3-00-000259-6 | Proceedings of the 1st International Workshop on Open Systems in Automotive Networks | October 9, 1995 |


E. Allgemeine Strukturen

Strukturelle Grundlagen
E. Allgemeine Strukturen

In dieser Anlage werden allgemeine Strukturen grafisch dargestellt, die in der MSRSYS.DTD definiert wurden und auch in der Softwaredokumentation verwendet werden oder in die von der Software referenziert wird.


E.1. Administrative Daten

Abbildung 23: Administrative Daten


E.2. Parametermodell

Abbildung 24: Parametermodell
Abbildung 25: ncoi


E.3. Annotations

Abbildung 26: Annotationen


E.4. Zusätzliche Informationen

Erlaubt die Erfassung weiterer Informationen, die über die in der DTD vorgesehene Detaillierung hinausgehen.
Abbildung 27: add-info


E.5. Topics

Abbildung 28: topic-1
Abbildung 29: topic-2


E.6. Namelist

Abbildung 30: locs


E.7. Introduction

In der <introduction> kann eine kurze Einführung zum jeweiligen Objekt gegeben werden. Detaillierte Beschreibungen sollten in <add-spec> untergebracht werden.
Abbildung 31: intro


E.8. SI-Einheiten

STEP (ISO/DIS 10303-41, S96 ff) stützt sich bzgl. SI-Einheiten auf die folgenden sieben Basis-Einheiten ab:
  • lenght (metre),
  • mass (gram),
  • time (second),
  • electric_current (ampere),
  • thermodynamic_temperature (kelvin),
  • amount_of_substance (mole; quantiy; compared to the number of atoms in 0.012 kilogram of carbon 12),
  • luminous_intensity (candela).


E.9. Mehrsprachige Dokumente

Über ein Konfigurationsfile kann die Software-DTD einsprachig oder mehrsprachig benutzt werden. Es wurde nicht für alle Elemente mit PCDATA-Content die Mehrsprachigkeit eingeführt. Elemente, die für die Referenzierung verwendet werden, müssen über Sprachgrenzen hinweg eindeutig sein. Beispiel <short-name>. Ein Beispiel für die Mehrsprachigkeit ist der <long-name>, siehe folgendes Bild und folgendes Beispiel.
Abbildung 32: Beispiel long-name
<sw-variable>
   <long-name>
      <l-5 l="german">Motortemperatur</l-5>
      <l-5 l="english">motor temperature</l-5></long-name>
   <short-name>tmot</short-name>
   . . .
</sw-variable>


F. Zusätzliche Anmerkungen zum Dokumentstand 1.1.0a am 10.7.98

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

Status dieses Dokument: CD


Technische Begriffe

Strukturelle Grundlagen
Technische Begriffe


Organisationen

ASAP | 2.2.3.9. 3.2. C.
california air resource board | 2.2.4.1.
CARB | 2.2.4.1. 2.2.4.1.10.
MSR | 2.2.3.9.


Produkte

ASCET | 3.2.
MSRREP.DTD | 1.2.4. 1.2.6. 1.2.9.
MSRSW.DTD | 1.1. 1.2.3. 2.1.1. 2.1.3. 2.2.4.1.
MSRSYS.DTD | 1.2.3. 2.1.1. 2.2.4.1. 2.2.4.1.3. C.
OSEK | 5.14.


Programmcode

#PCDATA | 5.9.
0x7f2a | 2.2.5.
architecture | 1.2.3.
ASCII | 2.2.3.4.
AXIS_VALUES | 2.2.3.4.
changed | 2.2.3.
CURVE_FIXED | 2.2.3.4.
CURVE_GROUPED | 2.2.3.4.
CURVE_INDIVIDUAL | 2.2.3.4.
MAP_FIXED | 2.2.3.4.
MAP_GROUPED | 2.2.3.4.
MAP_INDIVIDUAL | 2.2.3.4.
not-in-memory | 2.2.3.4.
STRUCT | 2.2.3.3.
STRUCTURE | 2.2.3.4.
SYSTEM_CONSTANT | 2.2.3.4.
VALUE | 2.2.3.4.
VALUE_BLOCK | 2.2.3.4.


SGML Attribute

 | 3.2.
amount-of-substance-exp | 3.3.
amount-ofsubstance-expo | 3.2.
calibration | 2.2.3.3. 2.2.3.4. 3.2. 3.3.
category | 3.2. 3.3.
electric-current-expo | 3.2. 3.3.
ext-id-class | 3.3.
f-child-type | 3.2. 3.3.
f-id-class | 3.2. 3.3.
f-name-space | 3.2.
f-namespace | 3.2. 3.3.
f-pubid | 3.2. 3.3.
fid | 3.2.
filename | 3.2.
fit | 3.2.
height | 3.2.
help-entry | 3.2.
HyNames | 3.2.
HyTime | 3.2.
id | 3.2. 3.3.
idref | 3.3.
interpolation-style | 2.2.3.5. 3.2. 3.3.
lang-subset | 2.2.3.5. 3.2.
length-expo | 3.2. 3.3.
luminous-intensity-expo | 3.2. 3.3.
mass-expo | 3.2. 3.3.
noown | 2.2.4.1.5.
notation | 3.2.
owns | 2.2.4.1. 3.2. 3.3. 5.1.
prog-lang | 2.2.3.5. 3.2.
pubid | 3.2.
role | 3.2.
s | 3.2. 3.3.
scale | 3.2.
sw-addressing-method | 3.2.
sw-code-syntax | 3.2.
sw-compu-method | 3.2. 3.3.
sw-function | 3.2. 3.3.
sw-param | 3.2. 3.3.
sw-physic-type | 3.2.
sw-unit | 3.2.
sw-variable | 3.2.
team-member | 3.2.
termodynamic-temperature-expo | 3.3.
thermodynamic-temperature-expo | 3.2.
time-expo | 3.2. 3.3.
tool | 3.2.
tool-version | 3.2.
type | 2.2.5. 3.2.
used-libs | 2.2.3.5. 3.2.
variant-def | 3.2.
width | 3.2.


SGML Elemente

sw-data-dictionary | 5.29.
label | 5.24.
short-name | 3.2.
sw-param | 3.2.
variant-def-ref | 3.2.
abs | 3.2.
add-info | 1.2.3. 2.2.4.1. 3.2.
add-spec | 2.2. 2.2.7. 3.2. E.7.
admin-data | 2.2. 2.2.3.3. 3.2. 5.25.
annotation | 3.2.
annotations | 2.2.4.1. 3.2. 5.8.
arraysize | 3.2. 5.6.
auto-text | 5.24.
behaviour | 2.1.1.
bit-base-name | 3.2.
bit-base-type | 3.2.
bit-count | 3.2.
bit-pos | 3.2.
change | 3.2.
chapter | 3.2.
cmt-int | 2.2.3.5. 3.2.
cmt-phys | 2.2.3.5. 3.2.
cmt-text | 2.2.3.5. 3.2.
code | 3.2.
coded | 3.2.
coded-max | 3.2.
coded-min | 3.2.
comany-ref | 3.2.
companies | 3.2.
company | 3.2.
company-doc-info | 3.2.
company-doc-infos | 3.2.
company-revision-info | 3.2.
company-revision-infos | 3.2.
company-revison-info | 3.2.
cond | 3.2.
count | 2.2.3.4. 3.2.
data-dictionary | 2.1.6.
date | 3.2.
date-1 | 3.2.
demarcation-other-project | 3.2.
department | 3.2.
desc | 2.2.3. 3.2.
doc-label | 3.2.
doc-revision | 3.2.
doc-revisions | 3.2.
entity-name | 3.2.
figure | 3.2.
file | 3.2.
formula | 3.2.
fulfills-ref | 2.1.6. 2.3.
function-ref | 3.2.
function-view-ref | 2.3.
general-project-data | 3.2.
generic-math | 3.2.
graphic | 3.2.
ie | 3.2.
info | 3.2.
introduction | 2.2. 3.2. E.7.
label | 2.2.3.4. 3.2. 5.24.
labels | 3.2.
language | 3.2.
locs | 2.2. 3.2.
long-name | 2.1.2.2. 2.2.3.1. 3.2. E.9. 5.24.
max | 3.2.
max-count | 2.2.3.4. 3.2.
min | 3.2.
mixed-content-4 | 3.2.
ml-data-1 | 3.2.
ml-data-4 | 3.2.
ml-data2 | 3.2.
ml-graphic | 3.2.
Modification | 3.2.
modifications | 3.2.
msrsw | 2.1.3. 2.1.4. 2.1.6. 2.2.5. 3.2. 5.22.
na | 3.2.
ncoi | 5.10.
ncoi-1 | 3.2.
offset | 2.2.3.4. 3.2.
overall-project | 3.2.
p | 3.2.
part | 2.3.
part-type | 2.3.
part-type-ref | 2.3.
phys | 2.2.3.3.
private-code | 3.2.
private-codes | 3.2.
prm | 3.2.
prm-char | 3.2.
prms | 2.2.4.1.2. 3.2.
product-spec | 2.3.
prog-code | 2.2.3.5. 3.2.
prog-code | 5.12.
project | 3.2.
project-data | 2.2. 2.2.2. 3.2.
reason | 3.2.
requirements | 2.3.
revision-label | 3.2.
sample | 3.2.
sample-spec | 3.2.
schedule | 3.2.
shift | 2.2.3.4. 3.2.
short-name | 2.1.2.2. 2.1.5. 2.2. 2.2.3.1. 2.2.3.3. 3.2. 3.3. E.9.
short-names | 5.7.
si-unit | 2.2.3.1. 3.2.
software | 2.3.
state | 3.2.
std | 3.2.
sw | 5.22.
sw- record-layouts | 5.27.
sw-addressing-method | 3.2.
sw-addressing-method-class | 3.2.
sw-addressing-method-desc | 3.2.
sw-addressing-method-ref | 3.2.
sw-addressing-methods | 3.2. 5.27.
sw-adressing-method-desc | 2.2.3.6.
sw-adressing-method-ref | 2.2.3.6. 2.2.3.8.
sw-adressing-methods | 2.2.3. 2.2.3.6.
sw-application-notes | 2.2.4.1. 2.2.4.1.8. 3.2.
sw-array-index | 3.2. 5.6.
sw-asap-6-prm-method | 2.2.3.1. 2.2.3.5. 3.2.
sw-axis-grouped | 2.2.3.4. 3.2.
sw-axis-individual | 2.1.6. 3.2.
sw-axis-shift-offset | 2.2.3.4. 3.2.
sw-base-type | 3.2. 5.21.
sw-bit-representation | 3.2.
sw-carb-doc | 2.2.4.1. 2.2.4.1.10. 3.2.
sw-code-syntax | 3.2.
sw-code-syntax-class | 3.2.
sw-code-syntax-desc | 2.2.3.8. 3.2.
sw-code-syntax-ref | 3.2.
sw-code-syntaxes | 2.2.3. 2.2.3.8. 3.2. 5.27.
sw-compu-generic-math | 2.2.3.5. 3.2.
sw-compu-mehtod | 5.11.
sw-compu-method | 2.1.2.2. 2.1.6. 2.2.3.9. 3.2. 5.11.
sw-compu-method-ref | 2.1.6. 2.2.3.3. 3.2. 3.3.
sw-compu-method-table | 2.2.3.5. 3.2.
sw-compu-method-text | 2.2.3.5. 3.2. 5.12.
sw-compu-method-text-pair | 2.2.3.5. 3.2.
sw-compu-method-value-pair | 2.2.3.5. 3.2.
sw-compu-methods | 1.2.5. 2.2.3. 2.2.3.5. 3.2.
sw-comput-method-table | 3.2.
sw-data-dictionaries | 1.2.5. 3.2.
sw-data-dictionary | 2.1.6. 3.2. 5.27.
sw-data-dictionary-class | 2.2.3. 3.2.
sw-data-dictionary-spec | 2.2. 2.2.4.1. 3.2.
sw-data-type | 5.11.
sw-data-type-scaling | 3.2.
sw-datadictionary | 2.2.3.
sw-datadictionary-spec | 2.2.3.
sw-datatype-scaling | 5.11.
sw-decomposition | 2.1.6. 2.2.4.1. 2.2.4.1.11. 3.2.
sw-fulfils | 2.1.1. 2.2.4.1. 2.2.4.1.3. 3.2.
sw-fullfils | 3.2.
sw-function | 1.2.3. 2.1.6. 2.3. 3.2.
sw-function-class | 1.2.3. 2.2.4. 3.2.
sw-function-def | 2.2.4.1. 2.2.4.1.1. 2.2.4.1.2. 3.2.
sw-function-desc | 1.2.3. 2.2.4.1. 2.2.4.1.2. 3.2.
sw-function-export-variables | 2.2.4.1.4. 3.2. 5.30.
sw-function-import-variables | 2.2.4.1.4. 3.2. 5.30.
sw-function-local-variables | 2.2.4.1.4. 3.2. 5.30.
sw-function-modelonly-variables | 2.2.4.1.4. 3.2.
sw-function-ref | 2.1.6. 2.2.3. 2.2.5. 2.3. 3.2. 3.3. 5.4. 5.26.
sw-function-refs | 2.2. 2.2.1. 3.2.
sw-function-spec | 2.1.2. 2.2. 2.2.4. 3.2.
sw-function-spec-variant | 2.1.2.1.
sw-function-variables | 2.2.3.3. 2.2.4.1. 2.2.4.1.4. 3.2. 5.23. 5.30.
sw-function-variant | 2.1.2.1. 2.1.2.2. 2.1.3. 2.1.4. 2.1.6. 2.2.4. 2.2.4.1. 2.2.4.1.6. 3.2. 5.23.
sw-function-variants | 3.2.
sw-functions | 3.2.
sw-functions-refs | 3.2.
sw-functions-spec | 3.2.
sw-funtion-variant | 3.2.
sw-glossary | 2.2. 2.2.6. 3.2.
sw-interpolation-method | 3.2.
sw-limits | 2.2.3.3. 3.2. A.
sw-local-variables | 2.1.6.
sw-maintenance-notes | 2.2.4.1. 2.2.4.1.9. 3.2.
sw-param | 2.1.2.1. 2.1.2.2. 2.1.4. 2.1.6. 2.2.3.4. 2.2.3.9. 2.2.4.1.2. 2.2.5. 3.2. 3.3. 5.5. 5.6. 5.21.
sw-param-array-x | 2.2.3.4. 3.2.
sw-param-array-xy | 2.2.3.4. 3.2.
sw-param-axis-value | 2.2.3.4.
sw-param-axis-values | 2.1.6. 3.2.
sw-param-axis-x | 2.2.3.4. 3.2.
sw-param-axis-y | 3.2.
sw-param-class | 2.2.3.4. 2.2.5. 3.1. 3.2.
sw-param-conten-x | 3.2.
sw-param-contens-spec | 2.2.4.1.
sw-param-content | 2.1.2.1. 2.1.4. 2.1.6. 3.2. 5.3. 5.4. 5.6. 5.24. 5.26.
sw-param-content-spec | 2.1.4.
sw-param-content-text | 2.2.5. 3.2.
sw-param-content-v | 2.2.5. 3.2.
sw-param-content-x | 2.2.5. 3.2. 5.3.
sw-param-content-y | 2.2.5. 3.2.
sw-param-contents | 2.1.2. 2.1.2.1. 2.1.4. 2.1.6. 2.2.3.4. 2.2.4.1.6. 2.2.5. 3.2. 5.2. 5.7. 5.24.
sw-param-contents-class | 2.2.5. 3.2.
sw-param-contents-spec | 2.1.2.1. 2.2. 3.2.
sw-param-group-axis | 2.2.3.4. 3.2.
sw-param-noeffect-value | 3.2.
sw-param-record-layout | 2.2.3.7. 3.2.
sw-param-record-layout-class | 3.2.
sw-param-record-layout-desc | 2.2.3.7. 3.2.
sw-param-record-layout-ref | 2.2.3.7.
sw-param-record-layouts | 2.2.3. 3.2.
sw-param-ref | 2.1.4. 2.1.6. 2.2.3.4. 2.2.4.1.5. 2.2.5. 3.2. 3.3. 5.1. 5.7.
sw-param-refs | 2.2.4.1. 2.2.4.1.5. 3.2.
sw-param-single-value | 2.2.3.4. 3.2.
sw-param-target | 3.2.
sw-param-text | 2.2.3.4. 3.2.
sw-param-value-block | 2.2.3.4. 3.2.
sw-param-values-adr | 2.2.5. 3.2.
sw-param-values-coded | 2.2.5. 3.2.
sw-param-values-coded-hex | 2.2.5. 3.2.
sw-param-values-generic | 2.2.5. 3.2.
sw-param-values-phys | 2.2.5. 3.2.
sw-params | 1.2.5. 2.2.3. 2.2.3.4. 3.2. 5.5.
sw-passing-variables | 2.1.6.
sw-physic-type | 3.2.
sw-physic-type-1 | 2.2.3.2. 3.2.
sw-physic-type-contents | 3.2.
sw-physic-type-ref | 2.2.3.2. 3.2.
sw-physic-types | 2.2.3. 2.2.3.2. 3.2. 5.11.
sw-prm | 3.2.
sw-resolution | 3.2. 5.11.
sw-test-spec | 2.2.4.1. 2.2.4.1.7. 3.2.
sw-unit | 2.2.3.1. 2.2.5. 3.2. 5.2. 5.29.
sw-unit-display | 2.2.3.1. 3.2.
sw-unit-from-method | 2.2.3.1.
sw-unit-ref | 2.2.3.1. 3.2. 5.29.
sw-unit-to-ref-method | 2.2.3.1.
sw-units | 2.2.3. 2.2.3.1. 3.2.
sw-var-init-value | 3.2.
sw-var-not-av-value | 2.2.3.3. 3.2.
sw-varable-implementation | 5.11.
sw-variable | 2.1.2.2. 2.1.6. 2.2.3.2. 2.2.3.3. 2.2.3.9. 3.2.
sw-variable-implemenation | 3.2.
sw-variable-implementation | 3.2. 5.20.
sw-variable-kind | 3.2.
sw-variable-read | 2.2.4.1.4.
sw-variable-ref | 2.1.6. 3.2.
sw-variable-sample-rate | 3.2. 5.20.
sw-variables | 1.2.5. 2.2.3. 2.2.3.3. 2.2.4.1.4. 3.2.
sw-variables-read | 3.2. 5.30.
sw-variables-readwrite | 2.2.4.1.4. 3.2. 5.30.
sw-variables-write | 2.2.4.1.4. 3.2. 5.30.
system-ref | 2.3.
tbd | 3.2.
tbr | 3.2.
team-member | 3.2.
team-member-ref | 3.2.
team-members | 3.2.
tol | 3.2.
topic-1 | 3.2.
topic-2 | 3.2.
typ | 3.2.
type | 3.2.
used-languages | 3.2.
v | 3.2.
value | 3.2.
var-def | 3.2.
variant-char | 3.2.
variant-char-value | 3.2.
variant-chars | 3.2.
variant-def | 2.1.6. 3.2.
variant-def-ref | 2.1.2.1. 3.2.
variant-def-refs | 2.1.2.1. 2.2.4.1. 3.2.
variant-defs | 3.2.
variant-spec | 3.2.
xdoc | 3.2.
xfile | 3.2.
xs-param-array-xy | 3.2.


Sonstige

calibration | 3.2.
no-calibration | 2.2.3.4.
not-in-memory | 3.2.
arraysize | 5.9.
calibration | 2.2.3.3. 2.2.3.4. 3.2.
discrete | 3.2.
interpolation | 3.2.
interpolation-style | 3.2.
measurement | 3.2.
nicht verfügbar | 2.2.3.3.
no-calibration | 2.2.3.3. 3.2.
not-in-memory | 2.2.3.3. 2.2.3.4.
record layout | 3.2.
Rohapplikationsdaten | 2.2.5.
Testdaten | 2.2.5.


Werkzeuge

Applikationssystem | 2.2.3.
ASAP | 3.2.
ASAP2 | 2.2.3.9.
Ascet | 1.2.1.
C | 2.2.3.3. 2.2.5.
C-Editor | 5.14.
CASE-Tools | 2.2.4.1.1.
Matrix-X | 1.2.1.
msrsw.dtd | 5.17.
Near&Far | 2.2.
Systementwurfswerkzeug | 2.2.4.1. 2.2.4.1.1.
Verstellysteme | 3.2.
Verstellystemen | 3.2.


Untitled

Review-Inhalte werden nicht modelliert. Man kann MSRREPORT.DTD mit dem Element <changes> auch für Review-Protokolle verwenden.


Untitled

Das Element kann auch Text aufnehmen, weil grundsätzlich keine Elemente als leer definiert wurden. Eventuell vorhandener Text wird ignoriert.


Untitled

Für Arrays kann "_ARRAY" angehängt werden. Bei ASAP ist das in Form von "VALUE_BLOCK_ARRAY" der Fall.


Untitled

"int" steht nicht für "integer" sondern für "intern". Es könnten auch Fließkommazahlen sein.


Untitled

Fehlt dieses Attribut, dann definiert die Funktion diese Kenngröße. In einer späteren Version der DTD wird auch der Wert "own" erlaubt.


Untitled

Hierfür ist muß die DTD geeignet konfiguriert werden.


Untitled

Diese Hierarchien sind mit dem fixen Attribut f-namespace in der DTD begrenzt.


Untitled

dieses Verfahren entspricht der Komponentenstruktur in MSRSYS.DTD


Untitled

Objektorientierte Strukturen sind für eine spätere Version vorgesehen.


Untitled

Die derzeitige Arbeitsweise der Anwender entspricht der ausschließlich implizen Variantenzuordnung.


Untitled

In einer künftigen DTD-Version ist vorgesehen, auch den Wert "owns" zuzulassen, und diesen als Default zu setzen.


Untitled

In einer Pilotanwendung wurde Angabe im "C-Stil" verwendet.


Untitled

Die Umsetzung dieser Referenz wird zurückgestellt bis zur Konzeption eines Requirements Tracing.


Untitled

Das Datenlexikon ist in der Regel projektspezifisch.