GLOSSAR DER SERVICEPLATTFORM TAURUS®

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Begriff

Bedeutung

Abbruchmodell

Über das Abbruchmodell definiert der àServiceautor die Reaktion von àISOM auf Fehler während der Ausführung des àAktionsplans. Für àAktionen zu einzelnen Steuergeräten und für àAusführungsgruppen kann mit àAnnotationen festgelegt werden, ob nach dem Scheitern einer Aktion die nachfolgenden Aktionen ausgeführt oder übersprungen werden sollen.

Abhängige Aktion

àAktionen können in àISOM/L-Programmen als voneinander abhängig gekennzeichnet werden. Dazu wurden die Begriffe bedingende Aktion und abhängige Aktion geprägt. Die Kennzeichnung der Abhängigkeit erfolgt mithilfe von àAnnotationen in ISOM/L.
(Siehe auch
àAbbruchmodell.)

Ablauf

Ein Ablauf beschreibt die Abfolge von Bedienschritten, wie sie vom àServiceautor für die àSoftware-Reparatur definiert und von der àServiceanwendung ausgeführt wird. Die Definition erfolgt im àTaurus® Automatenmodell.

Ablaufautomat

Als Bestandteil des àTaurus® Automatenmodells beschreibt ein Ablaufautomat einen àAblauf in Abhängigkeit von eintreffenden àEreignissen. Hierzu werden àAblaufzustände definiert, in denen die Verarbeitung von Ereignissen sowie der Zusammenhang zwischen den Ablaufzuständen beschrieben wird.

Ablaufzustand

Ein Ablaufzustand definiert das Verhalten der Applikation für einen bestimmten Zustand. Dazu legt der Ablaufzustand die Reaktion auf eingehende àEreignisse fest, z.B. den Aufruf bestimmter àOperationen. In Abhängigkeit vom Ereignis oder Operationsergebnis kann ein Nachfolgezustand festgelegt werden. Einem Ablaufzustand kann ein àDarstellungsautomat zugeordnet sein.

Abschließender Block

Der Kontrollfluss durch Funktionen in àISOM/L kann an vielen Stellen mit „return“ enden oder anderweitig verlassen werden. Ein abschließender Block vermeidet die Vervielfachung von identischen Codeabschnitten mit Anweisungen, die immer vor dem Verlassen einer Funktion ausgeführt werden sollen. Beispiele für diese Anweisungen sind das Erzeugen von Einträgen in der àTaurus® Ereignisaufzeichnung oder im àSitzungsprotokoll.

Aeneas

Aeneas ist der ASAM-D-Server der àServiceplattform Taurus®. Aufgabe von Aeneas ist die Kommunikation mit àSteuergeräten in Fahrzeugen, für die eine Beschreibung im Format ASAM-MCD-2 (ODX) vorliegt. Aeneas stellt dieses Funktionsmerkmal über die Schnittstelle ASAM-MCD-3 zur Verfügung.
(Siehe auch
àASAM-Auftrag, àFasttrack.)

Aggregat

Siehe àZusammengesetztes Steuergerät.

Aktion (BOAM)

Eine Aktion beschreibt im àTaurus® Automatenmodell die Reaktion eines àZustandsautomaten, nachdem ein neuer àZustand erreicht wurde. Ein Beispiel für eine Aktion ist der Aufruf einer Operation aus einer àOperationssammlung. Das Ergebnis der Operation kann anschließend in die Schaltbedingung einer àTransition eingehen, die zu einem neuen Zustandsübergang führen kann.

Aktion (ISOM)

Eine Aktion ist in àISOM eine Datenstruktur im àTherapieplan oder im àAktionsplan, die aus Sicht des Serviceautors eine in sich geschlossene Einheit bildet. Beispiele für Aktionen sind die àFlash-Programmierung und die àCodierung von Steuergeräten. Eine Aktion wird von einer àAusführungsfunktion ausgeführt. Die àIBS abstrahiert Aktionen im Namensraum Isom.Plan.TherapyPlanAction.
(Siehe auch
àEditierbare Aktion, àZusammengesetzte Aktion.)

Aktionsplan

Mit dem Aktionsplan wird in àISOM die Ausführung aller Aktionen modelliert. Insbesondere werden durch den Aktionsplan àAusführungsreihenfolgen und die Möglichkeit nebenläufiger Ausführung beschrieben. Der Aktionsplan besteht aus àAktionsplanphasen, er wird aus einem àTherapieplan erzeugt.

Aktionsplanpfad

Aktionsplanpfade bilden die zweite Gliederungsebene in einer àAktionsplanphase des àAktionsplans. Jeder Pfad ist eindeutig einem àN-Kanal zugeordnet. Die Aktionsplanpfade innerhalb derselben Phase werden deshalb nebenläufig ausgeführt.

Aktionsplanphase

Aktionsplanphasen bilden die erste Gliederungsebene des àAktionsplans. Aktionsplanphasen werden stets nacheinander ausgeführt, sie enthalten àAktionsplanpfade.

Aktor

Ein Aktor setzt die Elemente des Ausgangsvektors u einer àSteuerung in physikalische Größen um. Die Größen beeinflussen das Verhalten der Steuerstrecke.
(Siehe auch
àSensor.)

Annotationen in ISOM/L

Annotationen sind Auszeichnungen im Quelltext eines Programms. In einem àISOM/L-Programm können Funktionen und àNamensräume mit Annotationen ausgezeichnet werden. Sie steuern das Laufzeitverhalten des Programms. Beispiele sind die Definition àabhängiger Aktionen und àeditierbarer Aktionen, Vorgaben zum àAbbruchmodell und das Schärfen von àWächtern. Annotationen können àspezialisiert werden.

Anonymer Namensraum

Ein anonymer Namensraum ist ein in àISOM/L definierter àNamensraum, für den kein Namensraumbezeichner angegeben ist. Der Namensraum enthält Quelltext, der in nicht-anonyme Namensräume àeingefügt werden kann. Durch das Einfügen wird die Anonymität aufgehoben.

Anubis

Anubis ist ein Rahmenwerk zur Automatisierung von àSystemtests. Das Rahmenwerk führt àISOM als Konsolenanwendung aus und startet selbsttätig alle weiteren àTaurus® Programme. Mit Anubis sind auch Testkonstruktionen auf der Basis von àAblaufautomaten möglich, die von der àTaurus® Steuerung interpretiert werden. àPrometheus, Anubis und àVirgo ermöglichen die àkontinuierliche Integration von àServiceanwendungen.
(Siehe auch
àImhotep.)

Anubis-Bedienoberfläche

Die Anubis-Bedienoberfläche ermöglicht Auswahl, Ausführung und Auswertung von àSystemtests. Sie wurde ursprünglich für Systemtests im Testrahmenwerk àAnubis entwickelt, woraus ihre Bezeichnung resultiert. Die Steuerung der Tests erfolgt über eine grafische Bedienoberfläche, die von àPrometheus bereitgestellt wird.

Anwendung

Eine Anwendung ist ein logisch zusammenhängender Teil einer àDistribution, der installiert und aktualisiert werden kann. Der àTaurus® Installer unterstützt die Definition von Anwendungen als neue Teilmenge vorhandener Distributionen, wodurch das insgesamt erforderliche Datenvolumen reduziert werden kann. Diese Fähigkeit wird von den Herausgeberwerkzeugen àMelas zurzeit nicht unterstützt.

Anwendungsrahmen

Mit dem Anwendungsrahmen Argo kann auf der àServiceplattform Taurus® ein Programm erstellt werden, das konfigura­tionsgesteuert einen oder mehrere àFunktionsblöcke einbindet. Der Anwendungsrahmen liefert auf Anfrage die Schnittstelle eines gewünschten Funk­tionsblocks, der entweder intern oder von einem externen àTaurus® Programm bereitgestellt wird.

Argo

Siehe àAnwendungsrahmen.

Argonaut

Das Integrationsprodukt Argonaut ist Gegenstand der àdiskreten Integration von àServiceanwendungen, die auf der àServiceplattform Taurus® fußen. Das Produkt führt àTaurus® Programme mit OEM-spezifischen Komponenten und den àServicedaten von àMandanten in àDistributionen zusammen.

ASAM-Auftrag

Ein ASAM-Auftrag (engl. diagnostic job) beschreibt einen vollständigen Kommunikationsablauf zwischen àServiceanwendung und àSteuergerät, in dessen Rahmen àASAM-Dienste und andere ASAM-Aufträge ausgeführt werden können. Aufträge werden in einer höheren Programmiersprache wie z.B. Java oder C# implementiert und durch Instanzen von SINGLE-ECU-JOB bzw.
MULTIPLE-ECU-JOB beschrieben, falls sie sich auf ein einzelnes Steuergerät bzw. auf eine definierte Menge von Steuergeräten mit unterschiedlichen
àDiagnoseadressen beziehen.

ASAM-Dienst

Ein ASAM-Dienst (engl. diagnostic service) beschreibt eine Diagnoseanfrage und die zugehörige Antwort, die bei der Kommunikation zwischen àServiceanwendung und àSteuergerät als àDiagnosetelegramme ausgetauscht werden. Dienste werden durch Instanzen der Klasse DIAG-SERVICE als Teil der àODX-Daten in XML-Textdateien mit Namen *.odx-d beschrieben.

ASAM-JobConverter

Der D-Server àAeneas fußt auf dem .NET Framework. Die Java-Programme in den àODX-Daten einer àServiceanwendung müssen deshalb vor ihrer Ausführung durch Aeneas in die Common Intermediate Language (CIL) des Rahmenwerks übersetzt werden. Mit dem ASAM-JobConverter kann diese Übersetzung offline erfolgen, d.h. bereits im Prozess der Datenerstellung für eine Serviceanwendung. Das Werkzeug ist mit einer grafischen Bedienoberfläche ausgestattet und Teil von àISOM Didact.

Asterion

Asterion ist ein Produktmerkmal, das die Modellierung des àFehlerspeichers von àSteuergeräten durch àISOM zum Gegenstand hat. Die Modellierung erfolgt unabhängig von OEM und àBordnetzen, sie orientiert sich am Standard ISO 15031-6. Die wesentlichen Elemente von Asterion sind ein àFachdienst, eine XML-Datenbasis und der àNamensraum Isom.Context.Dtc der àIBS.

Attrappe

Eine Attrappe (engl.: mock object) kann das Verhalten eines realen Objekts vortäuschen. Attrappen bilden hierzu die externe Schnittstelle der Klassendefinition nach, die unter Umständen noch nicht implementiert ist und ermöglichen damit frühzeitige und unabhängige Komponententests. Der àNamensraum Isom.Context.MockupFactory der àIBS ermöglicht die Erzeugung von Attrappen für àFachobjekte aus XML-Beschreibungen.

Auriga

Das Autorenwerkzeug Auriga der àServiceplattform Taurus® dient der Analyse und Beseitigung von Fehlerbildern in den àServicedaten. Auriga ermöglicht das Setzen von Haltepunkten und die àEinzelschrittausführung in àISOM/L-Programmen und in àTaurus® Automaten. Auriga kann àereignisdiskrete Modelle als àGrafcet darstellen.

Auriga Live-Client

Das Analysewerkzeug àAuriga steht auch als àLive-System zur Verfügung. Im Rechnernetzwerk können mit diesem Auriga Live-Client (kurz: ALC) Fehlerbilder analysiert werden, ohne einen Rechner durch Installation von Software zu verschmutzen.

Ausführungsfunktion

Ausführungsfunktion ist der Oberbegriff für àISOM/L-Funk­tionen, die eine àAktion ausführen. Die Namen von Ausführungsfunktionen beginnen mit dem Präfix Do gefolgt vom Aktionsnamen. Ausführungsfunktionen werden deshalb umgangssprachlich auch „Do-Funktionen“ genannt.
(Siehe auch
àSofortausführungsfunktion.)

Ausführungsgruppe

Eine Ausführungsgruppe beinhaltet alle àAktionen, die durch denselben Aufruf der Schnittstellenfunktion ExecutePlanAsync durch ein àexternes Ausführungssystem ausgeführt werden. Eine Ausführungsgruppe wird durch Markieren der zugehörigen Aktionen mit einem gemeinsamen Namen definiert (àAnnotation ActionPlanGroup). Alle Aktionen einer Ausführungsgruppe werden in einem gemeinsamen àAktionsplanpfad eingeplant.

Ausführungsreihenfolge

Mit der Ausführungsreihenfolge legen àISOM und der àServiceautor die Reihenfolge der Ausführung von àAktionen im àAktionsplan fest. Bei der Festlegung wird berücksichtigt, dass zwischen Aktionen in nebenläufigen àAktionsplanpfaden keine Reihenfolge definiert sein darf. Stärkstes Kriterium sind die Vorgaben der àISOM/L-Programme, am schwächsten bewertet wird die àEinfügereihenfolge.

Auslösender Namensraum

Siehe àSpezialisierung.

Authentisierung

Mithilfe der Authentisierung personalisiert ein àBediener oder ein Gerät den Zugriff auf eine Ressource oder einen Dienst durch Nachweis seiner Authentizität. Der Anbieter prüft die Authentizität des Klienten, was als Authentifizierung bezeichnet wird. Der gesamte Vorgang aus Authentisierung und erfolgreicher Authentifizierung wird als Autorisierung bezeichnet - der Klient ist zum Zugriff auf die Ressource autorisiert. Ist der Anbieter ein Programm, dann wird das nachfolgende Zusammenwirken von Bediener und Programm als àSitzung bezeichnet.
(Siehe auch
àISecurityProvider, àZertifikat.)

Automat

Ein Automat im Sinn des àTaurus® Automatenmodells ist ein àZustandsautomat, der durch eine XML-Datei beschrieben wird. Diese Datei wird oft vereinfachend ebenfalls als Automat bezeichnet. Im Modell gibt es àAblaufautomaten und àDarstellungsautomaten.

Basisdaten

Die Basisdaten sind eine Teilmenge der àSteuergerätedaten einer àBaureihengruppe. Die Teilmenge ermöglicht die Aufnahme einer àFahrzeugsitzung, die àBaureihenerkennung des Fahrzeugs und die Ermittlung des àIst-Kontexts. Nicht enthalten sind Speicherabbilder zur àFlash-Programmierung, die vom àTaurus® Datentransfer nachgeladen werden können.

Basisfunktion

Wird eine àFachfunktion durch eine àErweiterungsfunktion überschrieben, wird die Funktion, die überschrieben wurde, als Basisfunktion bezeichnet.

Basisklasse

Eine Basisklasse ist der àNamensraum, der den Ausgangspunkt für eine àBasisklassenerweiterung der àISOM/L-Bibliothek für Serviceautoren (IBS) durch den àServiceautor bildet.

Basisklassenerweiterung

Eine Basisklassenerweiterung ist ein àISOM/L-Programm, das die Definition einer àFachklasse der àISOM/L-Bibliothek für Serviceautoren (IBS) um individuelle àErweiterungsfunktionen ergänzt. Die Erweiterung von Basisklassen steht in keinem direkten Zusammenhang mit der Technologie àISOM Extension. Eine Basisklassenerweiterung kann jedoch Funktionen aus Fachklassen verwenden, die mit dieser Technologie implementiert wurden.

Basissteuerung

Als Basissteuerung wird die mit einer Reihe von àOperationssammlungen ausgestattete àTaurus® Steuerung bezeichnet, die als àFunktionsblock im àTaurus® Client arbeitet.

Basisvariante (ASAM)

Basisvarianten von àSteuergeräten werden in den àODX-Daten als Entität BASE-VARIANT beschrieben. Im Gegensatz zur Basisvariante in àISOM ist jedoch keine eindeutige Zuordnung zwischen Basisvariante und Position innerhalb des àBordnetzes gegeben, wodurch i.Allg. weniger Basisvarianten zur Beschreibung des Steuergeräteinventars eines Fahrzeugs erforderlich sind.

Basisvariante (ISOM)

Die Basisvariante eines àSteuergeräts ist aus der Sicht des àISOM-Objektmodells ein Steuergerätename, der den Verbauort eines Steuergeräts in einem àBordnetz eindeutig bezeichnet. Damit steht z.B. die àDiagnoseadresse fest. In einem realen Fahrzeug kann zu einer Basisvariante maximal eine konkrete àSteuergerätevariante verbaut sein. Basisvarianten werden in der àISOM-Fahrzeugbeschreibung modelliert.

Baureihenerkennung

Das selbsttätige Erkennen der àBaureihengruppe eines Fahrzeugs ist ein wichtiges Funktionsmerkmal von àServiceanwendungen auf Basis der àServiceplattform Taurus®. Die Baureihenerkennung ist Gegenstand der Phase 1 einer àFahrzeugsitzung im àISOM-Phasenmodell. Der OEM-spezifische Ablauf wird vom àServiceautor im àEinsprungspunkt ContextIdent implementiert.

Baureihengruppe

Eine Baureihengruppe ist eine Menge von Fahrzeugbaureihen, deren Elemente in den grundlegenden elektrischen und in­formationstechnischen Merkmalen übereinstimmen. Zu diesen Merkmalen zählen z.B. das àBordnetz und das Diagnoseprotokoll sowie das Betriebssystem der àSteuergeräte. Für die àSoftware-Reparatur der Baureihen einer Baureihengruppe werden normalerweise identische àSteuergerätedaten, aber oft individuelle àServicedaten verwendet.

Bediener

Bediener ist eine Rolle in Anwendungsfällen von Software. Die Rolle wird von einem Menschen bekleidet. Die Interaktion zwischen Bediener und Programm wird als Bedienung bezeichnet, sie erfolgt über eine Mensch-Maschine-Schnittstelle (MMS). Die gemeinsame Arbeit von Bediener und Programm wird als àSitzung bezeichnet.
(Siehe auch
àAuthentisierung.)

Bedienoberfläche (BO)

Siehe àTaurus® Bedienoberfläche.

Bedienprotokoll

Das Bedienprotokoll ist die Aufzeichnung der Bedienung einer grafischen Bedienoberfläche in einer Textdatei. Die Aufzeichnung resultiert aus àEreignissen, die der àBediener an der Oberfläche erzeugt. Sie erfolgt aber typischerweise in der Syntax von Befehlen, die ein Kommandozeileninterpreter verarbeiten kann. Das Bedienprotokoll eignet sich deswegen zur Testautomatisierung und zur Reproduktion von àFahrzeugsitzungen im Rahmen der Analyse von àDefektmeldungen.
(Siehe auch
àSitzungsprotokoll.)

Bedingende Aktion

Siehe àAbhängige Aktion.

Bildpunkt

Der Bildpunkt ist die kleinste Einheit, die bei einer Bildschirmdarstellung technisch angesteuert werden kann. Ein Bildpunkt ist die Maßeinheit der àDimension.

Bildschirmmaske

Eine Bildschirmmaske definiert die Bedienelemente in einem Fenster der àTaurus® Bedienoberfläche. Das Erscheinungsbild der Maske wird in einer àDarstellungsdatei festgelegt; die Daten, die die Elemente anzeigen, werden in der àInhaltsdatei festgelegt. Jeder Bildschirmmaske ist ein àDarstellungszustand zugeordnet.

BOAM

Siehe àServicedaten (BOAM).

BOAM-Prüfung

Siehe àPrüfung der Servicedaten (BOAM).

Bordnetz

Moderne Fahrzeuge sind mit internen Netzwerken zur Verteilung von Energie und Daten ausgestattet. Für die àServiceplattform Taurus® ist vor allem das Datenbordnetz von Bedeutung, das deshalb kurz als Bordnetz bezeichnet wird. àSteuergeräte, àAktoren und àSensoren sind über das Bordnetz miteinander verbunden, das in physikalisch getrennte Segmente untergliedert sein kann. Die Kommunikation über Segmentgrenzen hinweg wird dabei von Protokollumsetzern (engl. Gateways) bewerkstelligt.
(Siehe auch
àZugangssteuergerät.)

Bordnetzgeneration

Die Bordnetzgeneration beschreibt die Technologie, die im àBordnetz eines Fahrzeugs eingesetzt wird. Die Technologie zeichnet sich durch mechanische, elektrische und informa­tionstechnische Merkmale aus. Zu letzteren zählt das verwendete Diagnoseprotokoll. Die Bordnetzgeneration wird in der àISOM-Fahrzeugbeschreibung durch das Element VehicleGeneration beschrieben.

Bordnetzsituation

Die Bordnetzsituation beschreibt die statische Struktur des àBordnetzes und eine aktuelle Momentaufnahme des dynamisch veränderlichen Zustands der Bordnetzteilnehmer. Ein Teil dieser Situation ist im àIst-Kontext abgebildet und steht damit in der àIBS in bordnetzübergreifender Syntax und Semantik zur Verfügung.

Bus

Der Bus ist eine mögliche Struktur (Topologie) der Kommuni­kationsverbindung zwischen den àSteuergeräten in einem àBordnetz. In der àISOM-Fahrzeugbeschreibung werden die Topologien durch das Attribut Topology der Entität Bus beschrieben.

Client-Beobachtung

Bei der Client-Beobachtung kann ein beobachtender Bediener die Interaktion eines steuernden Bedieners mit dessen àTaurus® Bedienoberfläche über das Netzwerk hinweg an seiner eigenen àlokalisierten Bedienoberfläche mitverfolgen. Er sieht dabei die Bewegungen und Änderungen des Mauszeigers und aller weiteren Bedienelemente. Das Funktionsmerkmal steht allen àServiceanwendungen der àServiceplattform Taurus® zur Verfügung, ohne dass Anpassungen durch den àServiceautor erforderlich sind.
(Siehe auch
àSitzungsbeobachtung, àBediener.)

Codierung

Die Codierung modifiziert die Firmware eines àSteuergeräts. Im Unterschied zur àFlash-Programmierung, bei der der komplette Zielspeicherbereich im Steuergerät neu geschrieben wird, verändert die Codierung nur einzelne, ausgesuchte Speicherplätze. Der abgelegte Code der Firmware wird von einer Codierung normalerweise nicht verändert.
(Siehe auch
àZwangscodierung.)

Darstellungsautomat

Ein Darstellungsautomat ist ein àZustandsautomat, der den Kausalzusammenhang der möglichen àDarstellungszustände definiert, die einem àAblaufzustand zugeordnet sind.

Darstellungsdatei

Mit der Darstellungsdatei legt der àServiceautor fest, in welcher Form und Anordnung Daten in einer àBildschirmmaske auf der àTaurus® Bedienoberfläche in Bedienelementen dargestellt werden. Der Ursprung der dargestellten Daten wird in der àInhaltsdatei festgelegt. Wiederkehrende Gruppen von Bedienelementen können in Darstellungsbibliotheken zusammengefasst werden.
(Siehe auch
àFeld, àZeigemodus.)

Darstellungszustand

Der Darstellungszustand beschreibt den Zustand einer àBedienoberfläche auf Basis der àServiceplattform Taurus®. Zum Zustand zählen der Inhalt des Hauptfensters sowie Anzahl, Anordnung und Inhalte von möglicherweise zusätzlich zum Hauptfenster geöffneten Dialogfenstern. Den Kausalzusam­menhang zwischen Darstellungszuständen beschreibt der àDarstellungsautomat.

Datenanbieter

Ein Datenanbieter ist ein àFunktionsblock im àAnwendungs­rahmen des àTaurus® DataProcurements. Beispiele sind der PythiaProvider, der Daten über den àTaurus® Verzeich­nisdienst ermittelt, und der WebServiceProvider, mit dem àWeb-Service-Vorlagen verarbeitet werden.

Defektmeldung

Eine Defektmeldung dokumentiert einen Fehler eines Produkts. Der Fehler wurde zuvor vom Produkt durch eine àFehlermeldung angezeigt oder hat sich durch eine unvollständige oder unbefriedigende Lösung einer àServiceaufgabe manifestiert. Das beobachtete Fehlverhalten wird beschrieben und analysiert, die Lösung ausgearbeitet und verifiziert. Der gesamte Vorgang wird in einem System zur Vorgangsverfolgung abgebildet.
(Siehe auch
àBedienprotokoll, àTaurus® Player.)

Delegierbare Funktion

Eine delegierbare Funktion ist ein Teil der Implementierung von àISOM, für den der àServiceautor in àISOM/L eine eigene Implementierung bereitstellen kann. ISOM oder ein àFachdienststellvertreter delegieren den Funktionsaufruf in diesem Fall an àISOM/L-Programme; der im Produkt implementierte Code wird entsprechend durch den ISOM/L-Code ersetzt. Die Delegierung kann je nach Funktion zwingend oder optional sein.

Deltaplan

Ein Deltaplan wird von àISOM berechnet, um im Fall der Anwendung der ànachgelagerten Logistik die Auswirkungen einer àUmrüstung auf den àSoll-Kontext zu ermitteln. Die àAktionen des Deltaplans werden in den vorhandenen àTherapieplan einsortiert.

Diagnose

Die Diagnose (engl. diagnosis) ist das Ergebnis der Untersuchung eines technischen Systems durch eine àDiagnoseanwendung. Das Untersuchungsergebnis ordnet Fehlerbilder (Symptome) einer möglichen Ursache zu und bildet auf diese Weise die Grundlage für eine nachfolgende Fehlerbehebung. Teil der Behebung kann eine àSoftware-Reparatur sein.

Diagnoseadresse

Über die Diagnoseadresse kann ein àSteuergerät im àBordnetz eines Fahrzeugs eindeutig identifiziert werden, z.B. beim Versand von àDiagnosetelegrammen. Die Diagnoseadresse ist in den meisten Fällen als Byte codiert, da die Anzahl von Steuergeräten im Fahrzeug üblicherweise kleiner als 255 ist.

Diagnoseanwendung

Eine Diagnoseanwendung (engl. diagnostics application) ist eine àServiceanwendung, mit der eine àDiagnose der Ursache des Fehlverhaltens eines technischen Systems erstellt werden kann.
(Siehe Darstellung im Taurus® Player.)

Diagnosemodus

àSteuergeräte steuern Funktionen eines àFahrzeugs. Diese Betriebsart der Geräte wird als Fahrmodus bezeichnet. Aus diesem Modus kann durch ausgezeichnete àDiagnosetelegramme in den Diagnosemodus umgeschaltet werden, der z.B. die àFlash-Programmierung unterstützt.
(Siehe auch
àSpeichermodell.)

Diagnosetelegramm

Ein Diagnosetelegramm ist eine Nachricht, die von einem externen Rechner über ein àFahrzeugzugangsgerät an ein àSteuergerät eines Fahrzeugs gesendet oder von dort empfangen wird. Diagnosetelegramme werden z.B. in àASAM-Diensten und in der àVirgo-Steuergerätebeschreibung beschrieben. Die Kommunikation auf der Basis von Diagnosetelegrammen ist ein zentrales Element der àServiceplattform Taurus®.

Differenzdistribution

Eine Differenzdistribution ist eine Zusammenstellung von Dateien zur Verarbeitung durch den àTaurus® Installer, die sich gegenüber einer zugrundeliegenden àDistribution verändert haben. Da die Differenzmenge im Fall von Software-Aktualisierungen häufig klein ist, kann die Differenzdistribution den logistischen Aufwand zur Verteilung von Aktualisierungen senken. Im Gegensatz zur Aktualisierung durch eine vollständige Distribution muss bei Verteilung der Differenzdistribution berücksichtigt werden, dass auf dem Zielsystem auf jeden Fall eine vollständige Installation vorliegen muss.

Dimension

Als Dimension eines Elements der àTaurus® Bedienoberfläche, einer àBildschirmmaske oder des Bildschirms wird die Einteilung der darstellenden Fläche in àBildpunkte bezeichnet.

Direktanbindung

Siehe àFachdienstanbindung.

Diskretes Ereignisorientiertes Dynamisches System (DEDS)

Ein Diskretes Ereignisorientiertes Dynamisches System (kurz: DEDS) ist ein System, dessen àZustände diskreter Natur sind. Die Zustände ändern sich aufgrund von àEreignissen. Zustände können andauern, wodurch eine Systemdynamik entsteht. Die bevorzugte Beschreibungsform für DEDS ist das àPetri-Netz.

Diskrete Integration

Diskrete Integration bezeichnet das geplante Zusammenführen von Änderungen am Quelltext eines Softwareprodukts. Maßnahmen und Auswirkungen der Zusammenführung werden in einem Fachgespräch diskutiert, das als Integrationskonferenz bekannt ist. Die technische Integration der Quelltexte wird von àPrometheus unterstützt. Sie wird durch eine Produktion abgeschlossen, die angekündigt und im Rahmen der Produktionskonferenz vorbereitet wird. Der resultierende Prozess ist im Prozesshandbuch àThemis definiert.
(Siehe auch Abbildung 1 und
àArgonaut.)

Distribution

Eine Distribution ist eine Sammlung von Installationspaketen und beschreibenden Dateien zur Installation oder Aktualisierung von àAnwendungen durch den àTaurus® Installer. Distri­butionen können mit àMelas erzeugt werden.

Durango

Durango ist ein Fahrzeug der Kategorie Plug-In-Hybrid. Es ist Gegenstand von àDiagnoseanwendungen und Anwendungen zur àSoftware-Reparatur und für den àSoftwarekauf. Das Fahrzeug wird auch von àISOM Didact eingesetzt.

Editierbare Aktion

Eine editierbare Aktion ist eine àAktion, die in der Phase der àPlanbearbeitung dem àTherapieplan hinzugefügt werden oder als àSofortaktion unmittelbar ausgeführt werden kann. Editierbare Aktionen werden durch die àAnnotationen EditableAction und EditableEcuAction ausgezeichnet.

Einfügbare Datei

Eine àISOM/L-Quelldatei definiert die àFunktionen eines àNamensraums. Der àServiceautor kann in anderen Dateien enthaltenen Quelltext in die Quelldatei einfügen. Die einfügbare Datei wird wegen ihrer Dateiendung auch als .isi-Datei bezeichnet. Sie definiert in den meisten Fällen einen àanonymen Namensraum.

Einfügereihenfolge

Die Einfügereihenfolge stellt den zeitlichen Ablauf dar, in dem àAktionen zum àTherapieplan hinzugefügt wurden. Die Einfügereihenfolge ist das am schwächsten bewertete Kriterium bei der Berechnung der àAusführungsreihenfolge.

Einzelschrittausführung

Die Einzelschrittausführung ist ein in der Entwicklung von Programmen eingesetztes Hilfsmittel, um den Verlauf eines Programms nachzuvollziehen und zu analysieren. Bei àServiceanwendungen, die auf der àServiceplattform Taurus® basieren, wird zur Einzelschrittausführung das Programm àAuriga eingesetzt.

Einzelstück

Objektbasierte Informationssysteme abstrahieren Merkmale und Verhalten durch die Definition von Klassen. Wenn es von einer Klasse zur selben Zeit nur eine einzige Instanz geben kann, liegt ein Einzelstück vor. In der àIBS werden Einzelstücke durch die Funktion GetInstance referenziert. Ein Beispiel ist die Abstraktion des àAktionsplans durch den Namensraum Isom.Plan.ActionPlan.

Einsprungspunkt

Der Einsprungspunkt ist eine àRückruffunktion, die der àServiceautor in àISOM/L implementiert. Die Funktion wird nach der Durchführung eines Übergangs im àISOM-Phasenmodell von àISOM aufgerufen. Einsprungspunkte können nur im àSpezialisierungskontext „Fahrzeug“ àspezialisiert werden. Die Liste der Einsprungspunkte, die ISOM aufruft, ist im àNamensraum Isom.Global.Processes der àISOM/L-Bibliothek für Serviceautoren (IBS) definiert.

Emulation

àVirgo liest eine àEmulationsbeschreibung und erzeugt daraus die Emulation eines Fahrzeugs. Die Emulation ist ein Programm in Ausführung, das die Merkmale von àBordnetz und àSteuergeräten so realistisch nachbildet, dass die àNachbildung durch die àServiceanwendung nicht von einem Fahrzeug unterschieden werden kann.
(Siehe auch
àHybride Emulation.)

Emulationsbeschreibung

Die Emulationsbeschreibung ist eine Sammlung von XML-Text­dateien, in der die Merkmale eines àBordnetzes und seiner àSteuergeräte beschrieben werden. Beschrieben werden jene Merkmale, die für die àereignisdiskrete àNachbildung der Steuergeräte durch den Fahrzeugemulator àVirgo erforderlich sind. Das zentrale Element der Emulationsbeschreibung ist die àVirgo-Fahrzeugbeschreibung.
(Siehe auch
àHarvester,àMahaf, àPerseus, àVirgoLint.)

Ereignis

Ein Ereignis tritt ein, wenn in einem System oder in dessen Umgebung physikalische Größen bestimmte Werte erreichen oder Uhren ablaufen. Die Werte werden von àSensoren erfasst. Ein Ereignis kann eine Zustandsänderung auslösen, die in einem àDEDS als àTransition modelliert wird. Eine àSteuerung ist echtzeitfähig, wenn Ereignisse schritthaltend mit ihrem Eintreten verarbeitet werden können.

Ereignisdiskretes Modell

Siehe àDiskretes Ereignisorientiertes Dynamisches System (DEDS).

Erweiterungsfunktion

Eine Erweiterungsfunktion dient der àBasisklassenerweiterung. Sie wird in àISOM/L implementiert und in einem àNamensraum des àMandanten bereitgestellt.

Externes
Ausführungssystem

àISOM unterstützt bei der Ausführung eines àAktionsplans die Möglichkeit, eine Gruppe von àAktionen durch eine externe Softwarekomponente ausführen zu lassen, anstatt die in einem àISOM/L-Programm definierten àAusführungsfunktionen der Aktionen aufzurufen. Die Gruppe wird àAusführungsgruppe genannt, die Komponente externes Ausführungssystem.

Fachdienst

Ein Fachdienst ist ein Programm in àServiceanwendungen der àServiceplattform Taurus®. Fachdienste sind fast immer OEM-spezifisch. Sie ermöglichen die Kommunikation mit àSteuergeräten (z.B. àFlash-Programmierung, àCodierung) und die Verwaltung der àLogistik von Hardware und Software im Fahrzeugservice (z.B. Kompatibiltätsaussagen, Teilekatalog).

Fachdienstadapter

Der Fachdienstadapter stellt der àZentralen Fachdienstverwaltung Informationen über die Merkmale eines àFachdienstes zur Verfügung. Adapter werden in der Plattformsprache C# implementiert. Die Liste der Adapter eines àMandanten wird in der Datei ServicesManagerConfig.xml angegeben.

Fachdienstanbindung

Die Fachdienstanbindung von àISOM stellt Mittel zur Kommunikation mit der àZentralen Fachdienstverwaltung zur Verfügung, erzwingt aber nicht deren Verwendung. Der àFachdienststellvertreter entscheidet, ob Hilfsfunktionen zur Ansteuerung der Zentralen Fachdienstverwaltung oder stattdessen direkt fachliche Funktionen einer Bibliothek aufgerufen werden. Letzteres wird als Direktanbindung bezeichnet.

Fachdienstesatz

Ein Fachdienstesatz ist eine gemeinsam verwendbare Menge von àFachdiensten verschiedenen Typs, die einem àlogischen Fahrzeug zugeordnet sind. Mit jedem Wechsel des logischen Fahrzeugs wird auch der Fachdienstesatz gewechselt. Fachdienstesätze werden in der àISOM-Fahrzeugbeschreibung definiert. Verschiedene Fachdienstesätze desselben Fahrzeugs müssen nicht zwingend disjunkt sein, d.h. sie können gemeinsame Elemente enthalten.

Fachdienststellvertreter

Ein Fachdienststellvertreter ist eine Softwarekomponente in àISOM. Stellvertreter implementieren von Taurus® definierte Schnittstellen wie àIVehicleProxy, àILogisticsProxy oder àISecurityProxy mithilfe von àFachdiensten.

Fachfunktion

Eine Fachfunktion ist eine àFunktion, die ein àServiceautor aufrufen kann. Sie wird in einem àNamensraum der àISOM/L-Bibliothek für Serviceautoren (IBS) bereitgestellt.

Fachklasse

Als Fachklasse wird in àISOM ein àNamensraum bezeichnet, wenn mindestens eine seiner Funktionen eine Fassade für eine Implementierung in der àWirtssprache ist. Die meisten Fachklassen können àFachobjekte erzeugen.

Fachobjekt

Ein Fachobjekt ist eine Instanz einer àFachklasse. Das Objekt ist entweder das Ergebnis der Ausführung einer àFachfunktion oder die Instanziierung wird vom àServiceautor durch Aufruf der Funktion Create angewiesen. Von manchen Klassen kann es nur àEinzelstücke geben.

Fahrzeug

Fahrzeuge im Sinne der àServiceplattform Taurus® sind Autos und Motorräder, die über mindestens 1 àSteuergerät verfügen, dessen Software durch àFlash-Programmierung aktualisiert werden kann.

Fahrzeugbeschreibung

Siehe àISOM-Fahrzeugbeschreibung, àVirgo-Fahrzeugbeschreibung.

Fahrzeuggeneration

Die Fahrzeuggeneration ist eine àSpezialisierungsebene von àISOM. In einer Generation werden üblicherweise alle àBaureihengruppen zusammengefasst, die über gleichartige àBordnetze verfügen.

Fahrzeugkontext

Der Fahrzeugkontext ist Teil des àISOM-Objektmodells. Er umfasst alle Informationen über das àBordnetz eines physikalischen Fahrzeugs. Die Informationen stammen aus der àISOM-Fahrzeugbeschreibung und aus der àSteuergeräte-Identifikation. Ein Fahrzeugkontext kann aus mehreren àlogischen Fahrzeugen bestehen. Ausprägungen sind àIst-Kontext und àSoll-Kontext.

Fahrzeugsitzung

Eine Fahrzeugsitzung ist eine àTaurus® Sitzung, die über ein àFahrzeugzugangsgerät mit einem Fahrzeug verbunden ist. Ziel der Fahrzeugsitzung ist die Lösung einer àServiceaufgabe mithilfe der àServicedaten, die der àMandant für die àBaureihengruppe des Fahrzeugs bereithält. Jeder Fahrzeug­sitzung ist eine Instanz von àISOM zugeordnet.
(Siehe auch
àSitzungskonservierung.)

Fahrzeugtherapie

Veraltet, siehe àSoftware-Reparatur.

Fahrzeugzugang

Ein Fahrzeugzugang ist ein externer Kommunikationszugang zum àBordnetz des Fahrzeugs. Beispiele für Fahrzeugzugänge sind K-Leitung, D-CAN, MOST, Ethernet und LTE. Fahrzeugzugänge werden in der àISOM-Fahrzeugbeschreibung als àP-Kanäle beschrieben und vom àFahrzeugzugangsgerät bereitgestellt.

Fahrzeugzugangsgerät

Ein Fahrzeugzugangsgerät (auch: VCI, vehicle communication interface) ist ein elektronisches Gerät, das àFahrzeugzugänge bereitstellt. Beispiele sind das àPass-Thru Tool und das àIFS Communication Interface. Das Fahrzeugzugangsgerät kann auch Teil des Fahrzeugs sein, wie im Fall des LTE-Zugangs zu àDurango. Fahrzeugzugangsgeräte können mit dem àVirgo-Fahrzeugzugang nachgebildet werden.

Fassade

Der Begriff Fassade bezeichnet in àISOM/L die Deklaration einer oder mehrerer àFunktionen in einem àNamensraum, wenn die Funktionen nicht in ISOM/L selbst implementiert sind, sondern eine in der àWirtssprache implementierte àFachklasse beschreiben.

Fasttrack

Fasttrack ist ein àFachdienst zur Fahrzeugkommunikation auf Basis des Standards ASAM, der den D-Server àAeneas verwendet. àISOM kann Fasttrack über die àZentrale Fachdienstverwaltung oder, wie in àISOM Didact, per àDirektanbindung verwenden.

Fehlergeschichte

Die àIBS stellt im Namensraum Isom.Sys.ErrorHistory eine Fehlergeschichte bereit. Die Aufzeichnung enthält alle Fehler, die seit dem letzten Löschen der Fehlergeschichte von àISOM identifiziert wurden. Hierzu zählen vor allem Fehler in Aufrufen an àFachdienste. Die Fehlergeschichte ermöglicht einem àMandanten die Definition fachlich sinnvoller Reaktionen auf Fehlersituationen in seinen àISOM/L-Programmen.

Fehlermeldung

Mit einer Fehlermeldung zeigt ein in Ausführung befindliches Programm einen Fehler an. Die Situation des Fehlers wird durch einen àlokalisierten Hinweistext beschrieben. Der Text kann in einem Dialogfenster angezeigt oder in die Standardfehlerausgabe ausgegeben werden. Fehlermeldungen werden von àTaurus® Programmen grundsätzlich in der àTaurus® Ereignisaufzeichnung protokolliert.
(Siehe auch
àDefektmeldung.)

Fehlerspeicher

Der Fehlerspeicher ist Teil eines àSteuergeräts. In diesem nichtflüchtigen Speicher werden Störungen im Betrieb des Fahrzeugs aufgezeichnet. Diese Fehlerspeichereinträge bilden häufig die Grundlage für die àDiagnose von Fehlerbildern, falls deren Ursache in der Kraftfahrzeugelektronik vermutet wird.
(Siehe auch
àAsterion und Darstellung im Taurus® Player.)

Feld

Ein Feld ist ein strukturgebendes Bedienelement der àTaurus® Bedienoberfläche. Felder können alle Arten von Bedienelementen enthalten, auch andere Felder. Felder werden in àDarstellungsdateien als XML-Elemente panel konfiguriert.

Filterung

Siehe àFilterfunktion.

Filterfunktion

Eine Filterfunktion ist eine àRückruffunktion. Mit der Funktion kann die Planung von àAktionen beeinflusst werden. Sie kann vom àServiceautor in einem àISOM/L-Programm definiert und àspezialisiert werden. Der Bezeichner der Funktion wird von àISOM vorgegeben, er beginnt immer mit dem Wort Filter, gefolgt vom Namen der Aktion. Ein Beispiel ist die Funktion FilterNativePlan, die von àISOM gerufen wird, nachdem der Serviceautor mit der Funktion Isom.Context.FutureVehicle­Context.GeneratePlan der àIBS die Berechnung eines àNativen Therapieplans angewiesen hat.
(Siehe auch
àVirtueller Ist-Kontext.)

Finaler Therapieplan (FTP)

Siehe àTherapieplan.

Firmware

Firmware ist Software, die Teil eines elektronischen Produkts ist, z.B. ist sie im Flash-Speicher von àSteuergeräten enthalten. Die Programme und Daten verantworten die Funktion des Geräts und sind sofort nach dem Einschalten des Geräts verfügbar. Im Gegensatz zu Software, die auf einer Festplatte abgelegt ist, kann Firmware nur mit besonderen Verfahren ausgetauscht werden, z.B. mithilfe der àFlash-Programmierung.

Flash-Programmierung

Flash-Programmierung bezeichnet die Aktualisierung der Flash-Speicher von àSteuergeräten und anderen elektronischen Geräten. Die Flash-Speicher beinhalten i.d.R. die àFirmware. (Siehe auch àSchattenspeicher, àSpeichermodell.)

Formulardaten

Formulardaten werden von àInhaltsdateien zur Befüllung von àBildschirmmasken mit Informationen verwendet. Die Informationen werden technisch von àOperationssammlungen bereitgestellt, die von der fachlichen Quelle abstrahieren. Im Verlauf einer àFahrzeugsitzung ist diese Quelle in den meisten Anwendungsfällen àISOM. Formulardaten können mit dem Werkzeug àAuriga angezeigt und analysiert werden.

Freischaltung

Mit der Freischaltung wird eine Zusatzfunktion eines Geräts oder eines Programms verfügbar. Die Funktion ist in Software implementiert, das Gerät verfügt in den meisten Fällen bereits vor der Freischaltung über die erforderliche Hardware wie z.B. àAktoren und àSensoren. Der Vorgang ermöglicht den Verkauf von Merkmalen über den erstmaligen Erwerb eines Produkts hinaus.
(Siehe auch
àSoftwarekauf, àUmrüstung, àZertifikat.)

Funktion

Der àServiceautor verwendet in seinen àISOM/L-Programmen Funktionen. Diese Funktionen hat er entweder selbst implementiert (àRückruffunktion, àHilfsfunktion, àErweiterungsfunktion) oder sie werden von der àISOM/L-Bibliothek für Serviceautoren (IBS) bereitgestellt.

Funktionsblock

Ein Funktionsblock ist eine in sich geschlossene Softwarekomponente, die in den àAnwendungsrahmen geladen werden kann. Die Funktionalität der Komponente wird mithilfe wohldefinierter Schnittstellen des Anwendungsrahmens über Prozessgrenzen hinweg vom àTaurus® Verzeichnisdienst publiziert.

Funktionsgruppe

Eine Funktionsgruppe setzt sich aus àFachfunktionen zusammen, die alle von mindestens einer, typischerweise aber von mehreren àFachklassen bereitgestellt werden. Ein Beispiel ist die Funktionsgruppe der Iteratoren, zu der die Funktionen Current, HasNext, Next und Reset zählen. Die Gruppe findet sich z.B. in allen Fachklassen, die Listen modellieren.

Geführter Tausch

Beim geführten Tausch erfolgt der Wechsel eines àSteuergeräts innerhalb einer àFahrzeugsitzung. Der Wechsel wird an der Bedienoberfläche von den àServicedaten angewiesen und überwacht, z.B. durch àIdentifikation des neu eingebauten Geräts. Die Sitzung kann für den Tausch auch àkonserviert und zu einem späteren Zeitpunkt wiederaufgenommen werden.

GRAFCET

GRAFCET ist eine grafische Entwurfssprache, mit der das Verhalten von àSteuerungen auf der Grundlage àdiskreter ereignisorientierter dynamischer Systeme (DEDS) beschrieben wird. Die Sprache ist in der Norm DIN EN 60848 beschrieben.

Grafcet

Als Grafcet wird die konkrete Darstellung eines Modells auf Basis der Entwurfssprache àGRAFCET bezeichnet.

Grundraumbezeichner

Der Grundraumbezeichner ist der Teil des Bezeichners eines àNamensraums, der den einfachen Namen der àFachklasse nicht enthält: Der Grundraumbezeichner von Isom.Context.Ecu ist Isom.Context.

Gültigkeitsterm

Gültigkeitsterme können als Teil von àAnnotationen in àISOM/L-Programmen und in der àISOM-Fahrzeugbeschreibung verwendet werden.

Beispiele für die Verwendung in einem
àISOM/L-Programm:

§  Steuerung àeditierbarer Aktionen, z.B. von àUmrüstungen

§  Bedingungen für das Auslösen von àWächtern

§  Beschreibung àabhängiger Aktionen

Beispiele für die Verwendung in einer àISOM-Fahrzeugbeschreibung:

§  Festlegen von àÜberarbeitungsständen

§  Definition von àSteuergerätevarianten

Gültigkeitsterme können àMakros enthalten.

Harvester

Harvester fasst Werkzeuge und Prozesse für den Aufbau einer Bibliothek von àEmulationsbeschreibungen für alle in Kundenhand befindlichen àFahrzeug eines OEM zusammen. Die Beschreibungen werden lokal von àMahaf erzeugt und mit den àSitzungsprotokollen aus der Werkstatt über das Internet an einen zentralen Rechner übertragen. Sie bilden dort die Grundlage für àRetriever.

Herausgeber

Der Herausgeber ist der Erzeuger und Verteiler einer àServiceanwendung. Er erzeugt àDistributionen mit Installa­tionspaketen unter Verwendung von Herausgeberwerkzeugen, die individuell auf seinen Prozess und die Struktur seiner àServicedaten zugeschnitten sind, und verteilt die Pakete in seinem Unternehmen.
(Siehe auch
àMelas.)

Herausgeberkonfiguration

Die Herausgeberkonfiguration ist Teil der àServicedaten. Sie besteht aus Konfigurationsdateien, mit denen der àHerausgeber die Parameter der àTaurus® Programme an die Laufzeitumgebung seiner àServiceanwendung anpassen kann. Beispiele sind àProtokollierungsrichtlinien und die Beschränkung der Anzahl gleichzeitiger àTaurus® Sitzungen.

Hermes

Hermes ist ein àFunktionsblock des àTaurus® Servers. Der Funktionsblock ist eine Komponente der àTaurus® Datenablage.

Heron

Heron ist eine àSteuerung der àServiceplattform Taurus®. Heron verarbeitet Modelle, die in der àkanonischen Beschreibungsform für àereignisdiskrete Systeme vorliegen. Heron ist in àHeron Didact und in àISOM Didact enthalten.

Heron Didact

Das Programmpaket Heron Didact veranschaulicht, wie àHeron Steuerungsmodelle in der àkanonischen Beschreibungsform verarbeitet. Dazu kann mit Beispielmodellen àereignisdiskreter Systeme experimentiert werden, die àAuriga als àGRAFCET darstellt. Elemente von Heron Didact sind neben Heron das Autorenwerkzeug àAuriga, Software-Surrogate für àSensoren und àAktoren sowie didaktisch wertvolle Beispielprogramme.

Hilfsfunktion

Eine Hilfsfunktion wird vom Serviceautor in einem àISOM/L-Programm implementiert. Der Programmierer ist bei der Fest­legung der Signatur der Hilfsfunktion frei, da die Funktion keine àRückruffunktion ist, d.h. sie muss nicht von àISOM erkannt und gerufen werden.

Hybride Emulation

Die hybride Emulation integriert reale Hardware in eine àEmulation. Bei der Hardware handelt es sich z.B. um àSteuergeräte, àSensoren und àAktoren, die über den CAN-Bus oder Ethernet mit dem Emulationsrechner verbunden sind. àVirgo unterstützt hybride Emulationen und umgekehrt auch das Ersetzen von realer Hardware durch Software im àFahrzeug.

Hybridmodus

Im Hybridmodus von àISOM können sowohl in das àisbx-Dateiformat übersetzte als auch in Quelltextform vorliegende àISOM/L-Programme interpretiert werden. Existiert eine Datei in beiden Formen, wird die Quelldatei bevorzugt.

IFS Communication Interface (IFSCI)

Das IFS Communication Interface (IFSCI) ist ein àFahrzeugzugangsgerät, dessen Merkmale an den àBordnetzen und àFahrzeugzugängen elektrisch angetriebener Fahrzeuge ausgerichtet sind. Ein Beispiel ist das Fahrzeug àDurango, das in der Infrastruktur von ePlanet® betrieben wird. Das IFSCI wird im Netzwerk über den àTaurus® Verzeichnisdienst gefunden.
(Siehe auch
àVirgoFahrzeugzugang.)

IFS WebLoader

Der IFS WebLoader ermöglicht die Ausführung des àTaurus® Installers auf der Grundlage der Technologie Microsoft ClickOnce zur komfortablen Bereitstellung von Softwareprodukten aus einer Internet-Quelle. Beispiele für diese Produkte sind àISOM Didact und àTaurus® Player.

Imhotep

Imhotep ist ein Merkmal des Testrahmenwerks àAnubis. Es stellt den Ablauf einer àFahrzeugsitzung aus Sicht des àServiceautors und seiner àISOM/L-Programmen als Ablaufdiagramm dar.

Individualdaten

àSteuergeräte können neben Programmen und Daten auch Individualdaten enthalten, die aus der Individualisierung des Fahrzeugs durch den Fahrer resultieren. Beispiele dieser Daten sind Einträge des Telefon- oder Adressbuchs, Steuergrößen der Spracherkennung oder Parameterwerte der Motorelektronik zur Anpassung an den individuellen Fahrstil. Bei der àSoftware-Reparatur müssen Individualdaten unbedingt erhalten bleiben.

Inhaltsdatei

Mit der Inhaltsdatei legt der àServiceautor fest, mit welchen àFormulardaten eine àBildschirmmaske von der àTaurus® Bedienoberfläche befüllt werden soll, deren Form und Gestaltung in der àDarstellungsdatei festgelegt wurde.

Instanzgebundene Funktion

Eine instanzgebundene Funktion benötigt zur Ausführung interne oder private Objektinformationen und wird in àISOM/L über den Bezeichner eines Objekts referenziert. Sie entspricht damit den nichtstatischen Funktionen oder Instanzmethoden der objektorientierten Programmiersprachen. Die entsprechenden àFunktionen der àIBS sind mit dem Schlüsselwort objectbound gekennzeichnet.
(Siehe auch
àInstanzlose Funktion.)

Instanzlose Funktion

Eine instanzlose Funktion benötigt zur Ausführung keine internen oder privaten Objektinformationen und wird in àISOM/L über den Bezeichner des àNamensraums referenziert. Sie entspricht damit den statischen Funktionen oder Klassenmethoden der objektorientierten Programmiersprachen.
(Siehe auch
àInstanzgebundene Funktion.)

Instrumentierung

Instrumentierung bezeichnet das Ergänzen von Programmen um Merkmale, die für das Lösen der spezifizierten àServiceaufgabe fachlich nicht erforderlich sind. Die Merk­male können jedoch die Analyse von àDefektmeldungen unterstützen oder Informationen zum Laufzeitverhalten (engl.: „profiling“) liefern. Die àIBS unterstützt die Instrumen­tierung mit den àNamensräumen Isom.Sys.RuntimeInfo und Isom.Sys.FunctionInfo, mit denen z.B. die Ausführungsdauer von àFunktionen ermittelt werden kann. Der àTaurus® Installer kann so instrumentiert werden, dass Installationsvorgänge zeitoptimal an die Fähigkeiten der Zielplattform adaptiert werden.

Interaktives Übersetzen

àServiceautoren stehen bei der àLokalisierung von àServiceanwendungen vor der Aufgabe, die Verträglichkeit der Länge übersetzter Texte mit den àDimensionen der entsprechenden Bedienelemente zu gewährleisten. Die àTaurus® Bedienoberfläche ermöglicht interaktives Übersetzen und ggf. sofortiges Verändern von Texten auf der Basis von àISOM/L-Programmen, die Internet-Dienste verwenden, wie z.B. Microsoft Bing. Das Übersetzen kann auch erst im Verlauf einer àFahrzeugsitzung erfolgen.
(Siehe auch
àWeb-Service.)

isbx-Dateiformat

Das isbx-Dateiformat ermöglicht die Zusammenfassung von àSyntaxbäumen in einer einzigen Datei. Motivation ist die Gewährleistung der Integrität der àISOM/L-Programme im Fall einer deaktivierten àSemantikprüfung (ISOM). Eine Datei im isbx-Dateiformat enthält Datensätze, die gemäß Type Length Value (TLV) strukturiert sind (ISO 7816 Teil 6).

Integriertes
Serviceobjektmodell (ISOM)

Das Integrierte Serviceobjektmodell (kurz: ISOM) ist eine zentrale Komponente der àServiceplattform Taurus®. ISOM besteht aus einem àInterpreter für die Programmiersprache àISOM/L und dem àISOM-Objektmodell. ISOM kommuniziert mit Fahrzeug und Logistik über àFachdienststellvertreter.

ISOM/L

ISOM/L ist eine Programmiersprache für die àServiceplattform Taurus®. ISOM/L ermöglicht àServiceautoren eine einfache Beschreibung der Lösung einer àServiceaufgabe auf der Grundlage von àFunktionen. ISOM/L ist objektbasiert und wird durch den àISOM-Interpreter ausgeführt. Die Syntax ist durch eine LL(1)-Grammatik beschrieben.

IsomlDoc

IsomlDoc (sprich: „Isom-Ell-Dok“) ist ein Werkzeug zur Erzeugung von Dokumenten aus den Quelltexten von àISOM/L-Programmen. Die Dokumente enthalten Verknüpfungen zur Beschreibung der àISOM/L-Bibliothek für Serviceautoren (IBS). IsomlDoc erkennt spezifische Merkmale der Sprache ISOM/L wie àAnnotationen, àAktionen mit àSpezialisierungen von àFilterfunktionen, àAusführungsfunktionen und àGültigkeitstermen sowie àBasisklassenerweiterungen.

ISOM/L-Bibliothek für Serviceautoren (IBS)

Die ISOM/L-Bibliothek für Serviceautoren (IBS) ist eine Sammlung von àFachklassen und àFachfunktionen, die àISOM für die Lösung von àServiceaufgaben mithilfe von àISOM/L bereitstellt. Die Bibliothek bildet die Fassade zum àISOM-Objektmodell.

ISOM Didact

ISOM Didact ist ein Produkt, das in die àSoftware-Reparatur von àSteuergeräten mithilfe der àServiceplattform Taurus® und ASAM einführt. Das Produkt unterstützt àServiceautoren beim Erlernen der Programmiersprache àISOM/L, es erleichtert die Einarbeitung in die àISOM/L-Bibliothek für Serviceautoren (IBS) und stellt die Anwendung von àereignisdiskreten Modellen in der àkanonischen Beschreibungsform vor. ISOM Didact beinhaltet auch den Fahrzeugemulator àVirgo und eine àEmulationsbeschreibung des Plug-In-Hybriden àDurango.
(Siehe auch
àDurango, àAeneas, àFasttrack.)

ISOM Extension

ISOM Extension ist eine Technologie der àServiceplattform Taurus®, mit der àISOM um Funktionalität ergänzt werden kann, die spezifisch für einen Mandanten ist. Die erforderlichen àPlattformfunktionen werden in der àWirtssprache, d.h. einer .NET-Plattformsprache wie C#, implementiert und als Fassade einer àFachklasse zur Verwendung in àISOM/L-Programmen bereitgestellt. Die Fachklasse ist für den àServiceautor syntaktisch nicht von einer Fachklasse der àISOM/L-Bibliothek für Serviceautoren (IBS) zu unterscheiden.

ISOM-Fahrzeugbeschreibung

Die ISOM-Fahrzeugbeschreibung beschreibt grundlegende Merkmale des àBordnetzes einer àBaureihengruppe. Die Beschreibung erfolgt in Form einer XML-Datei. àISOM verwendet diese In­formationen zur Konfiguration von àFahrzeugsitzungen, noch bevor Daten aus dem Fahrzeug ausgelesen werden. Die ISOM-Fahrzeugbeschreibung ist Teil der àServicedaten.

ISOM-Interpreter

Der ISOM-Interpreter prüft Syntax und Semantik von àISOM/L-Programmen und führt sie aus. Die Programme können als Quelltext (.is-Datei) oder in Binärform (àisbx-Dateiformat) vorliegen. In einer àServiceanwendung wird der ISOM-Interpreter von der àTaurus® Sitzungsverwaltung gestartet. Nach Start und Initialisierung wird die àRückruffunktion OnIsomStarting gerufen.

ISOM-Objektmodell

Das ISOM-Objektmodell bildet die Merkmale des behandelten Fahrzeugs auf Datenobjekte ab. Die Objekte stehen hinter einer Fassade in der àISOM/L-Bibliothek für Serviceautoren (IBS) zur Verfügung. Ein Beispiel ist die àFachklasse Isom.Context.Ecu, die ein àSteuergerät modelliert.

ISOM-Phasenmodell

Das ISOM-Phasenmodell beschreibt ein bewährtes Verfahren (engl. Best practice) zur Gliederung der àSoftware-Reparatur mithilfe der àServiceplattform Taurus®. Jede der Phasen hat eine wohldefinierte fachliche Bestimmung. Ein Beispiel ist die Berechnung des àTherapieplans. Die Übergänge zwischen den Phasen werden vom àServiceautor durch àISOM-Steuerbefehle ausgelöst. Die Befehle werden im àTaurus® Automatenmodell definiert und von einer àOperationssammlung ausgeführt. Als Folge eines Phasenübergangs werden von àISOM namentlich bekannte àEinsprungspunkte aus àISOM/L-Programmen gerufen.
(Siehe auch Abbildung 2.)

ISOM-Steuerbefehl

Der Verlauf einer àFahrzeugsitzung orientiert sich am àISOM-Phasenmodell. Die Übergänge zwischen den Phasen des Phasenmodells werden durch ISOM-Steuerbefehle ausgelöst, die in der Schnittstelle IIsomController definiert sind. Der àServiceautor setzt die Steuerbefehle im àTaurus® Automatenmodell ein. Sie werden dort von der àOperationssammlung OperationPoolIsom zur Verfügung gestellt.

Ist-Kontext

Der Ist-Kontext ist Teil des àISOM-Objektmodells. Er ist eine Ausprägung des àFahrzeugkontexts und beschreibt die àBordnetzsituation, die auf Basis der àISOM-Fahrzeugbeschreibung aus dem Fahrzeug ausgelesen wurde. Der àServiceautor kann in den Aufbau des Ist-Kontexts durch àSpezialisierung der àEinsprungspunkte UpdateCurrentVehicleData und UpdateCurrentContextEcus eingreifen.
(Siehe auch
àVirtueller Ist-Kontext, àSoll-Kontext.)

IAccessProxy

IAccessProxy ist eine Schnittstelle der àFachdienstanbindung an àISOM. Sie ermöglicht den Zugriff auf die Daten eines àFahrzeugzugangsgeräts (VCI). Hierzu zählen Klemmenspannungen, die verfügbaren àP-Kanäle und auch die Fahrgestellnummer des angeschlossenen Fahrzeugs, falls das VCI zu deren Ermittlung fähig ist. Der àFachdienststellvertreter implementiert die Schnittstelle mithilfe des àTaurus® DataProcurements.

ILogisticsProxy

ILogisticsProxy ist eine Schnittstelle der àFachdienstanbindung an àISOM. Die Schnittstelle definiert Dienste der àLogistik. ISOM ruft Instanzen von Implementierungen dieser Schnittstelle auf, um àSoll-Kontexte zu ermitteln oder um àLogistikpläne zu berechnen.

ISecurityProxy

ISecurityProxy ist eine Schnittstelle der àFachdienstanbindung an àISOM. ISOM ruft Instanzen von Implementierungen dieser Schnittstelle auf, um Sicherheitsfachdienste wie àPalaimon zu nutzen.

ISecurityProvider

ISecurityProvider ist eine Schnittstelle der àServiceplattform Taurus®, die von àSicherheitsanbietern implementiert werden muss. Die Schnittstelle definiert u.a. die Funktionen Authenticate zur àAuthentisierung und GenerateKey zur Erzeugung kryptografischer Schlüssel. Für die Verwaltung einer sicheren Datenablage beschreibt die Schnittstelle die Funktionen RequestKeyStore, CheckKeyStore und ProvideKeyStoreData.

ITaurusPlatform

Siehe àTaurus® DataProcurement.

IVehicleProxy

IVehicleProxy ist eine Schnittstelle der àFachdienstanbindung an àISOM. Die Schnittstelle definiert Dienste der Fahrzeugkommunikation. ISOM ruft Instanzen von Implementierungen dieser Schnittstelle auf, um àSteuergeräte zu identifizieren oder um àAktionen an Fahrzeugen und Steuergeräten durchzuführen.

JobConverter

Siehe àASAM-JobConverter.

Kanalumschaltung

àISOM ruft beim Wechsel des àFachdienstesatzes eine àRückruffunktion aus einem àISOM/L-Programm. In der àFunktion kann der àServiceautor z.B. Anweisungen zur Parametrierung des àFahrzeugzugangsgeräts definieren.

Kanonische
Beschreibungsform (KBF)

Mit der kanonischen Beschreibungsform (KBF) können àDiskrete Ereignisorientierte Dynamische Systeme (DEDS) beschrieben werden. Die Beschreibungsform kann Nebenläufigkeit darstellen und somit auch àPetri-Netze beschreiben. KBF-Modelle liegen als XML-Dateien vor und können von der àSteuerung àHeron verarbeitet werden. àAuriga kann die Modelle als àGrafcet darstellen.
(Siehe auch
Abbildung 3 und KBF-Modell als Grafcet in Abbildung 4.)

Kontextkompatibilität

Eine Komponente ist kontextkompatibel, wenn die Version ihrer Hardware und Software mechanisch, elektrisch, nachrichtentechnisch und algorithmisch einen fehlerfreien Betrieb in der Umgebung der anderen Komponenten eines technischen Systems ermöglicht. Im Falle eines àSteuergeräts wird die Umgebung durch den àIst-Kontext beschrieben. Die Kompatibilitätsaus­sage trifft die àLogistik.
(Siehe auch
àSoftware-Integrationsstand.)

Kontinuierliche Integration

Kontinuierliche Integration bezeichnet das frühzeitige Zusammenführen von Änderungen am Quelltext eines Produkts mit der zuletzt produzierten Version. Die Zusammenführung ist im Gegensatz zur àdiskreten Integration nicht im Voraus geplant, sondern erfolgt auf Initiative der Softwareentwickler. Die àServiceplattform Taurus® unterstützt das Verfahren durch automatische Regressionstests im àAnubis-Rahmenwerk, die von àPrometheus ausgelöst werden können.

Kronos

Mit Kronos können àMandanten und deren àServicedaten über den àTaurus® Client verwaltet werden. Kronos besteht aus einem àAblaufautomaten und àDarstellungsautomaten sowie einer àOperationssammlung.

Live-System

Eine àAnwendung auf Basis der àServiceplattform Taurus® wird als Live-System bezeichnet, wenn eine fehlerfreie Ausführung direkt vom Medium der àDistribution aus möglich ist. Das Medium muss dabei auch schreibgeschützt sein können.
(Siehe auch
àAuriga Live-Client, àTaurus® Player.)

Liste

Eine Liste ist eine Sammlung von Elementen. Sie ist eine Erweiterung der Menge, da Elemente in der Liste mehrfach enthalten sein dürfen. Die àISOM/L-Bibliothek für Serviceautoren (IBS) enthält àFachklassen zur Verwendung von Listen in àISOM/L-Programmen. Die Klassendefinitionen weisen z.T. einen starken fachlichen Bezug auf. Ein Beispiel dafür ist Isom.Context.EcuList, in deren Instanzen nach Elementen mit einer bestimmten àDiagnoseadresse gesucht werden kann.

Logische Einheit

Eine Logische Einheit modelliert im àISOM-Objektmodell eine Hardware- oder Softwarekomponente eines àSteuergeräts. Die Mo­dellierung erfolgte vor dem Hintergrund des Paradigmas von AUTOSAR. Die àIBS stellt hierzu die Fachklasse Isom.Context.LogicalUnit zur Verfügung.

Logischer Kanal (L-Kanal)

àNebenläufige Kanäle unterstützen logische Kanäle. Ein logischer Kanal ist durch Kommunikationsmerkmale charakterisiert, die von den àServicedaten eingestellt werden können. Durch Einschränkung der möglichen L-Kanäle werden Einschränkungen bzgl. der möglichen Kanäle angegeben, über die eine àAktion ausgeführt werden kann. Diese Einschränkung kann sowohl von der àLogistik als auch vom àServiceautor kommen.

Logischer Kontext

Ein logischer Kontext ist ein àFahrzeugkontext, der nur Elemente eines einzelnen àlogischen Fahrzeugs umfasst. àISOM verwendet logische Kontexte in den Schnittstellen für àFachdienststellvertreter. Damit wird vermieden, dass ein àFachdienst Zugriff auf Daten erhält, für die andere Fachdienste zuständig sind.

Logisches Fahrzeug

Logische Fahrzeuge sind Teil der àISOM-Fahrzeugbeschreibung. Sie ermöglichen die Definition von Teilen des àBordnetzes, die jeweils disjunkte Teilmengen der àSteuergeräte eines Fahrzeugs umfassen. Jede Menge kann über eigene àFachdienstesätze und àexterne Ausführungssysteme verfügen. Dem àServiceautor vermittelt àISOM trotz dieser Heterogenität eine zusammenfassende Sicht des Fahrzeugs im àISOM-Objektmodell. Hierzu zählen z.B. der àIst-Kontext oder der àTherapieplan.

Logistik

Als Logistik wird eine Softwarekomponente bezeichnet, mit der die Schnittstelle àILogisticsProxy implementiert werden kann. Die Komponente gewährleistet die àKontextkompatibilität. Eine zustandsfreie Logistik erzeugt einen àLogistikplan, speichert ihn aber nicht. Eine zustandsbehaftete Logistik speichert den Plan und erlaubt die Aktualisierung von außen. Bei der Verwendung der zustandsbehafteten Logistik durch àISOM ist ein àPlanabgleich notwendig.

Logistikplan

Der Logistikplan wird von àISOM unmittelbar nach der Ermittlung des àIst-Kontextes berechnet. Er enthält àAktionen, die von der OEM-spezifischen àLogistik zur Herstellung der àKontextkompatibilität des Fahrzeugs vorgegeben werden. Die Aktionen des Logistikplans wurden noch nicht vom àServiceautor àgefiltert.

Lokaler
Ereignisaufzeichner

Der Lokale Ereignisaufzeichner (kurz: LEA) ist eine Bibliothek, die Teil der àTaurus® Ereignisaufzeichnung ist. Sie wird von àTaurus® Programmen eingebunden, die mit ihrer Hilfe àEreignisse vom àZentralen Ereignisaufzeichner protokollieren lassen. Bei fehlender oder gestörter Verbindung zum ZEA werden die Ereignisse lokal aufgezeichnet.

Lokalisierung

Lokalisierung bezeichnet den Vorgang der Anpassung von Produkten an regionsspezifische Anforderungen. Zu dieser Anpassung zählen neben der Übersetzung von Texten zur Anzeige auf der àTaurus® Bedienoberfläche in eine landesübliche Verkehrssprache u.a. die kulturabhängige Formatierung von Datum und Uhrzeit und die Verwendung von Maßeinheiten. Die Zeichencodierung in àTaurus® Programmen erfolgt durchgängig in UTF-8, sodass auch komplexe Zeichen referenziert werden können.
(Siehe auch
àInteraktives Übersetzen.)

Mahaf

Mahaf hat die Erzeugung von àEmulationsbeschreibungen im Verlauf einer àFahrzeugsitzung zum Gegenstand. Der àServiceautor kann den Vorgang in den àServicedaten (BOAM) oder durch àISOM/L-Programme steuern. Mit Mahaf kann eine Emulationsbibliothek der im Service behandelten àFahrzeuge aufgebaut werden, die es ermöglicht, die Werkstattzeiten und Kosten von àSoftware-Reparaturen a priori zu ermitteln.

Makro

Mit Makros können Lesbarkeit und Wartbarkeit von àGültigkeitstermen verbessert werden. Die Definition erfolgt über die àAnnotation ContextTerm.

Mandant

Der Mandant bezeichnet eine organisatorisch abgeschlossene Einheit von àServicedaten. Zur Lösung von àServiceaufgaben verfügt der Mandant über alle Daten, die für die Durchführung einer àFahrzeugsitzung erforderlich sind. Die àServiceplattform Taurus® unterstützt den Mehrmandantenbetrieb.

Maske

Siehe àBildschirmmaske.

Maßnahmensteigerung

Scheitert eine àAktion im Verlauf der Ausführung eines àAktionsplans, kann der àServiceautor besondere Maßnahmen ergreifen. Im einfachsten Fall besteht diese Maßnahmensteigerung darin, die zuvor gescheiterte Aktion zu wiederholen.
(Siehe auch
àZwangsprogrammierung.)

Melas

Melas ist der Name der OEM-übergreifenden Herausgeberwerkzeuge für àHerausgeber von àAnwendungen der àServiceplattform Taurus®. Mit Melas können àTaurus® Programme, àServicedaten und àSteuergerätedaten geprüft, importiert und zu àDistributionen verpackt werden.

Mischbordnetz

Ein Mischbordnetz ist ein àBordnetz, das aus àTeilbordnetzen unterschiedlicher àFahrzeuggenerationen heterogen aufgebaut ist. Die Teilbordnetze verfügen dabei jeweils über einen eigenen àFahrzeugzugang und werden als àlogische Fahrzeuge modelliert.

Mock-Objekt

Siehe àAttrappe.

Nachbildung

Eine Nachbildung ist eine Softwarekomponente, die das Verhalten anderer Software oder das von realer Hardware nachbildet. Grundlage der Nachbildung ist in den meisten Fällen ein àereignisdiskretes Modell, das unabdingbar ist, wenn der nachgebildete Gegenstand über einen internen àZustand verfügt. Beispiele für Nachbildungen sind àAttrappen und die àEmulation eines àSteuergeräts durch àVirgo.

Nachgelagerte Logistik

Bei der nachgelagerten Logistik erfolgt die Überprüfung der àKontextkompatibilität einer àAktion nicht unmittelbar nach dem Hinzufügen der Aktion zum àTherapieplan, sondern erst bei der Berechnung des finalen àTherapieplans. Dieser Einsatz der Logistik ist in àISOM voreingestellt.
(Siehe auch
àSchritthaltende Logistik und àDeltaplan.)

Nachladen

Das Nachladen von àSteuergerätedaten aus einer zentralen Quelle zur Laufzeit einer àServiceanwendung ist eine verzögerte Form des àRüstens (engl. deferred provisioning). Die Vorgehensweise reduziert den erforderlichen Umfang der lokalen Datenhaltung auf dem Werkstattrechner und vereinfacht die Gewährleistung der Verwendung von aktuellen und unbeschädigten Daten im Rahmen der àSoftware-Reparatur. Das Nachladen wird vom àTaurus® Datentransfer unterstützt und vom àServiceautor mithilfe der àFachfunktion Isom.Plan.TherapyPlan.GetMissingFiles gesteuert.
(Siehe auch
àLogische Einheit.)

Namensraum

Ein Namensraum ist eine Sammlung von àFunktionen. Die Funk­tionen eines Namensraums werden vom Programmierer in àISOM/L definiert oder von einer àFachklasse – z.B. aus der àISOM/L-Bibliothek für Serviceautoren (IBS) – bereitgestellt. Ein Namensraum kann in einem übergeordneten Namensraum enthalten sein, wobei der oberste Namensraum in der Datei Specialization.xml im Element RootNamespace definiert ist.
(Siehe auch
àAnonymer Namensraum, àSpezialisierung.)

Nativer Therapieplan (NTP)

Der unmittelbar nach der àSteuergeräte-Identifikation und der Ermittlung des àSoll-Kontexts ermittelte àTherapieplan wird als nativer Therapieplan (NTP) bezeichnet. Der native Therapieplan führt zu einem einheitlichen àSoftware-Integrationsstand des Fahrzeugs, der von der àLogistik vorgegeben wird. Der Plan enthält noch keine àAktionen, die vom Servicepersonal manuell hinzugefügt wurden, und es wurden auch noch keine Aktionen manuell entfernt.

Nebenläufiger Kanal
(N-Kanal)

Ein nebenläufiger Kanal (N-Kanal) bezeichnet einen neben­läufig nutzbaren àFahrzeugzugang. Ein N-Kanal ist einem àAktionsplanpfad zugeordnet.

ODX-Daten

ODX-Daten definieren àASAM-Dienste und àASAM-Aufträge für die àSoftwarereparatur von àSteuergeräten gemäß Standard Open Diagnostic Data Exchange (ODX). Die Daten sind Teil der àSteuergerätedaten einer àBaureihengruppe. Zu den Daten zählen XML-Textdateien und Programm-Bibliotheken, deren Funktionen in Auftragsdefinitionen referenziert werden können.

OEM-Funktion

Die OEM-Funktion ist eine zusätzliche Funktion eines àFachdienstes, deren Semantik nicht durch die Schnittstelle festgelegt ist. Die Funktion kann im àISOM/L-Programm mittels RunProcess über ein Objekt aufgerufen werden, das entweder ein àSteuergerät oder einen àFahrzeugkontext modelliert. OEM-Funktionen werden in der àISOM-Fahrzeugbeschreibung beschrieben.

Operationssammlung

Eine Operationssammlung ist eine Software-Bibliothek, die von der àTaurus® Steuerung zur Laufzeit geladen wird. Die àTaurus® Steuerung und ein entsprechender Satz von Operationssammlungen bilden zusammen die àServerseitige Client-Steuerung und die àBasissteuerung. Operationssammlungen enthalten Operationen, die von der jeweiligen Steuerung technisch als Funktionen aufgerufen werden. Die Festlegung dieser Aufrufe erfolgt im àTaurus® Automatenmodell. Aus der Sicht des Modells stellen die Operationen àAktoren dar.

Palaimon

Palaimon ist ein àFachdienst, der Funktionen aus den Bereichen Sicherheit und Kryptografie anbietet. Der zugehörige àFachdienststellvertreter implementiert die Schnittstelle àISecurityProxy. Die Funktionen von Palaimon werden von àSicherheitsanbietern bereitgestellt.

Pass-Thru Tool (PTT)

Das Pass-Thru Tool (PTT) ist ein àFahrzeugzugangsgerät gemäß Standard SAE J2534. PTT können vom àVirgo-Fahrzeugzugang nachgebildet werden. Hierzu wird der Gerätetreiber VirgoPttDriver im Schlüssel HKLM\SOFTWARE\PassThruSupport.04.04\ der Windows-Registratur eingetragen, sodass D-Server wie àAeneas über àDiagnosetelegramme kommunizieren können. Der Treiber und die àNachbildung tauschen die Telegramme mithilfe von àSOAP aus.

Perseus

Perseus ist ein Programm zur Erzeugung und Bearbeitung von XML-Dateien der àServiceplattform Taurus®, für die eine Schemadefinition vorliegt. Ein Bespiel für diese Dateien sind àEmulationsbeschreibungen.

Petri-Netz

Das Petri-Netz ist ein Graph, der ein àDEDS modelliert. Der Graph besteht aus Stellen, Transitionen und gerichteten Kanten, mit denen eine Flussrelation zwischen Stellen und Transitionen definiert wird. Steuerungstechnisch interpretierte Petri-Netze können in der àkanonischen Beschreibungsform beschrieben werden. Eine Sonderform des Petri-Netzes ist der àZustandsautomat.

Phasenbruch

Ein Phasenbruch findet bei der Berechnung des àAktionsplans aus dem àTherapieplan statt, wenn eigentlich mögliche nebenläufige àAktionsplanpfade durch die àServicedaten ausgeschlossen werden. Die unverträglichen Pfade werden in aufeinanderfolgenden Phasen eingeplant.

Phasenmodell

Siehe àISOM-Phasenmodell.

Physikalischer Kanal
(P-Kanal)

Ein P-Kanal definiert in der àISOM-Fahrzeugbeschreibung einen physikalischen Kommunikationskanal des àFahrzeugzugangs.

Planabgleich

Der Planabgleich ist ein Mechanismus in àISOM, der bei zustandsbehafteter àLogistik oder Verwendung àexterner Ausführungssysteme dafür sorgt, dass genau die vom àServiceautor geplanten àAktionen mit Logistikinformationen versehen und ausgeführt werden. Dabei gilt das Paradigma „Der ISOM-Plan gewinnt.

Planbearbeitung

Für die àSoftware-Reparatur berechnet eine àServiceanwendung einen àNativen Therapieplans, der die Software eines Fahrzeugs auf einen einheitlichen àSoftware-Integrationsstand bringt. Die Planbearbeitung ermöglicht dem àBediener der àServiceanwendung das Entfernen von berechneten àAktionen und das Hinzufügen àeditierbarer Aktionen über die àTaurus® Bedienoberfläche.
(Siehe auch
àVirtueller Ist-Kontext.)

Plattformfunktion

Plattformfunktionen sind ein Teil der Technologie àISOM Extension. Sie werden in einer Plattformsprache des .NET Frameworks wie z.B. C# implementiert und mit einem àNamensraum als Fassade zur Verwendung in àISOM/L-Programmen bereitgestellt.

Programmiersegment

Ein Programmiersegment ist ein Bereich des Speichers eines àSteuergeräts, der im Zuge der àFlash-Programmierung aktualisiert wird. Das gesamte àSpeicherabbild  der Aktualisierung besteht aus mehreren Segmenten, die nicht gleich groß sein und auch nicht immer direkt aufeinanderfolgen müssen. Programmiersegmente werden vom àSpeichermodell unterstützt.

Programmierzeitprognose

Die Programmierzeitprognose (kurz: PZP) wird während der àFahrzeugsitzung erstellt und steht zur Verfügung, sobald der àTherapieplan berechnet ist. Sie prognostiziert die Dauer der Ausführung des resultierenden àAktionsplans. Für die Erstellung der Prognose wird ein àAblaufautomat verwendet.

Prometheus

Prometheus unterstützt die Entwicklung und Wartung von Software gemäß Prozessdefinition àThemis. Das Programm verknüpft Systeme zur Vorgangsverfolgung (z.B. Bugzilla) und Versionsverwaltung (z.B. CVS, SVN) mit der Dateiablage und einem Wiki. Das vorgangsgesteuerte Einbuchen und Abholen von Quelltexten sowie die automatische Ausführung von àAnubis-Tests ermöglichen die àkontinuierliche Integration einer àServiceanwendung.
(Siehe auch
àRisikoanalyse, àAnubis-Bedienoberfläche.)

Protokollierungs­richtlinie

Eine Protokollierungsrichtlinie ist eine XML-Datei, die Einstellungen für die àProtokollierungstiefen von àTaurus® Programmen zusammenfasst. Protokollierungsrichtlinien sind Teil der àHerausgeberkonfiguration.

Protokollierungstiefe

Die Protokollierungstiefe gibt vor, ab welcher Wichtigkeit àEreignisse von der àTaurus® Ereignisaufzeichnung aufgezeichnet werden. Ein Absenken der Schwelle vergrößert den Umfang der Aufzeichnung und kann die Analyse von àDefektmeldungen unterstützen. Unabhängig von der eingestellten Tiefe werden bei der Aufzeichnung eines Fehlers die zuvor unterdrückten Ereignisse ebenfalls protokolliert.

Prüfung der ISOM-Fahrzeugbeschreibung (PIF)  

Beim Starten von àISOM werden durch die Prüfung der ISOM-Fahrzeugbeschreibung (kurz: PIF) Syntax und Semantik aller àISOM-Fahrzeugbeschreibungen des gewählten àMandanten geprüft. Nach der Konformität zum XML-Schema der Fahrzeugbeschreibung wird die Einhaltung der Regeln geprüft, die in der Datei ModelCheckerRuleSet.xml angegeben sind.

Prüfung der Servicedaten (BOAM)

Die Prüfung der àServicedaten (BOAM) (kurz: BOAM-Prüfung) sichert die Korrektheit von àTaurus® Automatenmodell, àDarstellungsdateien und àInhaltsdateien zu. Die Prüfung erfolgt durch Anwendung des sogenannten XPathMappings, bei dem XPath-Ausdrücke dateiübergreifend formuliert werden können. Neben Beziehungen zwischen verknüpften XML-Dateien können auch Verweise auf Elemente des Dateisystems beschrieben werden, bei denen es sich nicht zwingendermaßen um XML-Dokumente handeln muss.

Pythia

Siehe àTaurus® Verzeichnisdienst.

Quickstep

Siehe àTaurus® Quickstep.

Referenzsteuergerät

Steuergeräte, die gleichzeitig an mehrere àFahrzeugbusse angeschlossen sind, werden genau einmal als Referenzsteuer­gerät im àTaurus® Steuergerätebaum dargestellt. An allen weiteren Bussen, an denen sie ebenfalls angeschlossen sind, werden sie als àSteuergeräteverweis angezeigt.

Reparaturplan

Der Reparaturplan ist eine Sonderform des àTherapieplans, der die àSoftware-Reparatur einiger weniger àSteuergeräte zum Gegenstand hat. Der Reparaturplan durchläuft nicht die üblichen Phasen des àISOM-Phasenmodells, sondern wird in einem àISOM/L-Programm manuell zusammengestellt. Häufigster Anwendungsfall ist die Reparatur des àZugangssteuergeräts.

Retriever

Retriever beschreibt eine verteilte Anordnung von àTaurus® Programmen und àServicedaten, mit der ein àFahrzeug ohne lokale àLogistik im Rahmen einer àSoftware-Reparatur auf einen neuen àSoftware-Integrationsstand gebracht werden kann. Die erforderlichen àAktionspläne werden in der àTaurus® Cloud nach der Freigabe neuer àSteuergerätedaten zentral an àEmulationen aller im Einsatz befindlichen Fahrzeuge ermittelt und als àWeb-Service bereitgestellt. Die erstmalige Erstellung der àEmulationsbeschreibung eines Fahrzeugs kann z.B. im Rahmen seiner àWerksprogrammierung erfolgen.
(Siehe auch
àHarvester, àSitzungskonservierung.)

Risikoanalyse

Eine Risikoanalyse schätzt die Auswirkungen der Änderung einer àServiceanwendung ab. Die Grundlage bilden die Anwendungsfälle und Grundfunktionen, die in àPrometheus mit der Funktion Failure Mode and Effects Analysis (FMEA) erfasst und mit Quelltextmodulen verknüpft werden können. Prometheus stellt das Analyseergebnis als Kiviat-Diagramm dar.

Rückruffunktion

Die Architektur der àServiceplattform Taurus® fußt auf àereignisdiskreten Modellen. Beim Eintreten ausgezeichneter àEreignisse werden von àISOM Rückruffunktionen aus àISOM/L-Programmen gerufen. Eine Teilmenge dieser Rückruffunktionen sind àEinsprungspunkte. Andere Beispiele für Rückruffunktionen sind àFilterfunktionen, àdelegierbare Funktionen und Funktionen für àWächter.

Rüsten

Rüsten bezeichnet das Einrichten eines Betriebsmittels für einen bestimmten Vorgang. Ein Beispiel ist der Aufbau einer Testkonstruktion aus àEmulation, àServicedaten und àSteuergerätedaten im Rahmen der Analyse einer àDefektmeldung.
(Siehe auch
àNachladen.)

Schattenspeicher

Schattenspeicher ist eine Form der Organisation des Flash-Speichers von àSteuergeräten. Der verfügbare Speicher ist dabei in zwei Abschnitte gegliedert, von denen im Fahrmodus immer nur einer verwendet wird. Bei der àFlash-Programmierung wird der aktuell nicht verwendete Teil aktualisiert. Kommt es dabei zu einem Flash-Abbruch, steht für den Neustart auf jeden Fall unbeschädigte àFirmware zur Verfügung. Nach erfolgreicher Aktualisierung wird der zuvor aktive Speicher zum Schattenspeicher. Die Funktion des Schattenspeichers wird vom àSpeichermodell des Fahrzeugs àDurango demonstriert.

Schritthaltende Logistik

Bei der schritthaltenden Logistik wird der àLogistikplan von àISOM unmittelbar nach jeder Änderung am àTherapieplan neu berechnet. Die Auswahl dieser Verwendung der Logistik erfolgt durch die àAnnotation AutoRetainLogisticsConsistency in einem àNamensraum oder an einer àAusführungsfunktion.
(Siehe auch
àNachgelagerte Logistik.)

Semantikprüfung (ISOM) (SePI)

Die Semantikprüfung (ISOM) (kurz: SePI) gewährleistet die Ausführbarkeit von àISOM/L-Programmen. Die Prüfung wird auf den àSyntaxbäumen der Programme ausgeführt, die nach erfolgreicher àSyntaxprüfung (ISOM) aus den Quelltexten erzeugt werden. Die Semantikprüfung kann abgeschaltet werden. Schaltet der àHerausgeber die Prüfung ab, kann dadurch der Startvorgang von àISOM beschleunigt werden. Um trotz abgeschalteter Prüfung die Vollständigkeit, Integrität und Authentizität von ISOM/L-Servicedaten gewährleisten zu können, wurde das àisbx-Dateiformat eingeführt.

Sensor

Ein Sensor ist ein elektronisches Bauelement, das eine phy­sikalische oder chemische Größe auf eine elektrische Größe abbildet. Die Messwerte digitaler Sensoren stehen direkt als Element des Eingangsvektors y einer àSteuerung zur Verfügung. Änderungen der Sensorwerte werden im àereignisdiskreten Modell der Steuerung als àEreignis interpretiert. Die Modellierung von Sensoren wird von der àkanonischen Beschreibungsform und von der àEmulationsbeschreibung unterstützt.
(Siehe auch
àAktor.)

Serverseitige
Client-Steuerung (SSCS)

Die àTaurus® Steuerung ist als Serverseitige Client-Steuerung (kurz: SSCS) Teil der àTaurus® Sitzungsverwaltung. Die Sitzungsverwaltung erzeugt für jede àTaurus® Sitzung eine eigene Instanz der Steuerung, die daraufhin mit der àBasissteuerung zusammenarbeitet.

Serviceanwendung

Eine Serviceanwendung ist eine Zusammenstellung von Programmen und Daten zur Erstellung von àDiagnosen und für die àSoftware-Reparatur von Fahrzeugen auf Basis der àServiceplattform Taurus®. Die Anwendung wird vom àHerausgeber als àDistribution bereitgestellt, die mithilfe von àMelas aus àTaurus® Programmen, OEM-spezifischen Programmen, àServicedaten, àSteuergerätedaten und begleitenden Dokumenten erzeugt wird. Die Installation der Distribution erfolgt mit dem àTaurus® Installer.

Serviceaufgabe

Die Serviceaufgabe beschreibt den Anlass, aus dem ein Fahrzeug in der Werkstatt behandelt wird. Sie bezeichnet das Ziel einer àFahrzeugsitzung, nicht die Art der Durchführung.

Serviceautor

Der Serviceautor ist ein Programmierer, der über die Kenntnis der Informationstechnik hinaus auch über Wissen im Bereich der Fahrzeugtechnik verfügt. Er erstellt Programme in der Programmiersprache àISOM/L und verknüpft ihre Ausführung im àTaurus® Automatenmodell. Der Serviceautor erstellt àServicedaten mithilfe eines Texteditors oder mit Werkzeugen wie àPerseus und analysiert in Ausführung befindliche àServiceanwendungen mit àAuriga.

Servicedaten

Als Servicedaten werden Daten für àServiceanwendungen bezeichnet, die von àServiceautoren für einen àMandanten erstellt und gepflegt werden. Servicedaten steuern das Verhalten und die Bedienoberfläche einer Serviceanwendung auf Basis der àServiceplattform Taurus®. Zu den Servicedaten zählen àISOM/L-Programme, àISOM-Fahrzeugbeschreibungen, àServicedaten (BOAM), die àHerausgeberkonfiguration und àWeb-Service-Vorlagen.

Servicedaten (BOAM)

Mit Servicedaten (BOAM) wird jener Teil der àServicedaten bezeichnet, mit dem die àTaurus® Bedienoberfläche (BO) und die àereignisdiskreten Zusammenhänge zwischen den einzelnen Bedienschritten einer àServiceanwendung im àTaurus® Automatenmodell (AM) in XML-Dateien beschrieben werden.
(Siehe auch
àAblaufautomat, àDarstellungsautomat, àDarstellungsdatei, àInhaltsdatei.)

Servicedatenverwaltung

Die Servicedatenverwaltung ist ein àFunktionsblock im àTaurus® Server und im àTaurus® Client. Der Funktionsblock kann àServicedaten für die Analyse durch einen àAuriga Live-Client bereitstellen.

Serviceplattform Taurus®

Die Serviceplattform Taurus® ist ein Produkt der IFS Infor­mationstechnik München für àDiagnoseanwendungen und für àServiceanwendungen zur àSoftware-Reparatur von àSteuergeräten in àFahrzeugen. Die Plattform bietet vielseitige Anpassungsmöglichkeiten an individuelle Anforderungen, indem sie z.B. die Verwendung OEM-spezifischer àFachdienste und Eingriffsmöglichkeiten in Form frei programmierbarer àServicedaten zur Gestaltung der àTaurus® Bedienoberfläche und des àAblaufs der Steuergerätebehandlung anbietet.
(Siehe auch
àThemis.)

Sicherheitsanbieter

Ein Sicherheitsanbieter ist eine Bibliothek, die kryptografische Verfahren und Methoden innerhalb des Sicherheitsfachdienstes àPalaimon realisiert. Der Anbieter muss die Schnittstelle ISecurityProvider implementieren.

Sitzung

Die gemeinsame Arbeit von àBediener und Programm wird als Sitzung bezeichnet, wenn das Programm àZustände und àTransitionen aufzeichnet. Beispiele dieser Aufzeichnungen sind das àBedienprotokoll und das àSitzungsprotokoll. Die Sitzung kann vom Bediener anonym geführt werden oder bei der Sitzungsaufnahme eine àAuthentisierung erfordern.
(Siehe auch
àTaurus® Sitzung.)

Sitzungsbeobachtung

Mithilfe der Sitzungsbeobachtung greift ein àBediener auf die Daten einer fremden àFahrzeugsitzung zu. Der Zugriff erfolgt nur lesend über eine àOperationssammlung, deren Verwendung in der àInhaltsdatei definiert wird. Das Funktionsmerkmal ermöglicht z.B. der Serviceannahme einer Werkstatt die Abfrage des aktuellen Zustands und des voraussichtlichen Abschlusses einer àSoftware-Reparatur.
(Siehe auch
àClient-Beobachtung.)

Sitzungsfortführung

Das àISOM-Phasenmodell erlaubt die Fortführung einer àFahrzeugsitzung auch nach Abarbeitung des àAktionsplans. Eine erneute Ermittlung des àSoll-Kontexts kann dadurch vermieden werden.

Sitzungskonservierung

àISOM ermöglicht die temporäre Unterbrechung einer àFahrzeugsitzung. Bei dieser Sitzungskonservierung wird das àISOM-Objektmodell mithilfe der àTaurus® Datenablage dauerhaft im Netzwerk gesichert. Die unterbrochene Sitzung kann zu einem späteren Zeitpunkt wiederaufgenommen werden. Die Sitzungswiederaufnahme kann auch auf einem anderen Rechner stattfinden.

Sitzungsprotokoll

Das Sitzungsprotokoll ist eine XML-Datei, die den Verlauf einer àFahrzeugsitzung wiedergibt. Die Elemente des Protokolls werden vom àServiceautor durch àISOM/L-Programme festgelegt. Er wird dabei vom àNamensraum Isom.Sys.Protocol unterstützt. Im Gegensatz zum àBedienprotokoll ist die Aufzeichnung nicht zur programmgesteuerten Wiederholung der àFahrzeugsitzung vorgesehen.

Sitzungsverwaltung

Siehe àTaurus® Sitzungsverwaltung.

Sitzungswiederaufnahme

Siehe àSitzungskonservierung.

SOAP

Siehe àWeb-Service.

Sofortaktion

Eine Sofortaktion (Synonym: sofort ausführbare Aktion) ist eine àEditierbare Aktion, die bereits in der Phase der àPlanbearbeitung unabhängig vom eigentlichen àTherapieplan ausgeführt werden kann. Die Ausführung der Aktion erfolgt durch die àSofortausführungsfunktion. Für sofort ausführbare Aktionen bleibt eine eventuell definierte àFilterfunktion unberücksichtigt.

Sofortausführungsfunktion

Eine Sofortausführungsfunktion ist eine àRückruffunktion, die in àISOM/L implementiert ist und von àISOM zur unmittelbaren Ausführung einer àSofortaktion gerufen wird. Der Name dieser Funktion beginnt mit „Run“, gefolgt vom Namen der auszuführenden Aktion.
(Siehe auch
àAusführungsfunktion.)

Software-Integrationsstand

Der Software-Integrationsstand charakterisiert die gemeinsame Freigabe von Hardware- und Softwareversionen für àSteuergeräte, die für eine Fahrzeugbaureihe zu einem bestimmten Zeitpunkt als zulässig und verträglich verifiziert wurden. Die Zuge­hörigkeit aller Teilnehmer im àBordnetz zu einem Software-Integrationsstand gewährleistet somit àKontextkompatibilität.

Softwarekauf

Softwarekauf bezeichnet den Kauf von Software während des laufenden Betriebs des Geräts, auf dem die Software aus­geführt werden soll. Der Verkäufer gewährleistet die àKontextkompatibilität der Software. Die Übertragung der gekauften Programme und Daten erfolgt über ein Netzwerk und nach der àFreischaltung wird die Abrechnung über ein Hintergrundsystem abgewickelt. Die gekaufte Software ist sofort funktionsfähig, der Käufer kann jedoch vom Kauf zurücktreten.
(Siehe Darstellung im Taurus® Player.)

Software-Reparatur

Die Software-Reparatur ist eine àServiceaufgabe. Sie dient der Wiederherstellung oder Verbesserung von Funktionen eines Fahrzeugs, die von àSteuergeräten und deren Software geleistet werden. Die Reparatur erfolgt im Rahmen einer àFahrzeugsitzung, häufig nach Erstellen einer àDiagnose. Die wichtigsten àAktionen sind àFlash-Programmierung, àCodierung, Individualisierung und àUmrüstung sowie der àTausch elektronischer Steuergeräte, falls sich die aus Gründen der àKontextkompatibilität erforderliche Software auf der vorhandenen Hardware nicht betreiben lässt. Die Software-Reparatur des Fahrzeugs àDurango kann über den àFahrzeugzugang Long Term Evolution (LTE) ohne Werkstattaufenthalt erfolgen.
(Siehe auch
àIndividualdaten.)

Soll-Kontext

Der Soll-Kontext ist Teil des àISOM-Objektmodells. Er ist eine Ausprägung des àFahrzeugkontexts und beschreibt den von der àLogistik vorgegebenen àSoftware-Integrationsstand des Bordnetzes. Der àServiceautor kann in den Aufbau des Soll-Kontexts durch àSpezialisierung des àEinsprungspunkts GetFutureContext eingreifen.
(Siehe auch
àIst-Kontext.)

Speicherabbild

Ein Speicherabbild ist eine Datei, in der àProgrammiersegmente zusammengefasst sind. Die Daten werden durch àFlash-Programmierung in ein àSteuergerät verbracht.

Speichermodell

Das Speichermodell von àVirgo ermöglicht eine realistische àNachbildung der Funktionen des àDiagnosemodus, insbesondere der àFlash-Programmierung und àFreischaltung. Modelliert werden sowohl Random-Access-Memory (RAM) als auch Flash-EEPROM. Auf der àVirgo-Bedienoberfläche werden die Speicherorganisation und die aktuelle Speichersituation interaktiv dargestellt.

Spezialisierung

Der Mechanismus der Spezialisierung ermöglicht die àbordnetzübergreifende Definition von àFunktionen und Annotationen, die anschließend für einzelne àBaureihengruppen oder àSteuergeräte spezialisiert werden. Wenn àISOM im Verlauf einer àFahrzeugsitzung die Implementierung einer Funktion benötigt, werden die àNamensräume des àMandanten in einer Reihenfolge durchsucht, die von der Datei Specialization.xml vorgegeben wird. Die Vorgabe der Suchreihenfolge kann für die àSpezialisierungskontexte „Fahrzeug“ und „Steuergerät“ getrennt erfolgen. Der Beginn der Suche wird als auslösender Namensraum bezeichnet. Für àEinsprungspunkte ist dies der Namensraum Isom.Global.Processes der àIBS.

Spezialisierungsauslöser

Der Spezialisierungsauslöser ist der àNamensraum, der in der Konfigurationsdatei specialization.xml eines àMandanten im Knoten TriggerNamespace angegeben ist. Beim Aufruf einer àFunktion aus diesem Namensraum sucht der àISOM-Interpreter im aktuell gültigen àSpezialisierungskontext die am weitesten spezialisierte Funktion.

Spezialisierungskontext

Der Spezialisierungskontext ist der Teil des àISOM-Objektmodells, der bei Suche nach einer àspezialisierten àFunktion oder àAnnotation verwendet wird. Man unterscheidet die Spezialisierungskontexte „Fahrzeug“ und „Steuergerät“.
(Siehe auch
àEinsprungspunkt.)

Steuerbefehl

Siehe àISOM-Steuerbefehl.

Steuergerät

Als Steuergerät wird ein Rechner in einem Kraftfahrzeug bezeichnet, der eine àSteuerung implementiert. Das Steuergerät bildet Informationen von àSensoren auf Signale an àAktoren ab, wobei dies oft in einem geschlossenen Regelkreis erfolgt. Dem Steuergerät ist eine àDiagnoseadresse zugeordnet. Das àereignisdiskrete Verhalten von Steuergeräten kann mit àVirgo nachgebildet werden.

Steuergerätebaum

Siehe àTaurus® Steuergerätebaum.

Steuergerätedaten

Zu den Steuergerätedaten zählen Daten, die über den àFahrzeugzugang in ein àSteuergerät übertragen werden können, z.B. Speicherabbilder für die àFlash-Programmierung, sowie Daten, die unmittelbar der Kommunikation mit einem Steuer­gerät dienen. Ein Beispiel hierfür sind Dateien gemäß dem Standard àODX-Daten. Zu den Steuergerätedaten zählen auch Daten, die für die àlogistische Verwaltung der zuvor genannten Daten benötigt werden.

Steuergeräte-Identifikation

Die Steuergeräte-Identifikation ermittelt die Informationen, mit denen aus der àISOM-Fahrzeugbeschreibung einer àBaureihengruppe der àIst-Kontext eines konkreten Fahrzeugs aufgebaut wird. Beispiele für die ermittelten Informationen sind die Versionen der Hardware und Software von àSteuergeräten und die Einträge in Fehlerspeichern.

Steuergerätevariante

Bei manchen Funktionen von àSteuergeräten handelt es sich um vom Kunden optional bestellbare Ausstattungen. Um Kosten zu reduzieren, gibt es Steuergerätevarianten, denen zwar dieselbe àDiagnoseadresse zugeordnet ist, die sich jedoch in Hardware und Software unterscheiden. Die Varianten können über àGültigkeitsterme in der àISOM-Fahrzeugbeschreibung definiert werden.
(Siehe auch
àUmrüstung.)

Steuergeräteverweis

Der Steuergeräteverweis ist ein Darstellungselement des àTaurus® Steuergerätebaums. Ist ein àSteuergerät an mehrere Kommunikationskanäle des àBordnetzes angeschlossen, wird es nur an einem Anschluss als àReferenzsteuergerät dargestellt, an allen weiteren Anschlüssen wird ein Verweis auf das Referenzsteuergerät eingezeichnet. Aufgrund seiner àhalbtransparenten Darstellung wird der Steuergeräteverweis auch als „SG-Geist“ bezeichnet.
(Siehe auch
Abbildung 5.)

Steuerung

Eine Steuerung zwingt einem technischen System ein Soll-Verhalten auf. Das System wird als Steuerstrecke bezeichnet. Der Zwang der Steuerung auf die Steuerstrecke wird über àAktoren ausgeübt. Die erforderlichen Signale werden von einem àereignisdiskreten Modell erzeugt, dessen Zustands­änderungen von àEreignissen getrieben werden. Die Ereignisse werden aus den Werten von àSensoren ermittelt. Zur Steuerstrecke einer àServiceanwendung auf Basis der àServiceplatt­form Taurus® zählt neben àFahrzeugzugangsgerät und àBordnetz auch der àBediener, der über Bedienelemente der àTaurus® Bedienoberfläche àEreignisse erzeugen kann.
(Siehe auch
àGRAFCET, àHeron, àTaurus® Steuerung.)

Syntaxbaum

Ein àISOM/L-Programm wird von àISOM intern als Syntaxbaum dargestellt. Für jeden àNamensraum und jede àBasisklassenerweiterung existiert genau ein Syntaxbaum.

Syntaxprüfung (ISOM) (SyPI)

Die Syntaxprüfung (ISOM) (kurz: SyPI) wird von àISOM immer durchgeführt, wenn àISOM/L-Programme als Quelldateien vorliegen. Die Prüfung erfolgt durch die ISOM-Komponenten Lexer und Parser. Nach erfolgreichem Abschluss liegen die Programme im Speicher als àSyntaxbäume vor. Diese Datenstrukturen können daraufhin von der àSemantikprüfung (ISOM) auf ihre Ausführbarkeit geprüft oder durch den àISOM-Interpreter ausgeführt werden.

Systemtest

Beim Systemtest wird geprüft, ob ein Produkt den Anwendungsfall des Lastenhefts erfüllt. Die Prüfung fußt auf einer Reihe von Testkriterien, die jeweils ein Fehlerbild hervorbringen oder ausschließen. Der Test findet in einer Testkonstruktion statt, die dem Einsatz des Produkts beim Kunden entspricht. Hierzu sind ggf. àNachbildungen für Umwelt und Plattformen erforderlich, wie sie z.B. àVirgo für àFahrzeuge und àFahrzeugzugangsgeräte bereitstellen kann.
(Siehe auch
àAnubis.)

Tabulatortaste

Mithilfe der Tabulatortaste und festgelegter àTastenkombinationen kann die àTaurus® Bedienoberfläche ausschließlich über die Tastatur bedient werden. Mit der Tabulatortaste wird dazu in àBildschirmmasken der Fokus von einem Bedienelement zum nächsten verlagert. In den àServicedaten (BOAM) wird die Reihenfolge definiert, in der Bedienelemente nach Drücken der Tabulatortaste den Fokus erhalten.

Tastenkombination

Um die àTaurus® Bedienoberfläche ausschließlich über die Tastatur bedienen zu können, ist es möglich, Tastenkombina­tionen aus der Taste „Alt“ und einem Buchstaben oder einer Ziffer zu definieren. Das Drücken einer festgelegten Tastenkombination löst anschließend dasselbe àEreignis aus wie die Betätigung eines Bedienelements auf der Bedienoberfläche mit der Maus oder mit dem Finger.

Taurus® Automatenmodell

Das Taurus® Automatenmodell (kurz: TAM) ist Teil der àServicedaten (BOAM). Es enthält die Beschreibung der àAblaufautomaten und àDarstellungsautomaten und definiert damit die Logik einer àServiceanwendung auf Basis der àServiceplattform Taurus®. Das Modell wird von der àTaurus® Steuerung interpretiert.

Taurus® Bedienoberfläche

Die Taurus® Bedienoberfläche ist ein àFunktionsblock des àTaurus® Clients. Er stellt die grafischen Elemente für die Bedienoberfläche einer àServiceanwendung bereit. Darstellung und Inhalt der àBildschirmmasken werden vom àServiceautor durch àDarstellungsdateien und àInhaltsdateien vorgegeben. Die zentrale Konfigurationsdatei ist TaurusClientConfig.xml im Ordner ~\Client\layout eines àMandanten.

Taurus® Client

Der Taurus® Client ist ein àAnwendungsrahmen, der die àTaurus® Bedienoberfläche bereitstellt. Weitere àFunktionsblöcke sind die àBasissteuerung, der àVehicle Communication Processor (VCP) und die àServicedatenverwaltung.

Taurus® Cloud

Taurus® Cloud bezeichnet den Betrieb einer Taurus® Server Farm auf deren Dienste àTaurus® Smart Clients über das Internet zugreifen.

Taurus® DataProcurement

Taurus® DataProcurement ist ein àAnwendungsrahmen zur OEM-unabhängigen Beschaffung OEM-abhängiger Daten. Die Daten werden von àDatenanbietern bereitgestellt. àAnwendungen kommunizieren mit dem Datenbeschaffer über die Schnittstelle ITaurusPlatform.

Taurus® Datenablage

Die Taurus® Datenablage ermöglicht die verteilte Ablage von Daten auf Rechnern in einem Netzwerk. Auf einem Rechner abgelegte Daten werden selbsttätig auf alle anderen Rechner repliziert. Die Replikation erfolgt auch nach dem Ändern oder Löschen von Daten durch àServiceanwendungen. Eine zentrale Komponente der Taurus® Datenablage ist der Funktionsblock àHermes.

Taurus® Datentransfer

Der Taurus® Datentransfer ermöglicht den Entwurf von àServiceanwendungen, die weitgehend datenlos installiert und erst zur Laufzeit mit aktuellen Daten versorgt werden. Typischerweise werden dann nur Daten transferiert, die von der àDiagnoseanwendung und für die àSoftware-Reparatur innerhalb der aktuellen àFahrzeugsitzung benötigt werden. Hierzu zählen z.B. àSteuergerätedaten.

Taurus®
Ereignisaufzeichnung

Programme, die sich in Ausführung befinden, erfassen àEreignisse in Ereignisprotokolldateien. Die Aufzeichnung dieser Ereignisse unterstützt die Analyse von Fehlerbildern. Die Taurus® Ereignisaufzeichnung verfügt hierzu über eine robuste Infrastruktur aus Programmen und Bibliotheken für verteilte àServiceanwendungen.
(Siehe auch
àZentraler Ereignisaufzeichner, àLokaler Ereignisaufzeichner, àProtokollierungstiefen.)

Taurus® Installer

Der Taurus® Installer ist das Installationswerkzeug der àServiceplattform Taurus®. Das Werkzeug wird als Bibliothek („Installer Engine“) bereitgestellt, die Funktionen für das Installieren, Aktualisieren, Reparieren und Entfernen von àDistributionen anbietet und die als Grundlage für Installationsprogramme dient. Der Taurus® Installer unterstützt die zentrale Bereitstellung von Distributionen im Internet und kann àDifferenzdistributionen verarbeiten.

Taurus® Kommunikationsbibliothek

Die Taurus® Kommunikationsbibliothek stellt die Infrastruktur für die Interprozesskommunikation zwischen àTaurus® Programmen bereit. Grundlage bildet die Technologie .NET Remoting, die um zusätzliche Kommunikationskanäle erweitert wurde. Die Bibliothek unterstützt die àVerbindungsüberwachung.

Taurus® Player

Der Taurus® Player gibt die Interaktion zwischen àBediener und àServiceanwendung wieder, die im Verlauf einer àTaurus® Sitzung aufgezeichnet wurde. Die Darstellung zeigt dabei die von der àClient-Beobachtung bekannte Detailtreue. Der Taurus® Player ist ein àLive-System und kann auch über den àIFS WebLoader bereitgestellt werden.

Taurus® Programm

Ein Taurus® Programm ist Teil einer àServiceanwendung, die auf Basis der àServiceplattform Taurus® entwickelt wurde. Das Programm ist meistens als àAnwendungsrahmen implementiert und verwendet die àTaurus® Kommunikationsbibliothek. Charakteristisches Merkmal eines Taurus® Programms ist, dass es in unveränderter Form in vielen OEM-spezifischen Serviceanwendungen zu finden ist.

Taurus® Proxy

Das Taurus® Proxy stellt ein Application-Level Gateway (ALG) für den Zugang zu einer Taurus® Server Farm aus dem Internet bereit. Die Software ist Teil des Programms àUniversalRouter, mit dem Testkonstruktionen für verteilte àServiceanwendungen aufgebaut werden können.
(Siehe auch
àTaurus® Cloud.)

Taurus® Quickstep

Taurus® Quickstep nutzt die àClient-Beobachtung für die rechnergestützte Zusammenarbeit von Menschen bei der Lösung einer àServiceaufgabe. Der Rechner eines unterstützenden Mitarbeiters wird dabei wechselweise mit dem Rechner des Werkers vor Ort für die Bedienung der àFahrzeugsitzung genutzt. Dabei zeigt der jeweils andere Rechner als Beobachter die durch­geführten Arbeitsschritte.

Taurus® Server

Der Taurus® Server ist ein àAnwendungsrahmen, der die àTaurus® Sitzungsverwaltung bereitstellt. Weitere àFunktionsblöcke sind der àZentrale Ereignisaufzeichner, die àServicedatenverwaltung und àHermes.

Taurus® Sidekick

Mit Taurus® Sidekick können àServiceanwendungen mit einer vorgangsorientierten Assistenzfunktion ausgestattet werden, die dem àBediener typische Servicevorgänge der àSoftware-Reparatur in Abhängigkeit von àIst-Kontext und Zustand im àTaurus® Automatenmodell anbietet.

Taurus® Sitzung

Eine Taurus® Sitzung ist eine àSitzung. Sie wird aufgenommen, indem die àBasissteuerung des àTaurus® Clients eine àTaurus® Sitzungsverwaltung mit dem Sitzungsstart beauftragt. Der Auftrag wird über eine àOperationssammlung im àTaurus® Automatenmodell erteilt. Innerhalb einer Taurus® Sitzung können àFahrzeugsitzungen gestartet, àkonserviert, wiederaufgenommen und beendet werden.

Taurus®
Sitzungsverwaltung

Die Taurus® Sitzungsverwaltung startet, beendet und verwaltet àTaurus® Sitzungen und ermöglicht dem àTaurus® Client die Verbindung mit laufenden Sitzungen. Die Taurus® Sitzungsverwaltung arbeitet als àFunktionsblock im àTaurus® Server. Den Zugang zu den Funktionen der Sitzungsverwaltung bietet die àOperationssammlung OperationPoolSession.

Taurus® Smart Client

Der Taurus® Smart Client ist ein funktionsmäßig schlanker Client (engl. thin client). Er umfasst die àTaurus® Bedienoberfläche, den àVehicle Communication Processor sowie den àTaurus® Verzeichnisdienst und àTaurus® DataProcurement. Im Betrieb werden zentral bereitgestellte Dienste, àServicedaten und àSteuergerätedaten in der àTaurus® Cloud verwendet.

Taurus® Steuergerätebaum

Der Taurus® Steuergerätebaum ist ein Bedienelement der àTaurus® Bedienoberfläche. Das Element stellt die àSteuergeräte eines Bordnetzes dar, einschließlich aller wesentlichen Kommunikationsverbindungen. Die Darstellung zeigt die àKontextkompatibilität der Steuergeräte, die geplanten àAktionen und den Fortschritt der Planausführung an. Das Element ist bedienbar und kann z.B. eine Steuergeräte-Detailansicht öffnen. In der àDarstellungsdatei wird der Taurus® Steuergerätebaum durch die Entität ecutree referenziert.
(Siehe auch
Abbildung 6 und àReferenzsteuergerät, àSteuergeräteverweis.)

Taurus® Steuerung

Die Taurus® Steuerung interpretiert zeitbehaftete, àereignisdiskrete Beschreibungen des Sollverhaltens einer àServiceanwendung. Diese Beschreibungen werden als àTaurus® Automatenmodell bezeichnet. Die Taurus® Steuerung arbeitet als àFunktionsblock im àTaurus® Client (àBasissteuerung) und im àTaurus® Server (àSSCS).

Taurus® Verzeichnisdienst

Mit dem Taurus® Verzeichnisdienst können àTaurus® Programme und Geräte in einem Rechnernetzwerk gefunden werden. Die Teilnehmer müssen sich dazu aktiv beim Dienst registrieren. Beispiele für teilnehmende Programme und Geräte sind der àTaurus® Server und das àIFSCI.

Tausch

Siehe àGeführter Tausch.

Teilbordnetz

Siehe àLogisches Fahrzeug.

Textdefinition

àServiceautoren können in àISOM/L-Programmen Zeichenketten mit dem Schlüsselwort deftext an Textbezeichner binden. Diese Textdefinitionen unterstützen die àLokalisierung von àServiceanwendungen. Sie können anschließend über den àNamensraum des Bezeichners referenziert werden.

Themis

Themis ist ein qualitätsorientierter Prozess zur Wartung von Softwareprodukten. Der Prozess bildet die àdiskrete Integration ab und fußt auf dem Einsatz quelloffener Werkzeuge, die von àPrometheus gesteuert werden. Auf der Grundlage von Themis werden àTaurus® und eine àServiceanwendung der BMW Group gewartet.

Therapieplan

Ein Therapieplan beschreibt die àSoftware-Reparatur eines Fahrzeugs. Er stellt eine Sammlung von àAktionen dar, mit denen der Zustand des Fahrzeugs vom àIst-Kontext in den àSoll-Kontext überführt wird. Die Aktionen des Plans wurden von àISOM automatisch mithilfe der àLogistik berechnet, von einem àServiceautor für das Fahrzeug definiert oder vom Servicetechniker in der Werkstatt manuell hinzugefügt. Der Therapieplan gibt dabei keine fachliche àAusführungsreihenfolge vor. Er bildet die Grundlage für den àAktionsplan.

Transition

Eine Transition ist Bestandteil eines àereignisdiskreten Modells. Sie modelliert die Änderung eines àZustands. Die Modellierungspraxis der Automatisierungstechnik assoziiert Transitionen mit àEreignissen, bei deren Eintreten eine Transition schaltet, sofern ihr Vorbereich aktiv ist. Die Signale mehrerer àSensoren werden mithilfe einer booleschen Funktion zu einer Transitionsbedingung verknüpft. Der Wert wahr ist daraufhin gleichbedeutend mit dem Eintreten des Ereignisses. Transitionen werden im àTaurus® Automatenmodell, in der àKBF und in der àVirgo-Steuergerätebeschreibung beschrieben.

Transparenz

Werden Elemente der àTaurus® Bedienoberfläche transparent dargestellt, sind die Bestandteile der Bedienoberfläche erkennbar, die von den Elementen verdeckt werden. Das Funktionsmerkmal wird z.B. vom Assistenzfenster in àTaurus® Sidekick und zur Darstellung des Kindfensters nach Abgabe des Eingabefokus an das Elternfenster eingesetzt.

Überarbeitungsstand

Der Überarbeitungsstand beschreibt eine Konfiguration von Fahrzeugen einer àBaureihengruppe. Für jeden Überarbeitungsstand werden in der àISOM-Fahrzeugbeschreibung àlogische Fahrzeuge modelliert. Unterschiedliche Überarbeitungsstände einer Baureihengruppe können sich z.B. durch die zu verwendenden àFachdienstesätze unterscheiden.

Umrüstung

Eine àUmrüstung verändert, erweitert oder reduziert Funktionsmerkmale eines Fahrzeugs. Der Vorgang kann den Einbau oder den Tausch von àSensoren, àAktoren und àSteuergeräten umfassen sowie àFlash-Programmierungen und àCodierungen erfordern.
(Siehe auch
àSteuergerätevariante.)

UniversalRouter

UniversalRouter ist ein Programm, das TCP-Datenpakete zwischen Prozessen weiterleiten kann. Das Programm wurde für Testkonstruktionen entwickelt, mit denen die àFlash-Programmierung über das Internet getestet wird. Das Programm ermöglicht auch die Beeinflussung und Störung der Datenübertragung im Sinne eines „Traffic-Shaping“. Neben der Funktionalität in der Transportschicht der Netzwerkkommunikation umfasst UniversalRouter auch das àTaurus® Proxy.

Ursprungsinformation

Die Ursprungsinformation ist Teil des àisbx-Dateiformats. Zu den gespeicherten Informationen zählen die Pfade und Prüfsummen der originalen Quelltextdateien – einschließlich aller àeingefügten Dateien – sowie Datum, Uhrzeit, Rechneradresse und Domänenkonto des Übersetzungsvorgangs.

Verbindungsüberwachung

Die Verbindungsüberwachung der Kommunikation zwischen àTaurus® Programmen ist ein Funktionsmerkmal der àTaurus® Kommunikationsbibliothek. Ein Beispiel ist die Überwachung der Verbindung zwischen àTaurus® Client und àTaurus® Server.

Virgo

Virgo bildet das àereignisdiskrete Verhalten des àDiagnosemodus der àSteuergeräte eines Fahrzeugs nach. Eigenschaften und Ver­halten der Steuergeräte sowie die Merkmale des àBordnetzes werden durch die àEmulationsbeschreibung festgelegt. Virgo unterstützt die Anbindung von CAN-Hardware und neben anderen die Diagnoseprotokolle UDS (ISO 14218) und KWP2000 (ISO 14230).

Virgo-Bedienoberfläche
(Virgo-BO)

Die Virgo-Bedienoberfläche (kurz: Virgo-BO) ist ein Programm, mit dem àEmulationen gestartet und bedient werden können. Die Bedienoberfläche ermöglicht das Einstellen von Werten für Messgrößen der Umwelt, die über àSensoren erfasst werden, und die Manipulation von àTransitionen in den àZustandsautomaten der Modelle, wodurch anspruchsvolle Testkonstruktionen ohne reales Fahrzeug àgerüstet werden können.
(Siehe auch
Abbildung 7.)

Virgo-Fahrzeugbeschreibung

Die Virgo-Fahrzeugbeschreibung ist Teil der àEmulationsbeschreibung von àVirgo. In der XML-Textdatei sind Merkmale des nachzubildenden àFahrzeugs und eine Liste von Dateien angegeben, die àVirgo-Steuergerätebeschreibungen enthalten.

Virgo-Steuergerätebeschreibung

Die Virgo-Steuergerätebeschreibungen sind Teil der àEmulationsbeschreibung von àVirgo. Sie werden von der àVirgo-Fahrzeugbeschreibung referenziert. Jede der XML-Textdateien beschreibt die Merkmale und das àereignisdiskrete Verhalten eines einzelnen àSteuergeräts. Zu den Merkmalen zählen z.B. die àDiagnoseadresse und die Busverbindungen. Das Verhalten resultiert aus der Verarbeitung von àDiagnosetelegrammen. Das XML-Schema der Steuergerätebeschreibung wird von der àBordnetzgeneration vorgegeben.

Virgo-Fahrzeugzugang

Der Virgo-Fahrzeugzugang ist ein Programm, das ein àFahrzeugzugangsgerät nachbildet. Die àNachbildung ist in Bezug auf das Finden, Reservieren und Freigeben sowie die verfügbaren àP-Kanäle im Werkstattnetz nicht von einem echten Gerät zu unterscheiden. Der Virgo-Fahrzeugzugang kommuniziert mit einer àEmulation.

Virgo-Instanz

Jede àEmulation ist üblicherweise mit der àNachbildung eines àFahrzeugzugangsgeräts durch den àVirgo-Fahrzeugzugang verbunden. Eine Ausnahme bildet der Betrieb der Emulation hinter einem OBD2-Schnittstellenmodul der IFS. Der Einheit aus Emulation und Virgo-Fahrzeugzugang ist entweder eine IP-Adresse des Rechners zugeordnet oder die Nummer einer Virgo-Instanz.

VirgoLint

VirgoLint ist eine Konsolenanwendung, die àEmulationsbeschreibungen prüfen und konvertieren kann. Geprüft werden neben der Gültigkeit gemäß XML Schema auch interne fachliche Zusammenhänge der Beschreibung.

Virtuelle Aktion

Virtuelle Aktionen sind àAktionen, die bei der Erzeugung und Ausführung des àAktionsplans unberücksichtigt bleiben. Alle àzusammengesetzten Aktionen sind virtuell.

Virtueller Ist-Kontext

Der Virtuelle Ist-Kontext ist eine spezielle Instanz des àIst-Kontexts. Er wird von der àIBS im Verlauf der Ausführung von àFilterfunktionen als Ergebnis des Aufrufs GetInstance im Namensraum Isom.Context.CurrentVehicleContext zur Verfügung gestellt. Der Ist-Kontext ist darin bereits um jene àAktionen ergänzt, die seit Beginn der àPlanbearbeitung hinzugefügt wurden.

Vehicle Communication Interface (VCI)

Siehe àFahrzeugzugangsgerät.

Vehicle Communication Processor (VCP)

Der Vehicle Communication Processor (kurz: VCP) ist ein Programm, das die Verbindung zwischen dem Kommunikationsprozessor des D-Servers àAeneas und dem àFahrzeugzugangsgerät herstellt. Das Programm ist als àFunktionsblock implementiert. Es kann damit sowohl in Aeneas selbst als auch im àTaurus® Client betrieben werden.

Void-Objekt

Ein Void-Objekt, das in àISOM/L ein „leeres Objekt“ repräsentiert, entsteht aus einem Objekt, wenn innerhalb einer seiner àFachfunktionen eine unerwartete Ausnahme auftritt. Wird eine Fachfunktion eines Void-Objekts aufgerufen, wird sie nicht abgearbeitet, sondern es wird wiederum ein Void-Objekt zurückgeliefert. Das Merkmal „Voidness“ kann mit der Fachfunktion IsVoid geprüft werden.

Wächter

Wächter ermöglichen die Überwachung von Umgebungsgrößen durch àISOM/L-Programme. Beispiele für überwachte Größen sind die Klemmenspannung des Fahrzeugs oder die Prozessorlast des àTaurus® Servers. àISOM ruft nach Erreichen eines Grenzwertes selbsttätig eine vom Autor registrierte àRückruffunktion auf. Die Registrierung der Rückruffunktion kann mit einer àAnnotation oder mit der àIBS erfolgen.

Web-Service

àTaurus® Programme bieten ihre Dienste als Web-Service im Simple Object Access Protocol (SOAP) über HTTP und TCP an. Die WSDL-Beschreibung kann über den URL-Parameter ?wsdl abgerufen werden, z.B. für einen lokalen àTaurus® Server mit dem URI localhost/TaurusServer. àISOM/L-Programme können Web-Services über àWeb-Service-Vorlagen nutzen.
(Siehe auch
Abbildung 8 und àTaurus® Kommunikationsbibliothek.)

Web-Service-Vorlage

Web-Service-Vorlagen sind Teil der àServicedaten einer àServiceanwendung der àServiceplattform Taurus®. Die Vorlagen sind XML-Dateien, die als Schablonen für die Inanspruchnahme von àWeb-Services dienen. Die Dateien werden vom àDatenanbieter WebServiceProvider des àTaurus® DataProcurements verarbeitet.

Werksprogrammierung

Die Werksprogrammierung ist eine Sonderform der àSoftware-Reparatur, die im Verlauf der Produktion eines Fahrzeugs zum Einsatz kommt. Die Produktion eines Fahrzeugs erfolgt gemäß einer Stückliste, die neben der Hardware auch die im Fahrzeug verbaute Software umfasst. Somit ist der àSoll-Kontext bekannt und es entfällt die Notwendigkeit der Berechnung eines àLogistikplans.
(Siehe auch
àRetriever.)

Wirtssprache

Wirtssprachen der àServiceplattform Taurus® sind alle Plattformsprachen des .NET Frameworks. Die àTaurus® Programme und auch die meisten àPlattformfunktionen sind in der Wirtssprache C# implementiert.
(Siehe auch
àFassade.)

Zeigemodus

Mit dem Zeigemodus von àAuriga kann die Definition von Elementen der àTaurus® Bedienoberfläche auf Einträge in der entsprechenden àDarstellungsdatei zurückgeführt werden. Die Auswahl des Elements erfolgt über ein Fadenkreuzsymbol.

Zeitgeber

Der Zeitgeber ist ein Element einer àSteuerung. Er wird gestartet und erzeugt nach Ablauf des konfigurierten Zeitintervalls ein àEreignis. Dessen Eintreten kann in die Bedingung für das Schalten einer àTransition im àereignisdiskreten Modell der Steuerung eingehen. Die Übereinstimmung von konfiguriertem und tatsächlichem Zeitintervall ist eine der Voraussetzungen für Echtzeitfähigkeit. Periodische Zeitgeber ziehen sich selbsttätig nach Ablauf eines Zeitintervalls wieder auf. Die àIBS stellt hierzu den àNamensraum Isom.Sys.Events.PeriodicTimer zur Verfügung. àHeron unterstützt die Verwendung von Zeitgebern durch das Modul TIMER.

Zentrale
Fachdienstverwaltung

Die Zentrale Fachdienstverwaltung (kurz: ZFV) startet àFachdienste und überwacht ihre Ausführung. Die Merkmale eines Fachdiensts werden von àFachdienstadaptern bereit­gestellt. Der Fachdienstadapter gibt an, ob ein Fachdienst exklusiv einer àFahrzeugsitzung zugeordnet ist, und steuert die Wiederverwendung des Fachdiensts nach dem Ende einer Sitzung. Das Programm der ZFV ist als àAnwendungsrahmen implementiert.

Zentraler
Ereignisaufzeichner

Der Zentrale Ereignisaufzeichner (kurz: ZEA) ist ein àFunktionsblock des àTaurus® Servers. Der ZEA ist die steuernde Komponente der àTaurus® Ereignisaufzeichnung. Er konfiguriert die àLokalen Ereignisaufzeichner und nimmt von ihnen àEreignisse entgegen. Der ZEA erstellt auch das àSitzungsprotokoll.

Zertifikat

Ein Zertifikat ist ein beglaubigter öffentlicher kryptografischer Schlüssel. Beglaubigt wurde der Schlüssel durch die digitale Signatur eines Herausgebers. Dessen Unterschrift kann mit einem weiteren Zertifikat verifiziert werden, woraus eine hierarchische Vertrauenskette der Zertifikate resultiert. Zertifikate werden zur àAuthentisierung eingesetzt, z.B. beim àSoftwarekauf und für àFreischaltungen.

Zugangssteuergerät

Ein Zugangssteuergerät ist Teil des Fahrzeugs. Es kommuniziert direkt mit dem àFahrzeugzugangsgerät und ist Proto­kollumsetzer (engl. Gateway) für weitere Teilnehmer (Steuergeräte) im àBordnetz.

Zusammengesetzte Aktion

Zusammengesetzte Aktionen bilden die hierarchische Struktur des àTherapieplans in àISOM ab. Sie dienen als Behälter für andere àAktionen, die selbst wiederum zusammengesetzt oder atomar sein können. Ein Beispiel für eine zusammengesetzte Aktion ist die Gesamtcodierung eines àBordnetzes, die aus atomaren Aktionen für die àCodierung der einzelnen àSteuergeräte zusammengesetzt ist.

Zusammengesetztes
Steuergerät

Teilen sich mehrere einzelne àSteuergeräte ein gemeinsames Gehäuse, bilden sie ein zusammengesetztes Steuergerät (ZSG). Das zusammengesetzte Steuergerät wird als Aggregat und die darin enthaltenen Teilgeräte werden als Komponenten bezeichnet.

Zustand

Ein Zustand beschreibt die Situation eines àereignisdiskreten Systems. Er ist die Folge der Änderungen, die sich seit dem Start eines Systems ereignet haben. In einem Zustand kann das Eintreten bestimmter àEreignisse das Schalten von àTransitionen auslösen. Im àPetri-Netz werden die möglichen Zustände und Aktivitäten des Systems als Stellen modelliert und in àGRAFCET durch Schritte abgebildet.

Zustandsautomat

Ein Zustandsautomat ist ein àereignisdiskretes Modell, bei dem auf jede Transition genau ein einziger Zustand folgt. Da die Menge der möglichen Zustände endlich ist, wird der Zustandsautomat auch als endlicher Automat (EA) bezeichnet. Beispiele für Zustandsautomaten sind àAblaufautomaten, àDarstellungsautomaten und die ereignisdiskreten Modelle für Steuergeräte in àVirgo-Steuergerätebeschreibungen.

Zwangscodierung

Der àServiceautor kann die àCodierung eines àSteuergeräts anweisen, auch wenn aus Gründen der àKontextkompatibilität diese àAktion nicht erforderlich wäre. Eine auf diese Weise „erzwungene“ Codierung wird als Zwangscodierung bezeichnet.

Zwangsprogrammierung

Zwangsprogrammierung bezeichnet die àFlash-Programmierung von Teilen der Software eines àSteuergeräts, obwohl diese Teile aus Gründen der àKontextkompatibilität planmäßig nicht aktualisiert werden müssten.