WO2005006091A1

WO2005006091A1 - Control device and network for a plurality of devices

Info

Publication number: WO2005006091A1
Application number: PCT/EP2004/007511
Authority: WO
Inventors: Peter-Michael Ludwig; Clemens Kroll; Hartmut GÜNTHNER
Original assignee: Peter-Michael Ludwig; Clemens Kroll; Guenthner Hartmut
Priority date: 2003-07-09
Filing date: 2004-07-08
Publication date: 2005-01-20
Also published as: DE10332113A1

Abstract

The invention relates to a control device for a plurality of devices, especially in a motor vehicle. The control device comprises a software packet provided with a specific part (500) for a domain and at least one control device (100) which is used to interact with at least one of the devices (300) via a peripheral element (200) in response to commands from the software packet. Said type of control devices are well known, especially in motor vehicle electronic systems. The disadvantages of prior art is that it can only be used in standard systems. According to the invention, the software and the hardware of the control device is domain specific, enabling said disadvantages to be overcome. A domain is defined as a group of at least similar requests to the control device, particularly with respect to the real time behaviour thereof or safety precautions thereof.

Description

Title: Controller and network for a variety of devices

description

The invention relates to a control device and a network for a plurality of devices, in particular in a motor vehicle (motor vehicle). In addition, the invention relates to a method for equipping a vehicle with at least one such control device or network.

Control devices, networks and methods of the type mentioned are basically known in the prior art. A control unit usually comprises a software package and a control device on which the software package runs. In the field of vehicle electronics, a microcontroller is often used as a control device for interacting with various devices of the vehicle. These devices can in particular be the engine, the transmission, an anti-lock system, a seat or a locking system of the vehicle. The devices are usually controlled by the microcontroller via a peripheral element in response to commands from the software package.

For the software package, it is particularly important in the field of vehicle technology, for example from VDI report no. 1646, 2001, page 249 to page 276, "Software development for control units in the system network - from the Cartronic domain structure to the device code", known to train this domain-specifically. The term "domain-specific training" in the state of the art means structuring the software according to functional and non-functional requirements. Functional requirements are, for example, the granting of an all-round view, which is implemented by a wiper system. In contrast, non-functional requirements are, for example, qualitative or business requirements for individual devices of the vehicle.

This construction of known control devices just described has the disadvantage that it is only of limited suitability for standardizing the control devices. The concept of domain-specific training of the software package for a control unit described in the VDI report does indeed achieve a certain degree of standardization, in particular for the software of the control units; however, it has been shown that this approach quickly reaches its limits when attempting further standardization.

On the basis of this prior art, it is therefore the object of the invention to develop a control device and a network for a plurality of devices and a method for equipping a vehicle with at least one of these control devices or networks in such a way that further standardization of the control devices becomes possible. so that they can be used for a much larger variety of applications.

This object is achieved by the subject matter of patent claim 1. Accordingly, the devices to be controlled by the control device have at least similar requirements for the control device, the class of these at least similar requirements represents the domain, and the control device of the control device is designed specifically for the domain as a domain controller.

Devices in the sense of the invention can in principle be any devices which can be controlled electrically / electronically by actuators and which can optionally give feedback via sensors.

The advantage of the claimed domain formation is there too see that they start at a very early stage of a development process, namely before the specification of the control unit, and not - as is known from the prior art - when specifying applications or functions that are to be implemented with a given control unit , It is also important that the domain formation according to the invention, in contrast to the prior art, extends not only to the software of the control device, but also to its hardware, in particular its control device. The domain-specific control device, that is to say the domain controller, and the domain-specific portion of the software package are identical for all different applications within a domain. In this respect, the claimed definition of a domain and the domain-specific training of the software and hardware of the control device based thereon form the basis for a very extensive standardization / modularization of the control device, which is described in more detail below, and for the resulting cost advantages.

According to an advantageous embodiment, the domain controller has a bus interface which is preferably designed to be domain-neutral. Peripheral elements connected to it must inevitably be bus-compatible. Such a design of the domain controller and the peripheral elements offers the advantage that no hardware specific to the individual peripheral elements has to be provided in the domain controller. The hardware expenditure for controlling the peripheral elements is thus shifted from the domain controller to the peripheral elements. This concept is a further prerequisite for a very extensive standardization of the control devices or, in particular, of their control devices, the domain controllers. They no longer have to be designed specifically for a large number of different peripheral elements. The number of use cases for which a single domain controller type can be used, this is further increased significantly. Such a standardized domain controller can be manufactured in much larger quantities, which results in considerable cost advantages. The cost advantages result in particular from training the domain controller as an integrated circuit. At the same time, the monolithic integration is a prerequisite for a simple, highly reliable implementation of foil-based "intelligent" cabling structures.

For a single specific domain controller type, it is advantageous if it is scalable in terms of its processing power and / or its memory size. This results in a further broadened possible range of applications with more

Standardization potential and further cost advantages for one and the same specific domain controller type.

Another particularly advantageous embodiment of the control device consists in that at least individual (as many as possible) devices of the domain controller or individual (as many as possible) peripheral elements are designed as intellectual property IP devices. Such training makes the facilities independent of the manufacturer, which means that many suppliers can be considered for these facilities. Individual parts of the software can be designed as open software architectures. In contrast to the prior art, no individual software adaptation of software components to different hardware devices, which are different because they come from different manufacturers, is then required.

The possibilities just described for standardizing the hardware of the control device, that is to say in particular the domain controller, also enable a more extensive and more extensive standardization of the software than was possible in the prior art.

This further standardization of the software is implemented, for example, in the form of a standardized sequence control as a domain-specific part of the software package. The process control essentially compares input patterns with condition patterns and triggers certain events depending on the result of this comparison. By providing these condition patterns, which are individually adapted to the devices to be controlled individually in each individual case, by means of a parameter database, it is possible to shift customer-specific functions and requirements into the software or into the condition patterns or data records. The domain controller and the process control remain unaffected by these customer-visible functions, which is why they are accessible for extensive standardization. They only need to be created and checked once. As a result, development costs as well as warranty and goodwill costs decrease, the time for further developments is shortened and the degree of product maturity is increased considerably.

Advantageously, the sequence control is not only flexibly adapted to the individual conditions of an individual case within a domain via the parameter database, but also via a limit value database and in particular via plug-in modules. For example, it is possible to implement a desired functional expansion for the sequential control system using an individually selected plug-in module without having to change the software of the standardized sequential control system.

The sequence control advantageously runs in a normalized environment. In terms of software, the encapsulation is achieved by linearization / normalization components in the input path of the sequential control system and by a denormalization component realized in the output path of the sequential control system. The linearization / normalization component and the denormalization component are preferably standardized and, wherever possible, are designed to be domain-specific or domain-specific. The software components mentioned cause a calibration of the connected peripheral elements and thus also support a connection of less precise (inexpensive) peripheral elements to the control unit. Because the sequential control system runs in a normalized environment, its system structure can be simplified or further standardized. The normalization and standardization of the sequence control makes it independent of the types and manufacturers of the connected peripheral elements and gives the user the freedom to change the supplier and type of a peripheral element at any time without the standardized sequence control, the linearization / normalization component, or the denormalization component or the standardized domain controller would have to be changed. In these cases, it is only necessary to adapt or change the device or function-specific data to be supplied to the linearization / normalization component and the denormalization component from a configuration database.

For security reasons, it is also advantageous if the software package has a diagnostic and error detection component and / or is at least partially redundant. For the same reasons, the domain controller can also be at least partially redundant.

The above-mentioned object of the invention is further achieved by a network for controlling a large number of devices, in particular a motor vehicle, wherein at least two of the control devices according to the invention described are linked to one another for the purpose of data exchange in this network. It is particularly advantageous if the domain Controllers of different domains are coupled to each other via a gateway, because such a gateway can, in addition to a pure multiplexer function, also implement a protocol conversion if necessary. This gateway can also be part of one of the control units.

Finally, the above-mentioned object is also achieved by a method for equipping a vehicle with at least one of the claimed control devices or at least one of the claimed networks. In this case, the individual devices of the vehicle, which are later to be controlled via the control unit, are advantageously already detected during the production of the vehicle. At the end of the production process, the software of the control unit can then be put together for the devices recorded and onto the control unit or the standardized domain Controller are imported.

Assigning a specific number for each imported software package, sometimes also for each software module, offers the advantage that it can be clearly identified. This means that the manufacturer is always able to determine the software version currently imported from each vehicle. To carry out a software update, for example in workshops, this number is then read into a central database and the software version represented by it is compared with the latest available software version. During the software update, the data history for each software package is updated. With the help of these assignments, the software versions of vehicles can be specifically determined.

Further advantageous refinements of the control device, the network and the method are the subject of the dependent claims. The invention is described in detail below in the form of exemplary embodiments with reference to the accompanying figures, wherein

1 shows the control of a device by a control device according to the invention via a peripheral element;

Figure 2 shows the structure of the control device according to the invention;

FIG. 3 shows the structure of a software package according to the invention; and

Figure 4 shows a method according to the invention

illustrated.

It can be seen in FIG. 1 how a device 300 is controlled via a control device 100 of a control device designed according to the invention. Specifically, the control takes place initially from the control device 100 via a data bus 400, which connects the control device 100 to a peripheral device, generally a sensor 200 or an actuator 200 '. In response to commands from a software package (not shown in FIG. 1) of the control device, the peripheral device 200, 200 'then controls the device 300 directly or receives sensor signals from it. The device 300 can be, for example, the motor, the transmission, a seat, a locking system or a communication device such as a hi-fi system, a personal computer or a navigation system, etc. act of a vehicle.

The structure of the hardware of the control device according to the invention, in particular of its control device 100, is illustrated in FIG. The control device 100 is preferably designed as a microcontroller and therefore comprises in the Also rule the typical facilities of a

Microcontrollers, in particular a microprocessor 110, an input / output device 140 and a memory device 150. The input / output device 140 is preferably designed as a bus interface, in particular for connecting the peripheral elements 200, 200 'via a standardized LIN bus or SAE J180 bus ,

In addition to the typical devices of a microcontroller, the control device 100 also includes other devices, such as a security device 120 and an energy-saving device 130. The security device 120 serves to protect the controller against unauthorized access and unwanted manipulation. The energy-saving device 130 serves to control the electrical power consumption of the control device 100 as required. For security reasons, it is advantageous if at least some of the devices of the domain controller are designed redundantly.

According to the invention, the control device shown in FIG. 2 is at least partially domain-specific, that is, it is designed as a domain controller. This means that it is specifically optimized with regard to a special class or group of identical or at least similar requirements for the control device. These at least similar requirements for the control device are defined by the devices 300 to be controlled. Accordingly, the control unit is preferably only used to control devices which at least approximately match the requirements of the control unit.

The domain-specific training of the domain controller means in particular that it respects its real-time behavior, its safety precautions or its functionalities such as temperature stability or data throughput with regard to the requirements of the control devices to be controlled is optimized. The optimization can also consist in that, depending on the application, some of the normally usual and above-mentioned devices 110 ... 150 of the domain controller are omitted if their function is not required.

Regardless of its domain-specific design, it is advantageous if the domain controller 100 is scalable with regard to its processing power and / or the memory size of its memory device 150. This possible training also makes a significant contribution to further standardization of the domain controller. It ensures that one and the same domain controller architecture, which is optimized with regard to the above-mentioned requirements for a special application, does not need to be changed, just because individual applications with the same domain-specific requirements for the control unit require greater or smaller processing power and / or need memory size.

The physical quantities with which the control unit is scalable must be distinguished from the domain-specific requirements for the control unit. While the scalable variables represent requirements for the control unit as a whole, in particular assuming that the control unit as a whole controls a large number of devices, the domain-specific requirements always only represent the requirements for the control unit from the point of view of individual devices to be controlled. If several devices are controlled by a control device virtually simultaneously, its required processing power or storage capacity can be several times higher than a corresponding domain-specific requirement of individual devices would require.

So it’s no contradiction if one and the same domain On the one hand, controller enables a certain real-time behavior, which is made as a domain-specific requirement for individual devices, and on the other hand, it is scalable with regard to its processing power. The real-time behavior describes, for example, the performance of the domain controller, which is required for processing data of a cylinder (device) of an internal combustion engine in real time. Regardless of this, the total processing power required by the domain controller can be set much higher. This applies in particular when not only the data from one cylinder, but the data from several cylinders of the internal combustion engine are to be processed in real time: the processing power required by the domain controller is then many times higher than in relation to the real-time behavior every single cylinder is required ..

In principle, a control device only comprises a domain controller. However, it is also conceivable that a control device has a plurality of domain controllers, each of which realizes different requirements assigned to one and the same domain and for the purpose of comprehensive provision of functions by the control device to one another, preferably via a standardized bus, e.g. the CAN bus, are networked with each other.

Several control units or their respective domain controllers can also be networked with one another if they are each assigned to different domains. The networking of the domain controllers with one another then preferably takes place via gateways, the latter, in addition to a multiplexer function, also being able to enable a protocol conversion between different domain controllers that may be required.

FIG. 3 shows the structure of the software package 500 according to the invention for the control device. Centerpiece of the Software package is a domain-specific standardized sequence control 510. It is essentially designed like a von Neumann state machine. It detects physical input variables which are supplied to it via sensor units 230 connected directly to the control unit or via a bus connection 400, for example in the form of a CAN bus or a LIN bus or a SAE J1850 bus connection. It receives these input variables in the form of the input pattern and compares this input pattern with a predetermined condition pattern which is assigned to a state in which the sequencer 510 is currently located. This condition pattern of the sequence control 510 is made available individually by the parameter database 520 for the configuration of the devices 300 connected to the control device. On the basis of the result of this comparison, the sequence controller 510 then decides whether it should remain in its current state or change to a new state.

Depending on this, the sequencer 510 triggers certain events. An event that can be triggered is, for example, the activation of a selected suitable plug-in module 540-1 ... 3. Such a plug-in module offers the possibility of a functional expansion for the sequence control while it is in a certain state. This functional expansion can consist, for example, in the preparation or filtering of data or in the provision of a control algorithm for the sequence control. In particular, the plug-in modules 540-4 ... -6 in the output path of the sequence control 510 can also provide a streaming machine and / or a pre- or postprocessor in software or hardware or a combination of software and hardware. The same is possible for the input path (not shown here).

If necessary, the plug-in modules 540-1 ... -6 are processed by the sequential control system via a standardized interface 510 activated and supplied with data or deactivated. However, there is also the possibility that the plug-in modules 540-1 ... -3 directly, that is, bypassing the sequence control 510, of suitable input variables provided by the sensor unit 200 via the bus 400 or directly by a sensor can be activated via sensor input 240. Thereafter, either an interaction with the sequence control 510 or also a direct output of data to the actuator unit 200 'via the bus 400 is possible or directly to an actuator via the driver output 240'. The plug-in modules 540-1 ... -6 can be designed in terms of both software and hardware.

The way in which the sequential control system 510 has just been described in abstract form is illustrated below with the aid of an example. For this purpose, it is assumed that the control device for controlling seat air conditioning is to be used as device 300. A current temperature of the seat is initially detected via suitable temperature sensors as sensor unit 230 of the bus-capable peripheral element 200 (see FIG. 1). The recorded temperature is then converted by a signal processing device 220 within the peripheral element 200 to the data format of a data bus 400 connected to the peripheral element, for example the LIN bus or SAE-J1850 bus, and by a bus interface 210 via the LIN bus or SAE J1850 - Bus transmitted to the domain controller 100 and the sequencer 510. It is further assumed that the sequence controller 510 is in a “seat temperature monitoring” state at this time. The sequence controller 510 then compares the actual temperature of the seat as an input variable or as an input pattern with a predetermined condition pattern which, for example, specifies that the current state of the sequence controller 510 "seat temperature monitoring" can only be maintained as long as the seat temperature in an area from 18 - 22 °. For example, if the actual temperature of the seat is 25 ° C, that is, outside the range specified by the condition pattern, the sequence control changes to a new state "seat cooling". In response to the result of this comparison via the bus 400, the sequence control 510 then activates a cooling device as a peripheral element 200 ′ for cooling the seat from 25 ° C. down to the range specified by the condition pattern. The cooling device as peripheral element 200 'comprises a bus interface 210' for receiving the data from the bus 400, a driver device 220 'and an actuator unit 230' designed here as a cooling unit. In parallel to the activation of the cooling device 200 ', the sequence control 510 can activate, for example, a plug-in module 540-1 assigned to it, which provides a control algorithm which specifies the course over time of the temperature of the seat 300 with the aid of the cooling device 200' to be shut down.

In addition to a parameter database 520, which basically provides the condition patterns for all states, the non-domain-specific part of the software package 500 can also provide a limit value database 595, which provides special condition patterns for the sequence controller 510. These special condition patterns dictate what to do if the input variables supplied to the sequencer 510 fall below or exceed certain threshold values. For example, it can also specify a fail-safe state for the sequence controller 510, which is to be assumed when the sequence controller becomes aware, based on the input data supplied to it, that the device 300 may be at risk. In this fail-safe state, the sequential control system 510, by outputting suitable output variables, preferably switches off the device 300, from which the danger threatens.

Advantageously, the sequencer 510 operates in a normalized environment; this is an important prerequisite for extensive standardization of the Flow control. For this purpose, the sequence controller 510 is connected upstream on its input side with a software-based, likewise domain-specific or domain-encompassing linearization / normalization component 550, for linearizing and / or normalizing input variables supplied directly or via a bus 400. In mirror image, a domain-specific or cross-domain denormalization component 560 is provided on the output side of the sequence controller 510 for adapting the output variables of the sequence controller 510 to those physical units that are used by the respective controlled peripheral element 200, 200 '. In this way, it is possible for the sequential control system 510 to be designed abstractly, that is to say independently of special peripheral elements used / connected and in particular independently of the physical units used by the peripheral elements, as a result of which it is particularly suitable for standardization.

Both the linearization / normalization portion 550 and the denormalization portion 560 only provide suitable conversion algorithms, which is why they can be standardized and at least partially cross-domain. However, they must be individually adapted to the connected peripheral elements. For this purpose, the software parts 550 and 560 mentioned are fed from respectively assigned, preferably flashable, calibration databases 555, 565 with data suitable for the connected peripheral elements, in particular for adapting the characteristic curve.

Furthermore, the software package 500 can comprise a diagnosis and error detection part 590, which enables the detection and correction of errors in the functioning of the male-specific part of the software package. This diagnostic and error detection part 590 is advantageously shared by a configuration database 600 suitable data or algorithms supplied and monitored with regard to its current software version.

The control unit described above for an application in a vehicle, in particular in a motor vehicle, is preferably implemented as part of the production process of the motor vehicle. Such an implementation process is shown schematically in FIG. 4. After a start step SO, this implementation process initially comprises a step S1, in which all devices of a specific vehicle are determined which are to be controlled via a control device or a network of the type described above.

In a subsequent method step S2, the previously determined devices of the vehicle are examined or queried with regard to their respective requirements for a control unit and assigned to a domain. The control units each comprise a domain controller 100 and a software package with the domain-specific software components 510, 550 and 560.

In addition to these domain-specific parts, the software packages 500 for the control units also include, as already mentioned above, non-domain-specific parts, in particular the parameters and / or limit value database 520, 595 or plug-ins etc. Their content must be in the form of data depending on the type of can be individually put together by the control device to be implemented functions or the connected peripheral elements and devices (method step 3).

The compilation of the software package for an individual control device includes in particular the loading of non-vehicle-specific software in the form of an operating system and the sequence control, the loading of vehicle-specific function and diagnostic parameter data, of address data, Calibration data and limit value data for the specifically used peripheral elements, the loading of condition patterns and plug-in functionalities as well as the loading of specific drivers for the control unit. The calibration data for the linearization / normalization and denormalization components 550, 560 are loaded from the calibration databases 555, 565 assigned to these components and the rest of the data is loaded from the configuration database 600.

The sensors and actuators connected via a bus advantageously send a type identifier when the domain controller requests them. This automates the process of pairing the sensor / actuator to a suitable calibration data record. This prevents configuration errors in production or in the event of a service event.

In principle, the compiled software package can then already be loaded onto the respective domain controller of the control device or of the network (method step S4). This would end the method for implementing an individual control device according to method step S5.

The configuration database 600 can also be designed to manage the versions of various databases and software components used in the software package of the control device. This means in particular that it only releases individual software components for importing into a control unit if there are no incompatibilities between the different versions.

In addition, the configuration database 600 can be embodied, data and / or algorithms for authentication methods, for license allocation methods and / or for billing methods in connection with a To make use of, in particular, the domain-specific part of the software package. Such a configuration of the configuration database 600 would significantly simplify and simplify the processing of the use of software licenses, in particular for the domain-specific portion of the software package. In this context, it would be advantageous if, after a previous authentication step, when the software package is automatically imported to a control unit, a billing process for the software package used is triggered for the user of the software package authenticated in the authentication step, in particular if the software package is under license is used.

Claims

claims

A control device for a plurality of devices (300), in particular a motor vehicle, comprising: a software package (500) with a portion (510, 550, 560) specific to a domain; and at least one control device (100), in particular a microcontroller, for interacting with at least one of the devices (300) via a peripheral element, in particular a sensor (200) or actuator (200 '), in response to commands from the software package; characterized in that the devices (300) have at least similar requirements for the control device; the class of these at least similar requirements represents the domain; and the control device (100) is at least partially designed specifically for the domain as a domain controller.

2. Control device according to claim 1, characterized in that the requirements for the control device are, for example, its real-time behavior, its security or its functionalities, such as temperature stability or data throughput.

3. Control device according to one of the preceding claims, characterized in that the domain controller is a domain-specific microcontroller.

4. Control device according to one of the preceding claims, characterized in that the domain controller has a preferably domain-specific security device (120) for protecting the controller against unauthorized access.

5. Control device according to one of the preceding claims, characterized in that the domain controller has a preferably domain-specific energy-saving device (130) for influencing the power consumption of the domain controller as required.

6. Control device according to one of the preceding claims, characterized in that the domain controller has an input / output device (140), in particular bus interface.

7. Control device according to claim 6, characterized in that the peripheral element (200) is bus-compatible and is connected via a data bus (400) to the bus interface (140) of the domain controller.

8. Control device according to claim 7, characterized in that a bus-capable sensor as bus-capable peripheral element (200) in addition to a sensor unit (230) also has a bus interface (210) and a signal processing device (220).

9. Control device according to claim 7 or 8, characterized in that a bus-capable actuator as bus-capable peripheral element (200 ') in addition to an actuator unit (230') also has a bus interface (210 ') and a driver device (220').

10. Control device according to claim 8 or 9, characterized in that the bus-capable sensor (200) and / or the bus-capable actuator (200 ') is at least partially designed as a companion unit, preferably as a companion chip.

11. Control device according to one of claims 6 to 10, characterized in that the companion unit is composed of one or more Intelectual-Property IP units.

12. Control device according to one of claims 3 - 11, characterized in that at least one of the devices (110 ... 150) of the domain controller is designed as an intellectual property IP unit.

13. Control device according to one of claims 3 - 12, characterized in that the domain controller (100) - with unchanged at least partial domain-specific design of its devices - is scalable with regard to its processing power and / or the memory size of its memory device (150).

14. Control device according to one of the preceding claims, characterized by a plurality of domain controllers which interconnect, preferably via a local bus, e.g. the CAN bus, are networked with each other and each take on different tasks when controlling the devices.

15. Control device according to one of the preceding claims, characterized in that the domain-specific software part comprises: a standardized sequence control (510) for detecting input variables in the form of input patterns via the sensors (200), for comparing the input patterns with condition patterns which have a current state are assigned to the sequential control system to make decisions based on the comparison whether, and if so, in which new state the sequence control changes and for triggering events in response to the result of the comparison.

16. Control device according to claim 15, characterized in that a non-domain-specific portion of the .software package (500) comprises: a parameter database (520) for providing the condition patterns, and / or a limit value database (595) for providing condition patterns for borderline cases which the input or output variables to be processed by the sequential control system exceed or fall below and, if necessary, to define a transition to a fail-safe state for the sequential control system (510).

17. Control device according to claim 16, characterized in that the non-domain-specific software part further comprises: - at least one plug-in module (540-1 ... -6), which is a functional extension for the sequence control (510) via a standardized Provides interface and can be activated or deactivated by the sequence controller (510) in response to the result of the comparison.

18. Control device according to claim 17, characterized in that the functional extension provided by the plug-in comprises a general control algorithm, an algorithm for processing or filtering data, the function of a streaming machine and / or the function of a pre- or post-processor.

19. Control device according to claim 17 or 18, characterized in that the plug-in module is software and / or hardware.

20. Control device according to one of claims 15 - 19, characterized in that the domain-specific software part further comprises: a linearization / normalization part (550) for linearizing and / or normalizing input variables for the sequence control (510) with the aid of suitable algorithms; and a denormalization component (560) for adapting the output variables of the sequential control system to the specific physical units used by the respective driven peripheral elements with the aid of denormalization algorithms.

21. Control device according to claim 20, characterized in that the domain-specific software portion further comprises: a calibration database (555, 565), preferably flashable, for providing the data required in each case for the linearization / normalization and denormalization portion (550, 560), each depending on the type / type of peripheral elements or devices connected in individual cases.

22. Control device according to one of claims 16 - 21, characterized in that the non-domain-specific software part further comprises: a diagnosis and error detection part (590) for detecting and correcting errors in the functioning of the domain-specific part (510, 550, 560) the software.

23. Control device according to one of the preceding Claims, characterized in that the domain-specific and / or non-domain-specific part of the software package or the domain controller are at least partially redundant.

24. Control device according to one of the preceding claims, characterized in that within a domain, several domain controllers are networked directly via a bus.

25. Network for controlling a large number of devices, in particular a motor vehicle, characterized in that: at least two control devices, each designed according to one of claims 1 to 24, are provided for controlling the devices which at least partially have different requirements for the control devices; the control devices are designed for different domains according to the different requirements of the devices; and the domain controllers of the control devices are preferably networked with one another via a gateway.