EP1483666A2 - Service controller for computer systems, especially for a motor vehicle - Google Patents

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 for computer systems, in particular for a

motor vehicle

description

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. For example, the Unix programming system has been in existence for years, with which a multitasking system can be implemented. There are also various real-time operating systems, such as QNX. This enables a program to execute commands in "real time".

It is also known to control a device using software. For this purpose, a function is selected via an input device on the device and this is converted into a command which is carried out by the device. However, if there are various components to be operated in a motor vehicle, as a rule individual commands are not initiated by the user on the components themselves, but rather on a multifunction control device common to several components. This multifunction control device then conveys the commands to be executed to the individual connected components and the components concerned then execute this command or these commands. Such a multifunction control device is known, for example, from WO 00/21795.

One possible solution is the layer model, which is known per se. If a command occurs in a higher layer, for example in one

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.

The systems mentioned have no boundary lines between the real-time operating system, the service and the user interfaces, hereinafter referred to as human machine interface or HMI for short.

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.

This object is achieved with the features of claims 1, 11 and 21. Further advantageous refinements of the invention are specified by the dependent claims and the further description.

For the solution, a so-called service controller is integrated, which manages the distribution of services between the computer system and a real-time operating system. For this purpose, 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 approach of the system is that under the existing human machine interface interface the control of the

User interface programming and the entire operating software is arranged. 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. In addition, 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. When designing the user interface, 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.

There is a defined division of the system dynamics. The further explanations are based on a three-layer system, but the invention is not limited to this, but the description is given purely by way of example.

The system dynamics are implemented in three layers, in which the entire system dynamics are processed proportionately and independently. These three layers are:

- the dynamics of the behavior influenced by the user, human machine interface and multimodal input options; - the dynamics of the relationship between different ones

Applications such as the service controller; - The dynamics within an application, hereinafter referred to as "service".

In order to clarify the functioning of the three-layer model, this is explained using a concrete example, namely the pressing of an operating button on the human machine interface to which the "play CD" function is assigned. If this button is pressed, the system goes immediately into the state "CD play" with the participation of simultaneously changing services with regard to amplifiers, output units etc. This means that when the function-associated service "CD play" is executed, further services are started which are necessary for the execution of the command the corresponding data and required units are thus activated and enabled via the computer system. In the case of “CD play”, 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. In this way it is possible for the first time to clearly structure the system dynamic parts and to display them in layers. 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. When the user enters a function via the human machine interface, 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.

In a further embodiment of the invention, 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. With this service API, 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.

In the following, the rule base and the functionality are explained based on the special features in a vehicle.

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.

In the present invention, 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. For each of the three areas, as described above, in a separate, newly created software instance, priority is dealt with or processed on the basis of software instances. In this way, the previous problems that a user assumes a system crash are avoided. A blockage can no longer arise because the different dynamic ranges, as described above, are processed in different software instances. The apparently illogical behavior or system behavior is avoided in that the service controller is able to differentiate and effect the currently desired application state.

Due to the clear division of the system dynamics into separate software layers, namely into several dynamic layers, individual layers can run on different processors or even different operating systems. In this way, e.g. For example, the service controller runs on a QNX-based computer, the human machine interface runs on a Windows CE-based computer, and the service controller then manages the conflicts that arise independently. In this way, 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 possibility of implementation on multiprocessor systems with different operating systems is guaranteed.

Several human machine interface instances, such as for drivers, co-drivers, passengers and even completely different applications, can be managed by a service controller of this software architecture. The human machine interface can even be decoupled via a wide area network, so that services in the sense of remote management are possible. There is also the possibility of remote control of the vehicle from outside, as well as end-to-end solutions for applications without driver involvement, for example to enable automatic service messages from the vehicle to the provider. Automatic authorization and / or maintenance of the vehicles, remote maintenance of an in-vehicle database, as well as the specification of navigation destinations, such as in vehicle fleet management, is thus possible from outside.

This makes the system easy to display in compliance with standards, because standardized protocols such as B. TPC / IP can be used.

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.

This formal architecture definition ensures independence from concrete real-time operating systems and the type of processor. It is therefore much easier to do what was previously based on real-time operating systems System can also be partitioned without necessarily knowing the type of microprocessor.

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.

Furthermore, the invention is explained in more detail on the basis of a specific exemplary embodiment with reference to FIGS. 3 to 5.

It shows:

3 shows a layer model according to the invention,

4 shows the components of a service controller and

5 shows a structure of a service controller.

A layer model is described in FIG. 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.

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.

To use the range of functions that a service offers, 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). There is an application programming interface for sending and receiving messages, which is called SERAPI (SERvice API) and is described in more detail below. The human machine interface has no direct access to the services and hardware.

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. On the other hand, 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.

The service controller will now be discussed. Among other things, a multimedia system has the following properties:

- to realize a simple way to be adaptable to an interface without complex adaptation work;

- to support partial developments and to enable testing of software components;

- Show a simple way to make the system equipable with expandable components.

As already shown, 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. To adapt the system to the specific properties of the hardware, however, it is necessary to design the software in a modular manner. This modularity is made possible by the development and introduction of a service. Each service has the option of access and control over the physical and actually existing units on the system and enables a hardware-independent interface to the respective upper layer, for example the human machine interface. Some of these services are dependent on other services or they require exclusive access to the hardware. 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.

On the other hand, it is also possible to connect an event generator to the service controller, which enables all test scenarios run automatically. This enables a deeper and more extensive and faster test possibility than has previously been possible.

As already mentioned, 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.

A number of possible events initialize a sequence of actions to be carried out in different services, but the sequence of the action is very important. The success or failure of an action affects the following actions. In order to make it even more complicated, it may be possible and necessary in certain areas that one event must be scheduled before another before this action can be carried out. This means that it may be necessary to act in parallel, and it must also be ensured that this parallel work with one another remains free or possibly not free from influence. 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, the up thread and the main thread. 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, as shown above, 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 further structure of the service controller is explained below with reference to FIG. 5. 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.

It is important that 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. In the event that an event triggers a number of further actions, the dispatcher creates a new job that manages this event. The dispatcher saves a list of active jobs.

The functionality is discussed in more detail below. 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.

The following events or attributes are defined:

Loop Through, Audio Producer, Audio Stopper, GSM Phone User, GSM Releaser and Rule Exception.

These attributes have the following meaning:

Loop through:

An event with this flag changes from the service controller to the associated one

Service or passed to the human machine interface.

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.

GSM Phone User:

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.

GSM Releaser:

This event attribute means that the service is giving up its access to the GSM modem. Ruie exception:

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.

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. If various conditions apply, all associated actions have been carried out, unless it is a ruie exception event, only the exception handler for this specific event is executed. After all ruie conditions have been checked, the dispatcher goes through the job list and continues the active jobs. The dispatcher then fetches the next event from the queue.

As already mentioned, 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:

Exception: 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.

Audio stopper:

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.

The associated action is: 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.

Loop through:

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.

As already shown, 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.

Claims

claims: 1. Method for managing and / or executing individual processes or functions, in particular a computer system in a motor vehicle, the computer system being implemented in a layer structure, characterized in that at least three mutually independent layers (HMI layer, service layer, protocol layer) be implemented, the human machine interface being implemented in the first layer (HMI layer), a controller (service controller) being implemented in the second layer (service layer), of which processes or functions, which data between or within the layer ( Exchange and / or transfer HMI layer, service layer, protocol layer) and / or initiate functions in one of the other layers (HMI layer, service layer, protocol layer) or in your own layer (HMI layer, service layer, protocol layer), are controlled and in the third layer (protocol layer) interfaces to and between components of the computer system are controlled. 2. The method according to claim 1, characterized in that a first sub-layer (skin sublayer) and a second sub-layer (logic sublayer) is controlled by the first layer (HMI layer). 3. The method according to claim 2, characterized in that different first services (service 1 skin, service 2 skin, service 3 skin) are processed by the first sub-layer (skin layer) and different second services (second sub-layer (logic sub-layer)) Service 1 logic, Service 2 logic, Service 3 logic) can be initiated and / or controlled. 4. The method according to one or more of the preceding claims, characterized in that between the first sub-layer (skin layer) of the first layer (HMI layer) and the controller (service controller) a main logic controller (main logic) for controlling the Processes is arranged. 5. The method according to one or more of the preceding claims, characterized in that the controller (service controller) of the second layer (service layer) inputs and outputs of the first layer (HMI layer) the first services (service 1 skin, service 2 skin, Service 3 skin) of the first sub-layer and the second services (service 1 logic, service 2 logic, service 3 logic) of the second sub-layer (logic layer) in the service layer of individual services (service 1, service 2, service 3 ) in the second layer (service layer). 6. The method according to one or more of the preceding claims, characterized in that the services (service 1, service 2, service 3) of the second layer (service layer) via protocol modules (protocol 1, protocol 2) in the third layer (protocol layer) be connected and implemented via the protocol modules (protocol 1, protocol 2) of the third layer (protocol layer) via interfaces (interface 1, interface 2). 7. The method according to one or more of the preceding claims, characterized in that a further service (user input service) is implemented in the second layer (service layer), which another interface (interface 3, Input) is assigned. 8. The method according to one or more of the preceding claims, characterized in that processes and threads are activated and controlled by the controller (service controller) in the second layer (service layer). 9. The method according to one or more of the preceding claims, characterized in that a message from the human machine interface (down-thread) of the first layer (HMI layer) from the controller (service controller) of the second layer (service layer) in a first list (priority queues) is entered and a service message (up-thread) from the third layer (protocol layer) is also entered in the first list (priority queues) and from the first list (priority queues) the individual messages stored there (down -thread, up-thread) are processed further after the time of entry and means for selecting the type of further processing (dispatcher) are available and in response to the means to be carried out processes (main threads) are entered in a second list (joblist) and of the means (dispatcher) messages are sent to the first and third layers (HMI layer, protocol layer), which depend on the status of the messages and the Processes (mainreads) contain status information. 10. The method according to one or more of the preceding claims, characterized in that Messages (down-thread, up-tread) are pushed into the first list (priority queues) and messages (down-thread, up-thread) from the first list (priority queues) are banned by the means (dispatcher). 11. Computer system, in particular in a motor vehicle, the computer system having a layer structure, characterized in that at least three mutually independent layers (HMI layer, service layer, protocol layer) are provided, the first layer (HMI layer) being the Human machine interface is implemented, in the second layer (service layer) a controller (service controller) is implemented, of which processes or functions, which data exchange between or within the layers (HMI layer, service layer, protocol layer) and / or transfer and / or initiate functions in one of the other layers (HMI layer, service layer, protocol layer) or in your own layer (HMI layer, service layer, protocol layer), be controlled and interfaces in the third layer (protocol layer) and are implemented between components of the computer system. 12. Computer system according to claim 11, characterized in that a first sub-layer (skin sublayer) and a second sub-layer (logic sublayer) can be controlled and / or controlled by the first layer (HMI layer). 13. Computer system according to claim 12, characterized in that the first sub-layer (skin layer) different first services (service 1 skin, service 2 skin, service 3 skin) can be edited and / or edited and the second sub-layer (logic sub-layer ) Various second services (service 1 logic, service 2 logic, service 3 logic) can be initiated and / or controlled and / or initiated and / or controlled. 14. Computer system according to claim 12 or 13, characterized in that a main logic controller (main logic) for controlling the processes is arranged between the first sub-layer (skin layer) of the first layer (HMI layer) and the controller (service controller) is. 15. Computer system according to one or more of the preceding claims 12 to 14, characterized in that the controller (service controller) of the second layer (service layer) inputs and outputs of the first layer (HMI layer) the first services (service 1 skin, service 2 skin, service 3 skin) of the first sub-layer and the second services (service 1 logic, service 2 logic, service 3 logic) of the second sub-layer (logic layer) in the service layer individual services (service 1, service 2 , Service 3) can be assigned and / or assigned in the second layer (service layer). 16. Computer system according to one or more of claims 11 to 15, characterized in that the services (service 1, service 2, service 3) of the second layer (service layer) via protocol modules (protocol 1, protocol 2) in the third layer (protocol Layer) are connected and / or can be connected and can be implemented and / or implemented via the protocol modules (Protocol 1, Protocol 2) of the third layer (Protocol Layer) via interfaces (Interface 1, Interface 2). 17. Computer system according to one or more of claims 11 to 16, characterized in that a further service (user input service) is implemented in the second layer (service layer), which another interface (interface) in the third layer (protocol layer) 3, input) is assignable and / or assigned. 18. Computer system according to one or more of claims 11 to 17, characterized in that the controller (service controller) of the second layer (service layer) is designed such that processes and threads can be activated and controlled by the controller (service controller) and / or activated and controlled. 19. Computer system according to one or more of claims 11 to 18, characterized in that a message from the human machine interface (down-thread) of the first layer (HMI layer) from the controller (service controller) of the second layer (service layer) in one first list (priority queues) can be entered and / or entered and a service message (up-thread) from the third layer (protocol layer) can also be entered and / or entered in the first list (priority queues) and from the first List (priority queues) of the individual messages stored there (down-thread, up-thread) can be processed and / or further processed after the time of entry and means for selecting the type of further processing (dispatcher) are available and in response to the means Processes to be carried out (main threads) can be entered and / or entered in a second list (joblist) and by means of (dispatcher) messages to the first and third n layers (HMI layer, protocol layer) can be sent and / or sent, which contain status information about the status of the messages and the dependent processes (main threads). 20. Computer system according to claim 19, characterized in that Messages (down-thread, up-thread) in the first list (priority queues) can be pushed and / or pushed and messages (down-thread, up-thread) from the first list (priority queues) by the means (dispatcher) are popable and / or poped. 21. Computer program product which can be loaded directly into one or more internal storage devices of a computer system and comprises program sections with which the method steps according to one of claims 1 to 10 are carried out and / or can be carried out when the program product runs in the computer system.