EP1483666A2 - Service-controller für computersysteme, insbesondere für ein kraftfahrzeug - Google Patents

Service-controller für computersysteme, insbesondere für ein kraftfahrzeug

Info

Publication number
EP1483666A2
EP1483666A2 EP03742455A EP03742455A EP1483666A2 EP 1483666 A2 EP1483666 A2 EP 1483666A2 EP 03742455 A EP03742455 A EP 03742455A EP 03742455 A EP03742455 A EP 03742455A EP 1483666 A2 EP1483666 A2 EP 1483666A2
Authority
EP
European Patent Office
Prior art keywords
layer
service
protocol
controller
logic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP03742455A
Other languages
English (en)
French (fr)
Inventor
Martin Ruff
Stefan Wellenhöfer
Norbert Feulner
Roland ZSCHÖRNIG
Wolfram Hohmann
Jens Fliegner
Jens Krüger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Volkswagen AG
Original Assignee
Volkswagen AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from DE10233488A external-priority patent/DE10233488A1/de
Application filed by Volkswagen AG filed Critical Volkswagen AG
Publication of EP1483666A2 publication Critical patent/EP1483666A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces

Definitions

  • Service controller for computer systems, in particular for a
  • the invention relates to a method for operating a service controller for vehicle-specific computer systems according to the features of claim 1 and computer system according to the features of claim 11.
  • Multi-tasking systems and multi-tasking real-time systems are widely known.
  • the Unix programming system has been in existence for years, with which a multitasking system can be implemented.
  • various real-time operating systems such as QNX. This enables a program to execute commands in "real time”.
  • Multimedia system with connected radio system and Traffic radio decoder and the traffic radio decoder receives an incoming traffic message, so this is immediately communicated to the system.
  • the system extracts the computing time from the running processes and switches the corresponding traffic message through.
  • DE-A1-100 43 086 discloses a cockpit system architecture, in particular for a motor vehicle, with at least one vehicle-specific component and at least one multimedia component.
  • the individual components have various functions, for example an operating function, a travel direction function, a signal processing function and a control function, which are implemented on a software and hardware basis.
  • the individual functions of the respective components are partitioned, i. H. separated and functionally, modularly combined, independent of components.
  • DE-C1-199 29 330 discloses a vehicle communication system with a data bus and components connected to it.
  • the components include at least one display / operating device and a computing device controlling it.
  • An interface based on the HTML / XML page format is implemented on the display / operating device and / or the computing device controlling it.
  • HMI human machine interface
  • FIG. 1 shows a form of implementation for today's infotainment systems for motor vehicles.
  • This system has a human machine interface and other facilities such as compact disc player, navigation, radio are integrated or connected. These individual devices are combined in a single device and have a common display and operating device.
  • Another currently known infotainment system is shown schematically by way of example in FIG. 2, this system is comparable to the system known from the already mentioned patent specification DE-C1-199 29 330.
  • This system has a control device with a human machine interface, which is connected to external devices such as CD navigation, telephone, radio, etc. via a bus protocol or an API protocol.
  • the object of the invention is to dissolve the rigid system architecture of the known multi-function operating devices and, furthermore, to make it possible to connect further devices / applications to existing systems and / or to exchange components.
  • a so-called service controller is integrated, which manages the distribution of services between the computer system and a real-time operating system.
  • special interfaces are implemented on the service controller for the human machine interface and for real-time operating systems, which enable special access to the individual services of the system. In this way it is also possible to achieve conflict management between the individual services.
  • Data access barriers can be designed to be multi-level and encapsulated, since these can be displayed individually for each service.
  • Multi-stage means that access to any existing human machine interface and to any application, for example Internet access, is only possible with the necessary access codes. Due to the encodability of the system and integrated management, this results in differentiated data transfers to and from special applications and services. Clear access rights can be assigned, ie that For example, for Internet activities that run in the system, the necessary and sufficient reserves are made available. This provides security against hackers in the sense of a fire wall. It is therefore not possible for a service to be able to access external resources that it does not need.
  • the user interface programming includes e.g. B. Control tasks for the human machine interface, in particular which display image and which key assignment is displayed after selection of a function and which inputs a user can make on the user interface.
  • the human machine interface interface introduces operating logic in which both the device control and the overall system control are interwoven. Given the great complexity of the system, the actual processes can no longer be traced, or only with great difficulty. However, these depend on the given system options.
  • it is predefined which functions a device can perform and which functions are provided for a user. These are assigned to the inputs or functions that can currently be performed on the device.
  • the service controller takes over these tasks by calling up the functions currently available from the device, which can also be carried out, and displaying them on the human machine interface. Only the functions that are actually actually executable by the device are displayed on the human machine interface and the display device. To illustrate this, this is explained in more detail using a CD player as an example.
  • the CD player has loaded a CD. It is in the "pause” state.
  • the service controller signals to the human machine interface that only the "CD play", "eject CD” or "stop mode” functions are available. Other functions are not possible and will not displayed. This information is provided by the device itself.
  • the device transfers its existing and executable functions to the service controller for the respective operating status. Consequently, a user can clearly see which functions he can select and which functions the device provides.
  • the existing display potential on the display device is tailored to the individual functions that are actually possible. If, for example, a user selects the "CD play" function, the service controller monitors the execution of the corresponding command for the CD player and at the same time asks whether there are further functions or function requests. Then he sends the command via the bus to CD player off The amplifier is informed that the CD player is now responsible for the sound. The CD player is now the signal source for the audio data and the amplifier amplifies it and routes it to the selected signal sinks Service controller a line between the amplifier and the CD player, so the service controller does two tasks at the same time, firstly to tell the human machine interface which functions are currently possible on the bus and which functions can be freely selected by a user At the same time, it controls the individual devices on the bus.
  • the system dynamics are implemented in three layers, in which the entire system dynamics are processed proportionately and independently. These three layers are:
  • service controller The dynamics within an application, hereinafter referred to as "service”.
  • the amplifiers are consequently controlled in such a way that they amplify the output data of the CD player and forward them to the output unit or output units, in particular loudspeakers, and possibly this Data (volume, frequency enzen) graphically on a display.
  • the input of the "CD play” command is requested via the human machine interface, which runs in the first layer, and goes to the service controller, which runs in the second layer, without the human machine interface necessarily carrying out the further execution to monitor or to have a direct connection to the other services that are running.
  • the service controller selects and controls the other necessary functions.
  • the system dynamics are not dealt with in the user interface of the human machine interface as before, but are dealt with separately and specifically as "conflict management" in the service controller. This means that the service controller takes over control of the remaining work and the human machine interface is disconnected separately Several systems addressed simultaneously will therefore have a dynamic sequence in their sequence
  • the service controller regulates the dynamics independently. It would make little sense to adjust the amplifier before the first signals for amplification are available. However, there is also the possibility that all services must be available at the same time, and some may also conflict with each other.
  • the service controller acts as a means and as an acting entity that clears up conflicts in advance of service implementation, regardless of the knowledge and, if applicable, the operator's will.
  • the great advantage of this system is that the operating logic of the individual devices that are connected can always remain the same, even if a new device is connected.
  • the service controller queries the operating logic of the device and automatically adds it to the system and integrates it into the set of rules with the corresponding rules. In exceptional cases, the corresponding block of the operating logic in the system itself must be replaced. However, the service controller recognizes this automatically and carries out these tasks. When inserting a new device, the service controller queries its functions and operating logic and saves them automatically. The service controller therefore creates a double set of rules, a device-specific set of rules and a set of rules that describes the relationships between the devices and applications.
  • the service controller checks whether the function is permissible, feasible and producible according to the existing rules. If the function is available and can be carried out, it initiates a cascade of commands that controls the entire system. All devices are controlled in a state that is necessary for the execution of the operating command or an automatic operating command. The service controller generates a rule-based overview of the devices and their functions and automatically compiles the processes that are necessary for execution.
  • a service API is present in the set of rules, its functions for device control in blocks for different Buses are subdivided, for example CAN bus, MOST bus, etc.
  • This service API can be placed on different bus blocks and connect them to each other, regardless of the connected devices.
  • the further dependent operating logic in particular the service controller, is no longer required to be kept informed of which physical devices call the desired function and in which form this function or command is to be issued.
  • the service controller only has to recognize which functions are available and which functions are possible. The rest is then controlled by the service API. When a device is inserted into the system, this makes it possible to insert the rule in just one place, namely in the service controller.
  • the further connections are then made automatically by the service API. This makes the system more transparent.
  • Individual applications can claim system resources on their own initiative, without user intervention. For example, if a traffic message is received or a traffic announcement is triggered in the vehicle while listening to the CD, i.e. the tuner makes a claim to the loudspeaker resources in order to output the incoming or received traffic message there and is furthermore conceivable that during a call that also wants to use the loudspeaker resource in the background navigation system, a necessary time and place or action instruction is given to spend for the driver, so far this has been solved in the form of a hard-coded straight-forward implementation, in which case these resources are directly accessed without the use of an intermediate instance.
  • the service controller intervenes here as a rule-based conflict management system. Always and in any case there is predictable system behavior. In the case described above, the service controller will issue a service message and cause a playback interruption beforehand. If the service message output is then ended, the service controller will continue to play the CD. Furthermore, the service controller can now be used to regulate transitions from service states, from applications, devices, sensors, tuners, which do not take place in time but require a certain transition or start time. The acquisition and controller monitoring of the aforementioned time, approval and activity frameworks are carried out according to predetermined rules for the individual services themselves, detached from conflict management between the various services and from user input via the human machine interface.
  • the service controller runs on a QNX-based computer
  • the human machine interface runs on a Windows CE-based computer
  • the service controller then manages the conflicts that arise independently.
  • multiprocessor systems can be managed without conflict.
  • the system interfaces in particular the interfaces between the human machine interface, the service controller and applications, are strictly message-based.
  • the system offers freedom in implementation technology, different layers and different services in different programming languages such as B. C, CH, C # (C-Sharp), Java, XML can be programmed.
  • the system concept also allows the integration of an OSGI framework (Open System Gateway Initiative) at the message-based interface. This enables significant system expandability while implementing strict security requirements for access rights and the encapsulation of services.
  • OSGI framework Open System Gateway Initiative
  • FIG. 5 shows a structure of a service controller.
  • the Human Machine Interface Layer also referred to as the skin or GUI layer, controls the graphic output and display of the Human Machine Interface (HMI), the design and the logical structure.
  • HMI Human Machine Interface
  • the underlying service layer is the middle part of the system.
  • Each physical unit in the system is represented by one or more services (logical units). For example, there is a phone service, a CD player service, etc. These services offer a hardware-independent set of commands, for example the command “telephone number 123 select "or" CD player play song 3 ".
  • the most important component in the service layer is the service controller, which manages and controls the services among themselves and, as the actual head unit, centrally manages the services. The service controller will be discussed in more detail below.
  • the third layer is followed by the protocol layer, which has the software components, in particular, for example, the protocols for in-vehicle communication on a multimedia bus system, such as MOST or Fire Wire, and at the same time represents the interface between software and hardware.
  • a multimedia bus system such as MOST or Fire Wire
  • the human machine interface sends a suitable message to the service controller.
  • the specified protocol that defines this message is referred to as the so-called multimedia interprocess communication protocol (MIC protocol).
  • MIC protocol multimedia interprocess communication protocol
  • SERAPI SEvice API
  • the strict separation between the Human Machine Interface Service and the protocol layer has various advantages.
  • One of these advantages is the high level of abstraction of the system.
  • the system offers the human machine interface an interface that is completely hardware and software independent and also independent of protocols. This means that the human machine interface, which runs, for example, on a MOST multimedia unit, can also function on a system based on fire wire, without any adaptation.
  • the logical structure of the user interface is completely encapsulated and limited to the human machine interface layer. This makes it very easy to change and completely change the design and the "look and feel" of the system in the human machine interface to replace without touching the underlying layers. Of course, this also makes it possible to design the development and the new implementation of individual services and of individual layers depending on the system.
  • a multimedia system has the following properties:
  • the human machine interface runs in a separate layer, the human machine interface layer. It can therefore be tested and developed as a separate unit.
  • This means that a software component is required which controls the service in a controlling and synchronizing manner and which establishes an interface between the human machine interface layer and the service interface. This component is the service controller.
  • the system consists of countless processes and threads currently running. In order to enable communication with each other, these send out messages which are defined by the MIC protocol.
  • the MIC protocol is constructed asynchronously due to the sometimes very long response times of some multimedia components. There are many situations, for example during the initialization phase, in which it is necessary to synchronize the individual components. It is the job of the service controller to perform and maintain this synchronization.
  • a multimedia system mostly consists of hardware units that only allow exclusive access. If various services need access to such hardware, it is the job of the service controller to solve these problems and the conflicts that arise between the services. This also applies in cases where parallel access is possible but not absolutely necessary.
  • the service controller solves this task by coordinating the event handling and executing it in such a way that the specified properties are met.
  • the main components of the service controller and its structure are shown on the basis of FIG.
  • the service controller consists of three main components that are always in operation, namely in parallel operation.
  • the down thread and the up thread have the task of receiving messages from the human machine interface and from the services and storing them in a central queue. Regardless of this, it is possible to carry out pre-filtering and pre-fetching of the messages which are carried out in part of the service controller.
  • the main thread takes the messages from the queue, executes them and manages them.
  • the message queue is a complicated structure. It consists of different queues, which can have different sizes. Each queue has its own priority. The receiving thread determines the priority of the event and stores it in the Appropriate Queue.
  • the service controller has a dispatcher. This dispatcher runs in the main thread and manages the events. It monitors and saves the current status of the individual system components. For example, in a system with a GSM modem, it monitors whether the phone service has access to the modem or whether a call is pending or whether the IP service is currently using the modem to establish an Internet connection.
  • the dispatcher does not monitor all system states, it only monitors those states that have an influence on whether an event can be executed or not.
  • the decision as to how and when an event is carried out and / or can be carried out is linked to various events.
  • the dispatcher creates a new job that manages this event.
  • the dispatcher saves a list of active jobs.
  • the service controller decides between two states or phases, the initialization phase and the operating phase. During the initialization phase, each service and the human machine interface reports directly to the service controller. The service controller then initializes the communication for each individual process. The service controller reads from the configuration file whose services are necessary to maintain an operational system. When all necessary services and the human machine interface are registered, each process receives a message from the service controller that the system is now in operation. If not all services have answered after a defined period of time, the service controller decides for itself whether limited operation is possible or whether the system is not operational.
  • Event handling is described in more detail below.
  • the system knows a large number of events. The way in which an event is handled depends on various system stages. Nevertheless, various events are treated equally.
  • a defined abstraction has been introduced to simplify event handling and to be open for future extensions.
  • Some event attributes have been introduced and a number of rules that define how an event is to be dealt with, based on the attributes.
  • the service controller has a table, a so-called info table, which contains some information for each defined event. This information consists of a priority with which the event is to be carried out and
  • Event attributes which are also referred to as event flags. It is possible that an event has various combinations of different attributes.
  • Audio producer
  • This flag gives the service controller the message that this event will start various audio outputs.
  • Audio Stopper This flag informs the service controller that the event ends its audio output.
  • the service controller receives the message that such an event can only be carried out correctly when the GSM modem is ready to open a connection.
  • This flag is set if an event cannot be managed or executed, depending on the rules mentioned above. For each ruie exception, the dispatcher must have a function that manages this special event.
  • the up thread When the up thread receives an event, it takes the associated priority for the priorities of this event from the info table and saves it in the associated queue.
  • the events of the human machine interface that are received by the down thread always have the highest priority.
  • the dispatcher becomes active as long as the queues are not empty. He fetches the next event, whereby of course he looks first in the queues and takes the event which has the highest priority. If this queue is empty, it takes the oldest element from the queue with the lowest priority, etc. Then the dispatcher checks whether the service to which the event is addressed is part of the running system. If this is not the case, an error message is sent. Then the dispatcher goes through the rule list and checks whether the event has a ruie condition.
  • an event can result in a sequence of actions which have to be carried out. Due to the asynchronous behavior of the system, it is necessary to wait for a sequence at a defined point for a message before the sequence can be ended completely. This means that the dispatcher must be able to receive new events before the first event is completely processed and ended. These types of events are in a job executed. When the dispatcher calls a job, it executes this sequence as far as possible. Until the dispatcher calls all jobs, a new event is received every time, in which case the job itself can check whether the condition for which it is waiting has come about - due to the new incoming event - and the job itself can continue to execute the sequence. When a job is finished, the dispatcher removes it from the job list.
  • the rules define how an event must be handled, depending on the attributes of the event and the system status. Each ruie defines a condition and an action, which must be carried out as soon as the event attributes and the system status meet the condition. In the event that a job is to be executed in an action, there are various subrules that determine what effects the individual job has and which executions are to be carried out. The manner in which a sequence has to do and execute when a branch point occurs depends on the system status which is present at the time of the branch point. The following rules are defined, for example:
  • the condition is: The event flag Ruie Exception is set.
  • the associated action is: Execution of the exception handler, which is defined for the special event. If the dispatcher has no exception handler for this event, an error message is sent to the component that sent the event.
  • Audio producer
  • the condition is: The event flag Audio Producer is set.
  • the associated action is: An audio producer job has started.
  • the condition is: The event flag Audio Stopper is set.
  • the associated action is: An audio stop job has started.
  • GSM Phone User Reject :
  • the condition is: The event flag GSM Phone User is set and the modem is currently in data connection.
  • An error message is sent to the sender of the event, which informs them that the modem is currently unable to establish a voice connection.
  • the condition is: The Loop Through event flag is set.
  • the associated action is: If this event has been received by the Human Machine Interface, it will be passed on to the associated service. If it has been received by a service, it is passed on to the human machine interface.
  • the sequences of actions created by a job are defined by the subrules.
  • These subrules can be very complicated, e.g. B. the audio producer job has the task to synchronize on all audio producer services, in this case it has to establish the connection between the audio sources and the audio sinks, cut existing connections and manage these connections. He also has to distribute the various error messages in different ways.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)
  • Control Of Electric Motors In General (AREA)

Abstract

Die vorliegende Erfindung beschreibt einen Service-Controller zum Einsatz in Kraftfahrzeugen, der es ermöglicht, in ein geschichtetes Softwaresystem eindeutige Zuweisungen von Hard- und Software individuell zu ermöglichen.

Description

Service-Controller für Computersvsteme, insbesondere für ein
Kraftfahrzeug
Beschreibung
Die Erfindung betrifft ein Verfahren zum Betrieb eines Service-Controllers für fahrzeugspezifische Computersysteme gemäß den Merkmalen des Anspruches 1 und Computersystem gemäß den Merkmalen des Anspruches 11.
Multitaskingsysteme und Multitaskingechtzeitsysteme sind weitläufig bekannt. So existiert beispielsweise seit Jahren das Programmiersystem Unix, mit welchem ein Multitaskingsystem realisiert werden kann. Im Weiteren existieren diverse Echtzeitbetriebssysteme, wie beispielsweise QNX. Dies ermöglicht es ein Programm in „Echtzeit" Befehle auszuführen.
Im Weiteren ist bekannt die Steuerung eines Gerätes mittels Software vorzunehmen. Hierzu wird über eine Eingabeeinrichtung am Gerät eine Funktion ausgewählt und diese wird in einen Befehl umgesetzt, welcher vom Gerät ausgeführt wird. Befinden sich jedoch in einem Kraftfahrzeug diverse zu bedienende Komponenten, so werden in der Regel einzelne Befehle nicht vom Benutzer an den Komponenten selbst initiiert, sondern an einer für mehrere Komponenten gemeinsamen Multifunktionsbedieneinrichtung. Diese Multifunktionsbedieneinrichtung vermittelt dann den einzelnen angeschlossenen Komponenten die auszuführenden Befehle und die betroffenen Komponenten führen dann diesen Befehl bzw. diese Befehle aus. Eine solche Multifunktionsbedieneinrichtung ist beispielsweise aus der WO 00/21795 bekannt.
Eine Lösungsmöglichkeit stellt das an und für sich bekannte Schichtenmodell dar. Tritt ein Befehl in einer höheren Schicht auf, beispielsweise ist in einem
Multimediasystem mit angeschlossenem Radiosystem und Verkehrsfunkdecoder und der Verkehrsfunkdecoder empfängt eine eingehende Verkehrsnachricht, so wird dies sofortig dem System mitgeteilt. Das System entzieht den laufenden Prozessen die Rechenzeit und schaltet die entsprechende Verkehrsnachricht durch.
Aus DE-A1-100 43 086 ist eine Cockpitsystemarchitektur, insbesondere für ein Kraftfahrzeug, mit mindestens einer fahrzeugspezifischen Komponente und mindestens einer Multimediakomponente bekannt. Die einzelnen Komponenten verfügen über diverse Funktionen, beispielsweise über eine Bedienfunktion, eine Anfahrtszeigefunktion, eine Signalverarbeitungsfunktion und eine Steuerfunktion, welche auf Software- und Hardwarebasis realisiert sind. Die einzelnen Funktionen der jeweiligen Komponenten sind partioniert, d. h. getrennt und funktionsweise komponentenunabhängig modular zusammengefasst.
Aus DE-C1-199 29 330 ist ein Fahrzeugkommunikationssystem mit einem Datenbus und daran angeschlossenen Komponenten offenbart. Unter den Komponenten befindet sich wenigstens eine Anzeige-/Bedieneinrichtung und eine diese steuernde Recheneinrichtung. Auf der Anzeige-/Bedieneinrichtung und/oder der diese steuernden Recheneinrichtung ist eine auf dem HTML/XML- Seitenformat basierende Oberfläche implementiert.
Die genannten Systeme weisen keine Grenzlinien zwischen dem Echtzeitbetriebssystem, dem Service und den Bedienschnittstellen, im Weiteren als Human Machine Interface oder kurz HMI bezeichnet, auf.
Aus FIG 1 ist eine Realisierungsform für heutige Infotainmentsysteme für Kraftfahrzeuge aufgezeigt. Dieses System weist ein Human Machine Interface auf und es sind weitere Einrichtungen wie Compact Disc Player, Navigation, Radio integriert bzw. angeschlossen. Diese einzelnen Einrichtungen sind in einem einzigen Gerät zusammengefasst und weisen eine gemeinsame Anzeige- und Bedieneinrichtung auf. Beispielhaft ist in FIG 2 ein weiteres derzeitig bekanntes Infotainmentsystem schematisch dargestellt, dieses System ist vergleichbar mit dem System, welches aus der bereits genannten Patentschrift DE-C1-199 29 330 bekannt ist. Dieses System weist eine Steuereinrichtung mit einem Human Machine Interface auf, welches über ein Busprotokoll bzw. ein API-Protokoll an externe Geräte wie CD-Navigation, Telefon, Radio usw. angeschlossen ist.
Aufgabe der Erfindung ist es, die starre Systemarchitektur der bekannten Multifunktionsbedieneinrichtungen aufzulösen und im Weiteren es zu ermöglichen an bestehende Systeme weitere Geräte/Anwendungen anzuschließen und/oder Komponenten zu tauschen.
Diese Aufgabe wird mit den Merkmalen der Ansprüche 1 , 11 und 21 gelöst. Weitere vorteilhafte Ausgestaltungen der Erfindung sind durch die abhängigen Ansprüche und der weiteren Beschreibung benannt.
Zur Lösung wird ein sogenannter Service-Controller integriert, welcher die Verteilung von Services zwischen dem Computersystem und einem Echtzeitbetriebssystem managt. Hierzu werden spezielle Interfaces am Service- Controller zum Human Machine Interface und zum Echtzeitbetriebssysteme implementiert, welche einen speziellen Zugriff auf die einzelnen Services des Systems ermöglichen. Auf diese Weise ist es auch möglich ein Konfliktmanagement zwischen den einzelnen Services zu erreichen.
Datenzugangsbarrieren können mehrstufig und kapselbar ausgestaltet werden, da diese für jeden Service einzeln darstellbar sind. Mehrstufig heißt, dass zu jedem vorhandenen Human Machine Interface und zu jeder Applikation, beispielsweise einem Internetzugang, ausschließlich geschützt über notwendige Zugangscodes, ein Zugriff ermöglicht wird. Dies ergibt durch eine Codierbarkeit des Systems sowie ein integriertes Management eine differenzierte Datenübertragungen auf und zu speziellen Applikationen und Services. Es werden eindeutige Zugriffsrechte zuweisbar, d. h. dass beispielweise für Internetaktivitäten, die im System laufen, die notwendigen und die ausreichenden Reserven zur Verfügung gestellt werden. Dies gewährt insbesondere eine Sicherheit gegen Hacker im Sinne einer Fire Wall. Es ist somit nicht möglich, dass ein Service auf externe, von ihm nicht benötigte Resourcen zu greifen kann.
Der Ansatz des Systems besteht darin, dass unter der vorhandenen Human Machine Interface Schnittstelle die Steuerung der
Bedienoberflächenprogrammierung und die gesamte Bediensoftware angeordnet wird. Die Bedienoberflächenprogrammierung beinhaltet z. B. Steuerungsaufgaben für die Human Machine Interface Schnittstelle, insbesondere welches Anzeigenbild und welche Tastenbelegung nach Auswahl einer Funktion angezeigt wird und welche Eingaben ein Nutzer an der Bedienoberfläche vornehmen kann. Außerdem wird durch die Human Machine Interface Schnittstelle eine Bedienlogik eingeführt, in der sowohl die Gerätesteuerung als auch die Gesamtsystemsteuerung miteinander verwoben ist. Bei der großen Komplexität des Systems können die tatsächlichen Abläufe nicht mehr, oder nur häufig sehr schwer, nachvollzogen werden. Diese hängen jedoch von den vorgegebenen Systemmöglichkeiten ab. Bei der Ausgestaltung der Bedienoberfläche ist vordefiniert, welche Funktionen ein Gerät ausführen kann und welche Funktionen für einen Nutzer bereitgestellt werden. Diese werden den aktuell am Gerät möglichen Eingaben bzw. aktuell vornehmbaren Funktionen des Gerätes zugewiesen. Diese Aufgaben übernimmt der Service Controller, in dem er vom Gerät die aktuell vorhandenen Funktionen, welche auch ausführbar sind, abruft und auf dem Human Machine Interface darstellt. Auf dem Human Machine Interface und der Anzeigevorrichtung werden nur die Funktionen angezeigt, welche auch tatsächlich vom Gerät aktuell ausführbar sind. Um dies zu verdeutlichen, wird beispielhaft an einem CD-Player dies näher erläutert. Der CD-Player hat eine CD geladen. Er ist im Zustand „Pause". Der Service-Controller signalisiert zum Human Machine Interface, dass lediglich die Funktionen „CD play", „CD auswerfen" oder in einem „Stop-Modus gehen" vorhanden sind. Weitere Funktionen sind nicht möglich und werden nicht angezeigt. Diese Informationen werden vom Gerät selbst bereitgestellt. Das Gerät überträgt zum jeweiligen Betriebsstatus seine vorhandenen und ausführbaren Funktionen dem Service-Controller. Folglich ist für einen Nutzer eindeutig zu erkennen, welche Funktionen er auswählen kann und welche Funktionen das Gerät bereitstellt. Das vorhandene Anzeigepotential auf der Anzeigevorrichtung wird auf die einzelnen, tatsächlich möglichen Funktionen zugeschnitten. Wählt ein Benutzer beispielsweise die Funktion „CD play" aus, so überwacht der Service-Controller die Ausführung des entsprechenden Befehls für den CD-Player und fragt zugleich ab, ob weitere Funktionen bzw. Funktionsanfragen vorliegen. Anschließend gibt er den Befehl über den Bus zum CD-Player aus. Dem Verstärker wird mitgeteilt, dass ab sofort der CD- Player für den Sound zuständig ist. Der CD-Player ist nunmehr die Signalquelle für die Audiodaten und der Verstärker verstärkt diese und leitet selbige an die ausgewählten Signalsenken. Zugleich schaltet der Service-Controller eine Leitung zwischen dem Verstärker und dem CD-Player. Der Service-Controller erledigt somit zwei Aufgaben zugleich, erstens dem Human Machine Interface mitzuteilen, welche Funktionen im Moment auf den Bus möglich sind, und welche Funktionen für einen Nutzer frei auswählbar sind. Zugleich steuert er die einzelnen Geräte im Bus.
Es erfolgt eine definierte Aufteilung der Systemdynamik. Im Weiteren wird auf ein dreischichtiges System die weiteren Erläuterungen gestützt, die Erfindung ist aber nicht hierauf limitiert, sondern die Beschreibung erfolgt rein beispielhaft.
Die Systemdynamik ist in drei Schichten realisiert, in denen die gesamte Systemdynamik anteilig und unabhängig bearbeitet wird. Diese drei Schichten sind:
- die Dynamik des Verhaltens, das vom User beeinflusst wird, Human Machine Interface und multimodale Eingabemöglichkeiten; - die Dynamik der Beziehung zwischen unterschiedlichen
Applikationen, wie beispielsweise dem Service Controller; - die Dynamik innerhalb einer Applikation, im Weiteren mit „Service" bezeichnet.
Um die Funktionsweise des drei Schichtenmodells zu verdeutlichen, wird dies anhand eines konkreten Beispiels, eben des Drückens eines Bedienbuttons auf der Human Machine Interface, der die Funktion „CD abspielen" zugewiesen ist, erläutert. Wird diese Schaltfläche (Button) gedrückt, geht das System sofort in den Zustand „CD play" unter der Beteiligung von gleichzeitig wechselnden Services bezüglich Verstärker, Ausgabeeinheiten usw. Dies bedeutet, dass mit dem Ausführen des funktionszugeordneten Services „CD play" weitere Services gestartet werden, welche zur Ausführung des Befehls nötig sind. Es werden somit über das Computersystem die entsprechenden Daten und benötigten Einheiten aktiviert und freigeschaltet. Bei „CD play" werden folglich die Verstärker in derart angesteuert, dass sie die Ausgangsdaten des CD-Players verstärken und an die Ausgabeeinheit bzw. Ausgabeeinheiten, insbesondere Lautsprecher weiterleiten und möglicherweise diese Daten (Lautstärke, Frequenzen) grafisch auf einem Display darstellt. Auf diese Weise ist es erstmalig möglich, die systemdynamischen Teile klar strukturiert und in Schichten darzustellen. Die Eingabe des „CD play"-Befehls wird über das Human Machine Interface, welches in der ersten Schicht abläuft, in Auftrag gegeben und geht an den Service Controller, der in der zweiten Schicht abläuft, ohne seitens des Human Machine Interface notwendigerweise die weitere Ausführung zu überwachen oder direkte Verbindung mit den weiteren Services zu haben, welche ausgeführt werden. Der Service-Controller wählt und steuert die weiteren notwendigen Funktionen.
Die Systemdynamik wird nicht wie bisher im Userinterface des Human Machine Interface abgehandelt, sondern als ein „Konfliktmanagement" im Service- Controller separat und konkret bearbeitet. Dies bedeutet, dass der Service- Controller die Steuerung der Restarbeiten übernimmt und das Human Machine Interface separat abgekoppelt ist. Mehrere gleichzeitig angesprochene Systeme werden also untereinander eine Dynamik in ihrer Abfolge haben. Diese Dynamik regelt der Service-Controller eigenständig. So würde es wenig Sinn machen, den Verstärker auszuregeln, ehe die ersten Signale zur Verstärkung anliegen. Es besteht aber auch die Möglichkeit, das alle Services gleichzeitig zur Verfügung stehen müssen, teilweise möglicherweise auch in Konflikt zueinander treten. Der Service-Controller ist als Mittel und als handelnde Instanz tätig, die unabhängig von Wissen und ggf. Wollen des Bedieners Konflikte im Vorfeld der Servicerealisierung ausräumt.
Der große Vorteil dieses Systems besteht darin, dass die Bedienlogik der einzelnen Geräte, welche angeschlossen sind, immer gleich bleiben kann, auch wenn ein neues Gerät angeschlossen wird. Der Service-Controller fragt die Bedienlogik des Gerätes ab und fügt sie selbsttätig dem System zu und bindet dieses in das Regelwerk mit den entsprechenden Regeln ein. In Ausnahmefällen muss der entsprechende Block der Bedienlogik im System selbst ausgetauscht werden. Dies erkennt jedoch der Service-Controller selbsttätig und führt diese Aufgaben aus. Hierbei fragt der Service-Controller bei Einfügung eines neuen Gerätes dessen Funktionen und dessen Bedienlogik ab und speichert sie selbsttätig. Über den Service-Controller wird mithin ein doppeltes Regelwerk geschaffen, ein gerätespezifisches Regelwerk und ein Regelwerk, das die Zusammenhänge zwischen den Geräten und Anwendungen beschreibt. Bei der Eingabe einer Funktion durch den Benutzer über das Human Machine Interface überprüft der Service-Controller, ob die Funktion nach dem vorhandenen Regelwerk zulässig, durchführbar und erzeugbar ist. Wenn die Funktion vorhanden und durchführbar ist, veranlasst er eine Befehlkaskade, die das Gesamtsystem steuert. Es werden alle Geräte in einem Zustand gesteuert, der für das Ausführen des Bedienbefehls oder einen automatischen Bedienbefehl notwendig ist. Der Service-Controller erzeugt eine regelbasierende Zusammenschau der Geräte und deren Funktionen und stellt die Abläufe selbsttätig zusammen, welche zur Ausführung notwendig sind.
In einer weiteren Ausgestaltung der Erfindung ist im Regelwerk ein Service-API vorhanden, dessen Funktionen zur Gerätesteuerung in Blöcke für verschiedene Busse unterteilt werden, beispielsweise CAN-Bus, MOST-Bus, usw. Dieses Service-API kann so auf verschiedene Busblöcke gestellt werden und diese miteinander verbinden, und zwar unabhängig von den angeschlossenen Geräten. Durch dieses Service-API ist die weitere abhängige Bedienlogik, insbesondere der Service-Controller, nicht mehr zwingend in Kenntnis zu halten, welche physikalischen Geräte die gewünschte Funktion abruft und in welcher Form diese Funktion bzw. dieser Befehl abzugeben ist. Der Service- Controller muss lediglich erkennen, welche Funktionen vorhanden sind und welche Funktionen möglich sind. Den Rest steuert dann das Service-API. Dies ermöglicht es bei Einfügung eines Gerätes in das System die Regel an lediglich einer Stelle, und zwar im Service-Controller einzufügen. Die weiteren Anbindungen nimmt dann das Service-API automatisch vor. Dadurch wird das System transparenter.
Im Folgenden wird die Regelbasierung und die Funktionsweise anhand der Besonderheiten in einem Fahrzeug erläutert.
Einzelne Applikationen können von sich aus, ohne Zutun des Benutzers, Anspruch auf Systemresourcen erheben. Wird beispielsweise während des CD- Hörens im Fahrzeug eine Verkehrsnachricht empfangen bzw. ein Traffic- Announcement ausgelöst, d.h. der Tuner erhebt Anspruch auf die Ressourcen Lautsprecher um dort die eingehende bzw. eingegangene Verkehrsnachricht auszugeben und ist im Weiteren denkbar, dass während eines Telefonats, das im Hintergrund laufenden Navigationssystem ebenfalls die Ressource Lautsprecher nutzen will, um eine notwendige Zeit- und Orts- oder Handlungsanweisung für den Fahrer auszugeben, so wurde dies bisher in Form einer hart codierten Straight-Forward-Implementierung gelöst, wobei dann direkt auf diese Ressourcen, ohne Nutzung einer Zwischeninstanz, direkt zugegriffen wird.
Bei der vorliegenden Erfindung greift hier der Service-Controller als regelbasierendes Konfliktmanagementsystem ein. Immer und in jedem Fall besteht ein vorhersehbares Verhalten des Systems. In dem oben beschriebenen Fall wird der Service-Controller eine Servicenachricht ausgeben und vorher eine Wiedergabeunterbrechung herbeiführen. Ist dann die Servicenachrichtausgabe beendet, so wird der Service-Controller die Wiedergabe der CD weiter fortführen. Im weiteren ist über den Service- Controller nunmehr möglich, Übergänge von Servicezuständen, von Applikationen, Geräten, Sensoren, Tunern, welche nicht rechtzeitig erfolgen, sondern eine gewisse Übergangs- oder Startzeit benötigen, zu regeln. Die Erfassung und Controllerüberwachung der vorgenannten Zeit-, Zulassungs- und Aktivitätsrahmen erfolgt nach vorgegebenen Regeln für die einzelnen Services selbst, losgelöst vom Konfliktmanagement zwischen den verschiedenen Services und von den Eingaben des Benutzers über das Human Machine Interface. Für jeden der drei Bereiche, wie oben geschildert, in eigener, neugeschaffener Softwareinstanz werden Priorität anhand von Software- Instanzen abgehandelt bzw. verarbeitet. Auf diese Weise werden die bisherigen Probleme, dass ein Benutzer von einem Systemabsturz ausgeht, umgangen. Es kann keine Blockade mehr entstehen, weil die unterschiedlichen Dynamikbereiche, wie oben beschrieben, in unterschiedlichen Softwareinstanzen aufgearbeitet werden. Das scheinbar unlogische Verhalten oder Systemverhalten wird dadurch vermieden, dass der Service-Controller in der Lage ist den aktuell gewünschten Applikationszustand zu differenzieren und zu bewirken.
Durch die klare Aufteilung der Systemdynamik in getrennte Softwarelayer, eben in mehrere Dynamikschichten, können einzelnen Schichten auf unterschiedlichen Prozessoren oder sogar unterschiedlichen Betriebssystemen laufen. Auf diese Weise kann z. B. der Service-Controller auf einem QNX- basierten Rechner, das Human Machine Interface auf einem Windows-CE basierten Rechner ablaufen und der Service-Controller managt dann die Konflikte, die hierbei auftreten, eigenständig. Auf diese Weise können Multiprozessorsysteme konfliktfrei gemanagt werden. Die Systemschnittstellen, insbesondere die Schnittstellen zwischen dem Human Machine Interface, dem Service-Controller und Applikationen sind streng nachrichten-basierend.
Die Implementierungsmöglichkeit auf Multiprozessorsysteme mit unterschiedlichen Betriebssystemen ist gewährleistet.
Mehrere Human Machine Interface Instanzen, wie für Fahrer, Beifahrer-, Passagiere und sogar komplett verschiedene Applikationen können von einem Service-Controller dieser Softwarearchitektur gemanagt werden. Das Human Machine Interface kann sogar über ein Wide Area Network abgekoppelt werden, so dass Services im Sinn der Fernwaltung möglich sind. Außerdem besteht die Möglichkeit der Fernsteuerung des Fahrzeugs von außerhalb, sowie End-to-End-Lösungen von Applikationen ohne Fahrerbeteiligung, um beispielsweise automatische Servicenachrichten vom Fahrzeug zum Provider zu ermöglichen. Eine automatische Autorisierung und/oder Wartung der Fahrzeuge, eine Fernwartung einer fahrzeuginternen Datenbank, ebenso wie die Vorgaben von Navigationszielen, wie beispielsweise bei Fahrzeugflotten- Management, ist somit von extern möglich.
Das System wird dadurch standardkonform einfach darstellbar, weil standardisierte Protokolle, wie z. B. TPC/IP verwendet werden können.
Das System bietet Freiheiten in der Implementierungstechnik, es können unterschiedliche Schichten und unterschiedliche Services in verschiedenen Programmiersprachen wie z. B. C, CH, C# (C-Sharp), Java, XML programmiert sein.
Durch diese formale Architekturdefinition ist eine Unabhängigkeit von konkreten Echtzeitbetriebssystemen und von der Prozessorart gegeben. Daher kann wesentlich einfacher das bisher auf Echtzeitbetriebssysteme basierende System auch partioniert werden, ohne notwendigerweise die Mikroprozessorart zu kennen.
Das Systemkonzept erlaubt obendrein an der messagebasierenden Schnittstelle eine Einbindung eines OSGI-Frameworks (Open System Gateway Initiative). Damit ist eine erhebliche Systemerweiterbarkeit unter Verwirklichung strenger Sicherheitsanforderung an den Zugangsrechten und die Kapselung von Services, möglich.
Im weiteren wird die Erfindung anhand eines konkreten Ausführungsbeispiels anhand der Figuren FIG 3 bis FIG 5 näher erläutert.
Es zeigt:
FIG 3 ein erfindungsgemäßes Schichtenmodell,
FIG 4 die Komponenten eines Service-Controllers und
FIG 5 eine Struktur eines Service-Controllers.
In FIG 3 wird ein Schichtenmodell beschrieben. Der Human Machine Interface Layer (Human Machine Interface Layer), auch mit Skin- oder GUI-Layer bezeichnet, steuert die graphische Ausgabe und die Anzeige des Human Machine Interface (HMI), das Design und die logisch Struktur.
Der darunterliegende Service-Layer ist der mittlere Teil des Systems. Jede physikalische Einheit im System ist durch eine oder mehrere Services (logische Einheiten) repräsentiert. Beispielsweise gibt es einen Phoneservice, einen CD- Player-Service usw. Diese Services bieten einen hardwareunabhängigen Funktionssatz von Befehlen, beispielsweise den Befehl „Telefonnummer 123 wählen" oder „CD-Player spiele Lied 3 ab". Die wichtigste Komponente im Service-Layer ist der Service-Controller, welcher die Services untereinander verwaltet und steuert und als eigentliche Headunit zentral die Services verwaltet. Auf den Service-Controller wird im Weiteren näher eingegangen werden.
Als dritte Schicht schließt sich der Protokoll-Layer an, welcher die Software- Komponenten, insbesondere beispielsweise die Protokolle für die fahrzeuginterne Kommunikation an einem Multimediabussystem, wie MOST oder Fire Wire aufweist und zugleich das Interface zwischen Soft- und Hardware darstellt.
Um den Funktionsumfang, den ein Service anbietet, zu nutzen, sendet das Human Machine Interface eine geeignete Nachricht zum Service-Controller. Das vorgegebene Protokoll, welches diese Nachricht definiert, wird als sog. Multimedia-Interprozesskommunications-Protokoll (MIC-Protokoll) bezeichnet. Es existiert ein Applikation Programming Interface zum Versenden und zum Empfangen von Nachrichten, welches SERAPI (SERvice API) genannt wird und im Weiteren näheren beschrieben wird. Das Human Machine Interface hat keinen direkten Zugriff auf den Services und die Hardware.
Die strenge Trennung zwischen Human Machine Interface Service und Protokoll-Layer hat diverse Vorteile. Einer dieser Vorteile ist die hohe Abstraktion des Systems. Das System bietet dem Human Machine Interface ein Interface, welches komplett hard- und softwareunabhängig und auch unabhängig von Protokollen ist. Dies bedeutet, dass das Human Machine Interface, welches beispielsweise auf einer MOST-Multimediaeinheit läuft, ebenso auf einem System, welches auf Fire Wire-Basis beruht, funktionsfähig ist, ohne irgendwelche Adaption. Auf der anderen Seite ist die logische Struktur des Userinterface komplett gekapselt und auf den Human Machine Interface Layer begrenzt. Dies ermöglicht es sehr einfach das komplette Design und das „Look and Feel" des Systems im Human Machine Interface zu verändern und zu ersetzen, ohne die tieferliegenden Schichten hierbei anzutasten. Natürlich ist somit auch ermöglicht, die Entwicklung und die neue Implementierung von einzelnen Services und von einzelnen Layern systemabhängig zu gestalten.
Im Weiteren wird nunmehr auf den Service-Controller eingegangen. Unter anderem, hat ein Multimediasystem folgende Eigenschaften zu erfüllen:
- einen einfachen Weg zu realisieren, um an ein Interface adaptierbar zu sein, ohne aufwendige Anpassungsarbeiten;
- Teilentwicklungen zu unterstützen und einen Test von Softwarekomponenten zu ermöglichen;
- einen einfachen Weg aufzuzeigen, das System mit erweiterbaren Komponenten ausstattbar zu machen.
Wie bereits aufgezeigt, läuft das Human Machine Interface in einer separierten Schicht, dem Human Machine Interface-Layer. Es kann daher als separate Einheit getestet und entwickelt werden. Um das System jedoch einfach an die spezifischen Eigenschaften der Hardware anzupassen, ist es notwendig, die Software modular auszugestalten. Diese Modularität wird durch die Entwicklung und Einführung eines Services ermöglicht. Jeder Service hat die Möglichkeit Zugriff und Kontrolle über die physikalischen und tatsächlich am System vorhandenen Einheiten zu erhalten und ermöglicht ein hardwareunabhängiges Interface zum jeweiligen Upper Layer, beispielsweise dem Human Machine Interface. Einige dieser Services sind abhängig von anderen Services oder aber sie benötigen exklusiven Zugriff auf die Hardware. Dies bedeutet, dass eine Softwarekomponente notwendig ist, welche steuernd und synchronisierend den Service steuert und ein Interface zwischen dem Human Machine Interface- Layer und dem Service-Interface aufbaut. Diese Komponente ist der Service- Controller.
Andererseits ist es somit auch möglich, einen Eventgenerator an den Service- Controller anzuschließen, welcher es ermöglicht, sämtliche Testszenarien automatisch auszuführen. Dies ermöglicht eine tiefere und extensivere und schnellere Testmöglichkeit, wie dies es bisher nicht möglich ist.
Wie bereits ausgeführt, besteht das System aus unzähligen aktuell laufenden Prozessen und Threads. Um eine Kommunikation untereinander zu ermöglichen, senden diese Nachrichten aus, welche durch das MIC-Protokoll definiert sind. Hervorgerufen durch die teilweise sehr langen Antwortzeiten von einigen Multimediakomponenten ist das MIC-Protokoll asynchron aufgebaut. Es gibt viele Situationen, beispielsweise während der Initialisierungsphase, bei welchen es notwendig ist, die einzelnen Komponenten zu synchronisieren. Es ist die Aufgabe des Service-Controllers diese Synchronisation durchzuführen und aufrecht zu erhalten.
Ein Multimediasystem besteht zumeist aus Hardwareeinheiten, welche ausschließlich exklusiven Zugriff erlauben. Wenn diverse Services Zugriff auf solch eine Hardware benötigen, ist es die Aufgabe des Service-Controllers diese Probleme und die hierbei auftretenden Konflikte zwischen den Services zu lösen. Dies gilt auch in Fällen, in welchen parallel Zugriff möglich, jedoch nicht unbedingt notwendig ist.
Eine Anzahl von möglichen Events initialisiert eine Sequenz von Aktionen, welche in unterschiedlichen Services auszuführen sind, wobei aber die Sequenz der Aktion sehr wichtig ist. Der Erfolg oder das Fehlschlagen von einer Aktion beeinflusst die folgenden Aktionen. Um es noch komplizierter darzustellen, mag es in gewissen Bereichen möglich und notwendig sein, dass eine zeitliche Ausführung eines Events vor einem anderen notwendig ist, ehe diese Aktion durchgeführt werden kann. Dies bedeutet, dass möglicherweise parallel zu agieren ist, außerdem muss gewährleistet sein, dass dieses parallele Arbeiten untereinander frei oder ggf. auch nicht frei von Einfluss bleiben. Der Service-Controller löst diese Aufgabe, indem er das Eventhandling koordiniert und ausführt in der Weise, dass die vorgegebenen Eigenschaften erfüllt sind. Anhand von Figur 4 werden die Hauptkomponenten des Service-Controllers und dessen Struktur aufgezeigt. Der Service-Controller besteht aus drei Hauptkomponenten, die immer in Betrieb sind, und zwar im Parallelbetrieb. Der Down-Thread, der Up-Thread und der Main-Thread. Der Down-Thread und der Up-Thread haben die Aufgabe, Nachrichten vom Human Maschine Interface und von den Services zu empfangen und sie in einer zentralen Queue zu speichern. Unabhängig davon ist es möglich, eine Vorfilterung und ein Vorhandling der Nachrichten auszuführen, welche in einem Teil des Service- Controllers durchgeführt werden. Der Main-Thread nimmt die Nachrichten aus der Queue und führt diese aus und verwaltet sie.
Die Message Queue, wie oben aufgezeigt, ist eine komplizierte Struktur. Sie besteht aus verschiedenen Queues, welche unterschiedliche Größe haben können. Jede Queue ist mit einer eigenen Priorität ausgestattet. Der Receivingthread ermittelt die Priorität des Events und speichert diese in der Appropriate Queue.
Im weiteren wird anhand von Figur 5 der weitere Aufbau des Service- Controllers erläutert. Der Service-Controller weist einen Dispatcher auf. Dieser Dispatcher läuft im Main-Thread und verwaltet die Events und Ereignisse. Er überwacht und speichert den aktuellen Stand der einzelnen Systemkomponenten. Beispielsweise in einem System mit einem GSM-Modem überwacht er, ob der Phoneservice Zugriff auf das Modem hat oder ob ein Anruf ansteht oder ob der IP-Service das Modem aktuell nutzt, um eine Internetverbindung aufzubauen.
Es ist wichtig, dass der Dispatcher nicht alle Systemzustände überwacht, er überwacht lediglich diejenigen Zustände, welche Einfluss darauf haben, ob ein Event ausführbar ist oder nicht. Die Entscheidung, auf welche Art und wann ein Event ausgeführt ist und/oder ausführbar ist, ist an diverse Events gekoppelt. Im Falle, dass ein Event eine Anzahl weiterer Aktionen veranlasst, erzeugt der Dispatcher einen neuen Job, der dieses Event verwaltet. Der Dispatcher speichert eine Liste der aktiven Jobs ab.
Im Weiteren wird auf die Funktionalität näher eingegangen. Der Service- Controller entscheidet zwischen zwei Zuständen bzw. Phasen, der Initalisierungsphase und der Betriebsphase. Während der Initialisierungsphase berichtet jeder Service und das Human Maschine Interface direkt dem Service- Controller. Anschließend initialisiert der Service-Controller die Kommunikation zu jedem einzelnen Prozess. Der Service-Controller liest aus dem Konfigurationsfile, wessen Services notwendig sind, um ein lauffähiges System zu erhalten. Wenn alle notwendigen Services und das Human Maschine Interface registriert sind, erhält jeder Prozess eine Nachricht vom Service Controller, dass das System sich nunmehr in Betrieb befindet. Haben nach einer definierten Zeit nicht alle Services geantwortet, dann entscheidet der Service-Controller von selbst, ob ein beschränkter Betrieb möglich ist oder ob das System nicht lauffähig ist.
Im Folgenden wird das Eventhandling näher beschrieben. Das System kennt eine große Anzahl von Events. Die Art und Weise, in welcher ein Event behandelt wird, hängt von verschiedenen Systemstadien ab. Nichts desto trotz werden diverse Events gleich behandelt. Um das Eventhandling zu vereinfachen und um für zukünftige Erweiterungen offen zu sein ist eine definierte Abstraktion eingeführt. Es sind einige Event-Attribute eingeführt und eine Anzahl Regeln, welche definieren, auf welche Art und Weise ein Event abzuhandeln ist, basierend auf den Attributen.
Der Service-Controller hat eine Tabelle, eine sogenannte Infotabelle, welche einige Informationen für jedes definierte Event aufweist. Diese Information besteht aus einer Priorität, mit welcher das Event auszuführen ist, und
Eventattributen, welche auch als Event-Flags bezeichnet werden. Es ist möglich, dass ein Event diverse Kombinationen verschiedener Attribute aufweist.
Die folgenden Events bzw. Attribute sind definiert:
Loop Through, Audio Producer, Audio Stopper, GSM Phone User, GSM Releaser und Rule Exception.
Diese Attribute haben folgende Bedeutung:
Loop Through:
Ein Event mit diesem Flag wird vom Service-Controller zum zugehörigen
Service oder zum Human Maschine Interface durchgereicht.
Audio Producer:
Dieses Flag gibt dem Service-Controller die Mitteilung, dass dieses Event verschiedene Audioausgaben starten wird.
Audio Stopper: Dieses Flag teilt dem Service-Controller mit, dass das Event seine Audioausgaben beendet.
GSM Phone User:
Der Service-Controller erhält die Nachricht, dass ein derartiges Event nur korrekt ausführbar ist, wenn das GSM-Modem bereit ist für eine Verbindungseröffnung.
GSM Releaser:
Dieses Event-Attribut bedeutet, dass der Service seinen Zugriff auf das GSM- Modem aufgibt. Ruie Exception:
Dieses Flag wird dann gesetzt, wenn ein Event nicht verwaltet oder ausgeführt werden kann, in Abhängigkeit der vorausgenannten Regeln. Für jede Ruie exception muss der Dispatcher eine Funktion aufweisen, welche dieses spezielle Event verwaltet.
Wenn der Up-Thread ein Event empfängt, so entnimmt er aus der Infotabelle für die Prioritäten dieses Events die zugehörige Priorität und speichert sie in der zugehörigen Queue. Die Events des Human Maschine Interface, welche vom Down-Thread empfangen werden, bekommen stets die höchste Priorität. Der Dispatcher wird aktiv, solange die Queues nicht leer sind. Er holt das nächste Event, wobei er natürlich zuerst in den Queues nachsieht und das Event entnimmt, welches die höchste Priorität hat. Wenn diese Queue leer ist, nimmt er das älteste Element aus der Queue mit der niedrigsten Priorität usw. Anschließend überprüft der Dispatcher, ob der Service, an welchen das Event adressiert ist, ein Teil des laufenden Systems ist. Wenn dies nicht der Fall ist, wird eine Fehlernachricht versendet. Dann geht der Dispatcher durch die Regelliste und überprüft, ob das Event eine Ruie condition hat. Wenn verschiedene Bedingungen zutreffen, alle zugehörigen Aktionen ausgeführt sind, ausgenommen, es handelt sich um ein Ruie Exception Event, wird lediglich der Exceptionhandler für dieses spezifische Event ausgeführt. Nachdem alle Ruie Conditions überprüft sind, geht der Dispatcher durch die Jobliste und setzt die aktiven Jobs fort. Anschließend holt der Dispatcher das nächste Event aus der Queue.
Wie bereits ausgeführt kann ein Event eine Sequenz von Aktionen nach sich ziehen, welche notwendigerweise auszuführen sind. Aufgrund des asynchronen Verhaltens des Systems ist es notwendig an einem definierten Punkt eine Sequenz auf eine Nachricht abzuwarten, bevor die Sequenz komplett beendet werden kann. Dies bedeutet, dass der Dispatcher in die Lage versetzt sein muss neue Events zu empfangen, noch ehe das erste Event komplett abgearbeitet und beendet ist. Diese Art von Events werden in einem Job ausgeführt. Wenn der Dispatcher einen Job aufruft, so führt er diese Sequenz soweit als möglich aus. Bis der Dispatcher alle Jobs aufruft wird jedesmal ein neues Event empfangen, in diesem Fall kann der Job selbst überprüfen, ob die Bedingung, auf welche er wartet, eingetroffen ist - durch das neue eingegangene Event - und der Job selbst kann die Sequenz weiter durchführen. Wenn ein Job beendet ist, entfernt der Dispatcher diesen von der Jobliste.
Die Rules definieren, wie ein Event behandelt werden muss, in Abhängigkeit von den Attributen des Events und dem Systemstatus. Jede Ruie definiert eine Bedingung und eine Aktion, welche ausgeführt werden muss, sobald die Event Attribute und der Systemstatus die Bedingung treffen. Im Falle, dass in einer Aktion ein Job auszuführen ist, existieren diverse Subrules, welche festlegen, was der einzelne Job für Auswirkungen hat und welche Ausführen veranlasst sind. Die Art und Weise, was eine Sequenz bei Eintritt eines Verzweigungspunktes zu tun und auszuführen hat, ist abhängig vom Systemstatus, welcher zum Zeitpunkt des Verzweigungspunkte vorliegend ist. Folgende Rules sind beispielsweise definiert:
Exception: Die Bedingung ist: Das Event-Flag Ruie Exception gesetzt ist.
Die zugehörige Aktion ist: Ausführung des Exceptionhandlers, welcher für das spezielle Event definiert ist. Wenn der Dispatcher keine Exception Handler für dieses Event hat, wird eine Fehlermeldung an diejenige Komponente gesendet, die das Event ausgesendet hat.
Audio Producer:
Die Bedingung ist: Das Event-Flag Audio Producer ist gesetzt.
Die zugehörige Aktion ist: Ein Audio Producer Job ist gestartet.
Audio Stopper:
Die Bedingung ist: Das Event-Flag Audio Stopper ist gesetzt. Die zugehörige Aktion ist: Ein Audiostopperjob ist gestartet. GSM Phone User Reject:
Die Bedingung ist: Das Event-Flag GSM Phone User ist gesetzt und das Modem ist aktuell in Datenverbindung.
Die zugehörige Aktion ist: Dem Aussender des Events wird eine Fehlermeldung gesendet, welche diesem mitteilt, dass das Modem momentan nicht in der Lage ist eine Sprachverbindung aufzubauen.
Loop Through:
Die Bedingung ist: Das Event-Flag Loop Through ist gesetzt. Die zugehörige Aktion ist: Wenn dieses Event vom Human Maschine Interface empfangen wurde, wird dieses zum zugehörigen Service durchgereicht. Wenn es von einem Service empfangen wurde, wird es zum Human Maschine Interface durchgereicht.
Wie bereits aufgezeigt, sind die Sequenzen auf Aktionen, welche von einem Job erzeugt werden, definiert durch die Subrules. Diese Subrules können durchaus sehr kompliziert sein, z. B. der Audio Producer Job hat die Aufgabe auf allen Audio Producer Services zu synchronisieren, er muss in diesem Fall die Verbindung zwischen den Audioquellen und den Audiosenken herstellen, bestehende Verbindungen kappen und diese Verbindungen verwalten. Außerdem muss er die diversen Fehlermeldungen auf unterschiedliche Weise verteilen.

Claims

Patentansprüche:
1. Verfahren zur Verwaltung und/oder Ausführung einzelner Prozesse bzw. Funktionen, insbesondere eines Computersystems in einem Kraftfahrzeug, wobei das Computersystem in einer Layerstruktur realisiert wird, dadurch gekennzeichnet, dass mindestens drei voneinander unabhängige Layer (HMI Layer, Service Layer, Protokoll Layer) implementiert werden, wobei im ersten Layer (HMI Layer) das Human Machine Interface realisiert wird, im zweiten Layer (Service Layer) ein Controller (Service-Controller) realisiert wird, von welchem Prozesse bzw. Funktionen, welche Daten zwischen oder innerhalb der Layer (HMI Layer, Service Layer, Protokoll Layer) austauschen und/oder übergeben und/oder Funktionen in einem der anderen der Layer (HMI Layer, Service Layer, Protokoll Layer) oder im eigenen Layer (HMI Layer, Service Layer, Protokoll Layer) initiieren, gesteuert werden und im dritten Layer (Protokoll Layer) Schnittstellen zu und zwischen Komponenten des Computersystems gesteuert werden.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass vom ersten Layer (HMI Layer) ein erster Sub-Layer (Skin Sublayer) und ein zweiter Sub-Layer (Logik Sublayer) gesteuert wird.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass vom ersten Sublayer (Skin Layer) verschiedene erste Services (Service 1 Skin, Service 2 Skin, Service 3 Skin) bearbeitet werden und vom zweiten Sub-Layer (Logik Sublayer) verschiedene zweite Services (Service 1 Logik, Service 2 Logik, Service 3 Logik) initiiert und/oder gesteuert werden.
4. Verfahren nach einem oder mehreren der vorherigen Ansprüche, dadurch gekennzeichnet, dass zwischen dem ersten Sub-Layer (Skin Layer) des ersten Layers (HMI Layer) und dem Controller (Service Controller) ein Hauptlogik-Controller (Main Logic) zur Steuerung der Prozesse angeordnet wird.
5. Verfahren nach einem oder mehreren der vorherigen Ansprüche, dadurch gekennzeichnet, dass vom Controller (Service Controller) des zweiten Layers (Service Layer) Eingaben und Ausgaben des ersten Layers (HMI Layer) den ersten Services (Service 1 Skin, Service 2 Skin, Service 3 Skin) des ersten Sub-Layers und den zweiten Services (Service 1 Logik, Service 2 Logik, Service 3 Logik) des zweiten Sub-Layers (Logic Layer) im Service-Layer einzelne Services (Service 1 , Service 2, Service 3) im zweiten Layer (Service Layer) zugeordnet werden.
6. Verfahren nach einem oder mehreren der vorherigen Ansprüche, dadurch gekennzeichnet, da die Services (Service 1 , Service 2, Service 3) des zweiten Layers (Service Layer) über Protokollmodule (Protokoll 1 , Protokoll 2) im dritten Layer (Protokoll Layer) verbunden werden und über die Protokollmodule (Protokoll 1 , Protokoll 2) des dritten Layers (Protokoll Layer) über Interfaces (Interface 1 , Interface 2) umgesetzt werden.
7. Verfahren nach einem oder mehreren der vorherigen Ansprüche, dadurch gekennzeichnet, dass im zweiten Layer (Service Layer) ein weiterer Service (User-Input-Service) implementiert ist, welchem im dritten Layer (Protokoll Layer) ein weiteres Interface (Interface 3, Input) zugeordnet wird.
8. Verfahren nach einem oder mehreren der vorherigen Ansprüche, dadurch gekennzeichnet, dass vom Controller (Service Controller) im zweiten Layer (Service Layer) Prozesse und Threads aktiviert und gesteuert werden.
9. Verfahren nach dem oder mehreren der vorherigen Ansprüche, dadurch gekennzeichnet, dass eine Nachricht vom Human Machine Interface (down-thread) des ersten Layers (HMI Layer) vom Controller (Service Controller) des zweiten Layers (Service Layer) in einer ersten Liste (priority queues) eingetragen wird und eine Service- Nachricht (up-thread) vom dritten Layer (Protokoll Layer) ebenfalls in der ersten Liste (priority queues) eingetragen wird und aus der ersten Liste (priority queues) die einzelnen dort abgelegten Nachrichten (down-thread, up-thread) nach dem Zeitpunkt der Eintragung weiterverarbeitet werden und Mittel zur Auswahl der Art der Weiterverarbeitung (dispatcher) vorhanden sind und in Reaktion auf die Mittel auszuführende Prozesse (main-threads) in eine zweite Liste (joblist) eingetragen werden und von den Mitteln (dispatcher) Nachrichten an den ersten und dritten Layer (HMI Layer, Protokoll Layer) versendet werden, welche über den Status der Nachrichten und der abhängigen Prozesse (main- treads) Statusinformationen enthalten.
10. Verfahren nach dem oder mehreren der vorherigen Ansprüche, dadurch gekennzeichnet, dass
Nachrichten (down-thread, up-tread) in die erste Liste (priority queues) gepushed werden und Nachrichten (down-thread, up-thread) aus der ersten Liste (priority queues) von den Mitteln (dispatcher) gepoped werden.
11. Computersystem, insbesondere in einem Kraftfahrzeug, wobei das Computersystem eine Layerstruktur aufweist, dadurch gekennzeichnet, dass mindestens drei voneinander unabhängige Layer (HMI Layer, Service Layer, Protokoll Layer) vorgesehen sind, wobei im ersten Layer (HMI Layer) das Human Machine Interface realisiert ist, im zweiten Layer (Service Layer) ein Controller (Service-Controller) realisiert ist, von welchem Prozesse bzw. Funktionen, welche Daten zwischen oder innerhalb der Layer (HMI Layer, Service Layer, Protokoll Layer) austauschen und/oder übergeben und/oder Funktionen in einem der anderen der Layer (HMI Layer, Service Layer, Protokoll Layer) oder im eigenen Layer (HMI Layer, Service Layer, Protokoll Layer) initiieren, gesteuert werden und im dritten Layer (Protokoll Layer) Schnittstellen zu und zwischen Komponenten des Computer-Systems realisiert sind.
12. Computersystem nach Anspruch 11 , dadurch gekennzeichnet, dass vom ersten Layer (HMI Layer) ein erster Sub-Layer (Skin Sublayer) und ein zweiter Sub-Layer (Logik Sublayer) steuerbar ist und/oder gesteuert werden.
13. Computersystem nach Anspruch 12, dadurch gekennzeichnet, dass vom ersten Sublayer (Skin Layer) verschiedene erste Services (Service 1 Skin, Service 2 Skin, Service 3 Skin) bearbeitbar sind und/oder bearbeitet werden und vom zweiten Sub-Layer (Logik Sublayer) verschiedene zweite Services (Service 1 Logik, Service 2 Logik, Service 3 Logik) initiierbar und/oder steuerbar sind und/oder initiiert und/oder gesteuert werden.
14. Computersystem nach Anspruch 12 oder 13, dadurch gekennzeichnet, dass zwischen dem ersten Sub-Layer (Skin Layer) des ersten Layers (HMI Layer) und dem Controller (Service Controller) ein Hauptlogik-Controller (Main Logic) zur Steuerung der Prozesse angeordnet ist.
15. Computersystem nach einem oder mehreren der vorherigen Ansprüche 12 bis 14, dadurch gekennzeichnet, dass vom Controller (Service Controller) des zweiten Layers (Service Layer) Eingaben und Ausgaben des ersten Layers (HMI Layer) den ersten Services (Service 1 Skin, Service 2 Skin, Service 3 Skin) des ersten Sub-Layers und den zweiten Services (Service 1 Logik, Service 2 Logik, Service 3 Logik) des zweiten Sub-Layers (Logic Layer) im Service-Layer einzelne Services (Service 1 , Service 2, Service 3) im zweiten Layer (Service Layer) zuordbar sind und/oder zugeordnet werden.
16. Computersystem nach einem oder mehreren der Ansprüche 11 bis 15, dadurch gekennzeichnet, dass die Services (Service 1 , Service 2, Service 3) des zweiten Layers (Service Layer) über Protokollmodule (Protokoll 1 , Protokoll 2) im dritten Layer (Protokoll Layer) verbunden sind und/oder verbindbar sind und über die Protokollmodule (Protokoll 1 , Protokoll 2) des dritten Layers (Protokoll Layer) über Interfaces (Interface 1 , Interface 2) umsetzbar sind und/oder umgesetzt sind.
17. Computersystem nach einem oder mehreren der Ansprüche 11 bis 16, dadurch gekennzeichnet, dass im zweiten Layer (Service Layer) ein weiterer Service (User-Input-Service) implementiert ist, welchem im dritten Layer (Protokoll Layer) ein weiteres Interface (Interface 3, Input) zuordbar und/oder zugeordnet ist.
18. Computersystem nach einem oder mehreren der Ansprüche 11 bis 17, dadurch gekennzeichnet, dass der Controller (Service Controller) des zweiten Layer (Service Layer) derart ausgebildet ist, dass vom Controller (Service Controller) Prozesse und Threads aktivierbar und steuerbar sind und/oder aktiviert und gesteuert werden.
19. Computersystem nach einem oder mehreren der Ansprüche 11 bis 18, dadurch gekennzeichnet, dass eine Nachricht vom Human Machine Interface (down-thread) des ersten Layers (HMI Layer) vom Controller (Service Controller) des zweiten Layers (Service Layer) in einer ersten Liste (priority queues) eintragbar ist und/oder eingetragen wird und eine Service-Nachricht (up-thread) vom dritten Layer (Protokoll Layer) ebenfalls in der ersten Liste (priority queues) eintragbar ist und/oder eingetragen wird und aus der ersten Liste (priority queues) die einzelnen dort abgelegten Nachrichten (down-thread, up-thread) nach dem Zeitpunkt der Eintragung weiterverarbeitbar sind und/oder weiterverarbeitet werden und Mittel zur Auswahl der Art der Weiterverarbeitung (dispatcher) vorhanden sind und in Reaktion auf die Mittel auszuführende Prozesse (main-threads) in eine zweite Liste (joblist) eintragbar sind und/oder eingetragen werden und von den Mitteln (dispatcher) Nachrichten an den ersten und dritten Layer (HMI Layer, Protokoll Layer) versendbar sind und/oder versendet werden, welche über den Status der Nachrichten und der abhängigen Prozesse (main-threads) Statusinformationen enthalten.
20. Computersystem nach Anspruch 19, dadurch gekennzeichnet, dass
Nachrichten (down-thread, up-thread) in die erste Liste (priority queues) pushbar sind und/oder gepushed werden und Nachrichten (down-thread, up- thread) aus der ersten Liste (priority queues) von den Mitteln (dispatcher) popbar sind und/oder gepoped werden.
21. Computerprogrammprodukt, das direkt in eine oder mehrere interne Speichereinrichtungen eines Computersystems ladbar ist und Programmabschnitte umfaßt, mit denen die Verfahrensschritte gemäß einem der Ansprüche 1 bis 10 ausgeführt werden und/oder ausführbar sind, wenn das Programmprodukt im Computersystem läuft.
EP03742455A 2002-02-22 2003-02-15 Service-controller für computersysteme, insbesondere für ein kraftfahrzeug Withdrawn EP1483666A2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
DE10207644 2002-02-22
DE10207644 2002-02-22
DE10233488 2002-07-24
DE10233488A DE10233488A1 (de) 2002-02-22 2002-07-24 Service-Controller für Computersysteme, insbesondere für ein Kraftfahrzeug
PCT/EP2003/001534 WO2003070505A2 (de) 2002-02-22 2003-02-15 Service-controller für computersysteme, insbesondere für ein kraftfahrzeug

Publications (1)

Publication Number Publication Date
EP1483666A2 true EP1483666A2 (de) 2004-12-08

Family

ID=27758410

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03742455A Withdrawn EP1483666A2 (de) 2002-02-22 2003-02-15 Service-controller für computersysteme, insbesondere für ein kraftfahrzeug

Country Status (3)

Country Link
EP (1) EP1483666A2 (de)
JP (1) JP4301957B2 (de)
WO (1) WO2003070505A2 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ITGE20110085A1 (it) * 2011-08-03 2013-02-04 Datamar S R L Estensione delle funzionalità di un application server a tre strati
KR102711206B1 (ko) * 2019-06-14 2024-09-27 현대자동차주식회사 자동차 및 그를 위한 사용자 설정 메뉴 관리 방법
CN110795454A (zh) * 2019-10-31 2020-02-14 中国农业银行股份有限公司 一种服务请求方法、装置、服务器及存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19739357B4 (de) * 1997-09-08 2016-06-23 Leopold Kostal Gmbh & Co. Kg Datenein- und Ausgabegerät für Kraftfahrzeuge sowie Verfahren zum Überwachen und Steuern von in einem Kraftfahrzeug befindlichen Funktionsmodulen
CN100347005C (zh) 1998-10-15 2007-11-07 大众汽车有限公司 汽车中的多功能显示操纵设备及其操作方法
US6154210A (en) * 1998-11-25 2000-11-28 Flashpoint Technology, Inc. Method and system for implementing button interface compatibility in touch-screen equipped digital imaging device
DE19929330C1 (de) 1999-06-26 2001-05-10 Siemens Ag Fahrzeugkommunikationssystem mit Anzeige-/Bedieneinheit
US6559773B1 (en) * 1999-12-21 2003-05-06 Visteon Global Technologies, Inc. Reconfigurable display architecture with spontaneous reconfiguration
DE10043086C5 (de) 2000-09-01 2009-07-30 Robert Bosch Gmbh Cockpitsystemarchitektur

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO03070505A2 *

Also Published As

Publication number Publication date
JP4301957B2 (ja) 2009-07-22
WO2003070505A3 (de) 2004-08-26
JP2005537529A (ja) 2005-12-08
WO2003070505A2 (de) 2003-08-28

Similar Documents

Publication Publication Date Title
EP0207255B1 (de) Anordnung zum Bedienen und Warten einer Fernmelde- insbesondere Fernsprechvermittlungsanlage
DE202008016892U1 (de) Kraftfahrzeug-Steuervorrichtung
EP2098926A1 (de) Verfahren und Vorrichtung zum Programmieren und/oder Konfigurieren einer Sicherheitssteuerung
DE60109060T2 (de) Interkommunikationsvorprozessor
EP0807883A2 (de) Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen
DE19930158A1 (de) System und Verfahren zum Sammeln von Programmregistrierungen für Ereignisbenachrichtungen
EP2478436A1 (de) Verfahren und system zur verwendung von temporären exklusiven sperren für parallele betriebsmittelzugriffe
EP1854022B1 (de) Steuergerät mit konfigurierbaren hardwaremodulen
DE102006010400B4 (de) Verfahren zur Erstellung eines optimierten Ablaufplans für ein zeitgesteuertes verteiltes Rechnersystem
WO2003070505A2 (de) Service-controller für computersysteme, insbesondere für ein kraftfahrzeug
DE10233488A1 (de) Service-Controller für Computersysteme, insbesondere für ein Kraftfahrzeug
DE102021209627A1 (de) System und Verfahren zum Ausführen von funktional gleichen Applikationen
WO2006094629A1 (de) Vorrichtung und verfahren zur abarbeitung priorisierter steuerungsprozesse
EP2169485B1 (de) Konfigurationseinrichtung zur Konfiguration eines zeitgesteuerten Bussystems
EP2402202B1 (de) Verfahren zum Betrieb eines wenigstens eine Information an einen Fahrer ausgebende und/oder Informationen von einem Fahrer entgegennehmende Funktionalität aufweisenden Fahrzeugsystems eines Kraftfahrzeuges
DE10239934B4 (de) Verfahren zur Steuerung der Dienstbelegung in einem Datenbussystem
EP1536328B1 (de) Datenverarbeitungssystem mit automatisierbarer Verwaltung und Verfahren zur automatisierten Verwaltung eines Datenverarbeitungssystems
DE10228778B4 (de) Hardware-Verfahren zum Implementieren von atomischen Semaphoroperationen unter Verwendung von Codemakros
EP0849652B1 (de) Verfahren zur Verwaltung von Weckzeiten und Vorrichtung zur Ausführung dieses Verfahrens
DE60220669T3 (de) System und verfahren zum vorladen einer bussteuerung mit einem befehlsplan
EP3647794A1 (de) Verfahren zum steuern einer kommunikation zwischen einer aufzeichnungseinheit und einem geschwindigkeitsgeber eines tachographensystems eines kraftfahrzeugs sowie korrespondierendes tachographensystem und aufzeichnungseinheit für das tachographensystem
EP3590234B1 (de) Anordnung und verfahren für ein flugzeug zur übertragung eines analogen audiosignals
DE102020214357A1 (de) Computerimplementiertes Verfahren zum Übertragen von Nachrichten in einem auf einem MQTT-Protokoll basierenden Kommunikationsnetzwerk
DE60211703T2 (de) Verfahren und system zur zeitverwaltung in einem echtzeitsystem
EP1374000B1 (de) Verfahren und anordnung zur bedienung und/oder beobachtung der eine anlagen-steuerung uberwachenden einrichtung

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT SE SI SK TR

17P Request for examination filed

Effective date: 20050228

17Q First examination report despatched

Effective date: 20081202

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: VOLKSWAGEN AKTIENGESELLSCHAFT

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180901