WO2006063924A1 - Verfahren zum initialisieren eines elektronischen systems umfassend mehrere plug-ins - Google Patents

Verfahren zum initialisieren eines elektronischen systems umfassend mehrere plug-ins Download PDF

Info

Publication number
WO2006063924A1
WO2006063924A1 PCT/EP2005/056224 EP2005056224W WO2006063924A1 WO 2006063924 A1 WO2006063924 A1 WO 2006063924A1 EP 2005056224 W EP2005056224 W EP 2005056224W WO 2006063924 A1 WO2006063924 A1 WO 2006063924A1
Authority
WO
WIPO (PCT)
Prior art keywords
plug
ins
size
interface
functionality
Prior art date
Application number
PCT/EP2005/056224
Other languages
English (en)
French (fr)
Inventor
Erwin Lock
David Rubia
Alexander Buechel
Volkmar Wuensch
Bernd Doerr
Original Assignee
Robert Bosch Gmbh
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
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to EP05811127A priority Critical patent/EP1828886A1/de
Priority to CN2005800429552A priority patent/CN101080692B/zh
Priority to US11/792,737 priority patent/US20080155405A1/en
Priority to JP2007546011A priority patent/JP2008523519A/ja
Publication of WO2006063924A1 publication Critical patent/WO2006063924A1/de

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/25—Pc structure of the system
    • G05B2219/25093—During start, integration into machine, send module functionality to scheduler
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/25—Pc structure of the system
    • G05B2219/25101—Detect connected module, load corresponding parameters, variables into module

Definitions

  • the present invention relates to a method of initializing an electronic system having a base interface and a plurality of plug-ins connected thereto.
  • the invention also relates to a communication protocol for processing on at least one computing device of an electronic system during the initialization of the electronic system.
  • the electronic system includes a base interface and several plug-ins connected thereto.
  • the invention relates to a computer program for processing on a computing device of a data processing system.
  • the computer program includes several plug-ins and a basic interface, with the plug-ins connected to the base interface.
  • the present invention also relates to an electronic system with a
  • the electronic system includes a base interface and several plug-ins connected thereto.
  • an electronic system for vehicles which consists of first components for performing control tasks in operating procedures and second components that coordinate an interaction of the first components.
  • the first components carry out the control tasks through a combination of operating functions and basic functions.
  • the operating functions are implemented in operating submodules (so-called plug-ins) and can be modularly integrated into the electronic system, re-used and exchanged or changed at any time.
  • the basic functions are summarized in a base layer, which communicates with the operating modules via a suitable interface.
  • a system layer which comprises the second components for coordinating the interaction of the first components Implementation of the control tasks includes.
  • an intelligence is present, which is required for integrating the plug-ins into the overall system.
  • the functionalities of the plug-ins build on the functionalities of the system layer and even require it.
  • the plug-ins must therefore be tailored to the functionalities of the system layer and can not easily in other electronic
  • the initialization of the system and the linking of the plugins to each other are not realized by the plug-ins themselves, but only by the system layer and / or an underlying operating system layer.
  • the initialization is thus controlled centrally, a communication between the plug-in of the system before or during initialization does not take place.
  • the present invention has the object, the known method to design and further develop that the initialization of the electronic system can be performed much more flexible than before.
  • the links of the plug-ins are to be generated automatically in the context of initialization, without the electronic system, the type and number of connected plug-ins and their functionality or processes must be known in advance.
  • first of all the plug-ins connected to the basic interface are queried for specific information.
  • This information relates, for example, to the functionalities realized in the plug-in or the corresponding processes.
  • the information relates to the variables determined by the processing of the processes and provided by the plug-in, as well as the sizes that the plug-in needs to execute the functionalities or to process the processes.
  • variables are, for example, variables, functions, structures, etc.
  • the plug-ins of the electronic system according to the invention therefore have additional initialization functionality in order to respond to the corresponding requests from the basic interface and to transmit the desired information ,
  • the base interface After receiving the information from a first plug-in, the base interface asks the remaining plug-ins if they can provide at least one of the required sizes. If this is the case, information is provided to the first plug-in through the base interface
  • a plug-in of the electronic system according to the invention thus has the additional initialization functionality to save the received references to one or more plug-ins, which provide the required sizes of the plug-in, at a suitable location.
  • At least one empty field is provided in the plug-ins, where the reference can be stored.
  • the reference can be stored.
  • the size is retrieved by the other plugin via the reference.
  • references to various other plug-ins can also be stored in the plug-ins, especially if different sizes are required in a plug-in. References to the other plug-ins can be of any kind.
  • the connections between the plug-ins can be created at runtime during the initialization of the electrical system, regardless of which plug-ins are actually connected to the base interface, and without having to know in advance which Plug-ins are connected.
  • the method according to the invention allows maximum flexibility in terms of adding, removing and changing plug-ins of an electronic system.
  • the plug-ins can be designed as hardware (for example as plug-in cards with additional input / output interfaces, additional drivers, additional memory or computing capacities, etc. for a control unit) or as software (for example as operating submodules of a computer program).
  • the basic interface has no functionality to complement the
  • the purpose of the basic interface concerns only the linking of the plug-ins during initialization and the communication between the plug-ins during operation of the electrical system.
  • the necessary information about the plug-ins is obtained by the basic interface directly from the plug-ins during the initialization phase of the electronic system through a communication with the plug-ins.
  • the at least a functionality is realized by at least one process. That is, the functionalities of the plug-ins are realized by one or more processes.
  • the transmission of information regarding the functionality of the plug-ins thus concerns any information regarding the processes implemented in the plug-in.
  • the information concerning the functionality of the plug-ins comprises a time frame in which the at least one process is processed, and a priority of the at least one process.
  • a pointer to a memory location is stored as a reference, at which the required size is stored by one of the other plug-ins.
  • the referenced memory space may be provided in one of the plug-ins, but also in the base interface or a subordinate base functionality or basic software.
  • Working with pointers has several advantages. One advantage is that if the software is updated in a plug-in, the old software can remain in memory, the new software is stored in another new location in memory, and the pointer is simply converted to the new memory location. A reprogramming (so-called flashing) of the entire memory (deletion of the old content and writing with the new software) is not required.
  • a pointer to a structure is stored, in which stored at a predetermined position, the required size by one of the other plug-ins becomes.
  • a separate pointer is not stored for each required size on a memory location where the required size is stored, but only a single pointer stored on a structure where all the required sizes are stored.
  • the structure comprises a certain number of fields, with certain sizes stored in certain fields. For example, it is defined in advance that a size A is always stored at the third position in the structure. When size A is needed in a plug-in, the plug-in jumps to the beginning of the structure pointed to by the pointer.
  • the required size is read and then returned to the plug-in again.
  • the structure may be included in the base interface or child base functionality or base software.
  • the content of the structure is continuously updated by the plug-ins providing the appropriate sizes. This embodiment has the advantage that only one field is needed in the plug-ins for the pointer pointing to the beginning of the structure, even if more than one size is needed in the plug-in.
  • the question is which plug-in should provide the size for the remaining plug-ins that need the size.
  • the size of the plug-in for further processing is advantageously used, whose process for determining the size has the highest priority. Since this process has the highest priority, it will be able to provide the required size before the other processes.
  • the size is provided by the plug-in from which the base interface first receives the information that the plug-in or a process of the plug-in -in the needed size can provide.
  • the size be provided by the plug-in from which the base interface receives the last information that the plug-in or a process of the plug-in can provide the required size.
  • the base interface has access to an initialization table with information on where the individual plug-ins are stored. If the plug-ins are software-designed, this table can be updated when flashing new plug-ins. In the case of plug-ins configured as software, but also as hardware, it is also conceivable that at the beginning of the initialization the plug-ins connected to the basic interface and their (initial) addresses are determined and the table is updated accordingly.
  • the table is preferably stored in the basic interface. Based on this table, the base interface can then query the individual plug-ins and obtain the desired information.
  • the electronic system is designed as a computer program, is a structuring of the computer program into basic software without plug-ins, a master interface arranged above and plug-ins and / or sub-interfaces connected thereto, to which further sub-interfaces and / or further plug-ins are connected conceivable.
  • the basic software comprises a fixed, permanent part of the software, which is responsible, for example, for communication via bus drivers, etc. In this way, it is possible to achieve a cascaded structure of the electronic system. For this structure, a visibility concept can be realized, by means of which it is possible to limit the visibility of certain variables from below, that is, from higher-ranking areas, to certain lower-ranking areas of the structure.
  • the interfaces are divided into different areas (eg private, public, protected, etc.). Only the variables within the same area of the interfaces (variables, functions, etc.) are visible to subordinate (ie higher ranking) interfaces and thus also accessible. The same size can be applied to different areas of an interface. As a result, the sizes can be encapsulated in certain areas and are somewhat similar to local variables.
  • the interfaces are divided into a private area and a public area. Only the public variables (variables, functions, etc.) applied to the public area of an interface are visible to a subordinate interface and therefore also accessible. The private quantities applied to the private area of the interface are only visible in the relevant interface and public areas of interfaces located above.
  • a subordinate interface only has access to the values applied to the public areas of the superordinate interfaces.
  • the sizes applied to the private areas are not visible to the subordinate interface and therefore not accessible.
  • an encapsulation of program areas or the functionalities realized therein is thus made possible in a simple manner.
  • the externally developed program areas can also be easily and quickly integrated into an existing computer program with the help of this visibility concept.
  • any size needed by the plug-ins or provided by the plug-ins be assigned a unique identifier for a defined area of the electronic system.
  • the defined area is preferably the area of the electronic system completed by the visibility concept.
  • the identifier includes, for example, an identification number and an indication of whether the size is public or private.
  • the identifiers of the variables are stored in an identification list which can be accessed by the basic interface during the initialization of the electronic system. It is conceivable that all variables (variables, functions, etc.) theoretically available in the electronic system are listed and explained in the identification list. The list is created for the whole system and not for the currently connected plug-ins. Therefore, regardless of the type and number of connected plug-ins, it always has the same content.
  • the base interface in advance no information about the plug-ins actually connected are available.
  • the list preferably forms the basis for an interface agreement or interface definition and serves as the basis both for the supplier of software or plug-ins and for the integrator.
  • the communication protocol be programmed in such a way that information is made available when the electronic system of the basic interface is initialized by the plug-ins concerning: + at least one functionality performed by the respective plug-in;
  • the basic interface provides information to the individual plug-ins regarding: which of the remaining plug-ins needed a size required by the plug-in
  • the electronic system is designed as a computer program, so that the plug-ins are operating submodules of a computer program. Accordingly, therefore, the invention is realized by the computer program.
  • the plug-ins in the context of the initialization of the electronic system of the basic interface provide information concerning: + at least one of the respective Plug-in executed functionality; + Sizes used by the respective plug-in to execute the at least one
  • FIGS. Show it: 1 shows an inventive electronic system according to a first preferred embodiment
  • Figure 2 shows the structure of a plug-in
  • FIG. 3 shows a flowchart of a method according to the invention in accordance with a preferred embodiment
  • FIG 4 shows an inventive electronic system according to another preferred embodiment.
  • plug-and-play mechanisms are realized from the prior art for both software and hardware.
  • an additional or a different functionality can be made available in a control unit simply by programming an operating submodule (a so-called plug-in).
  • the plug-in component would be designed as software.
  • plug-in component would be designed as hardware.
  • a particularly preferred field of use of plug-in components is in a control unit network, where additional control units can be added and connected, for example via a CAN bus with the other control units. As a result, additional or different functionalities can be made available to the ECU network.
  • An example of such a known plug-in mechanism is, for example, the integration of an ACC (Adaptive Cruise Control) function into an existing control unit network in a motor vehicle.
  • ACC Adaptive Cruise Control
  • the hardware components required for the ACC function are installed in the motor vehicle, they either immediately or after a restart of the system send defined CAN messages, which in a motor control system provide the corresponding functionalities in a computer program or the interfaces of the functionalities , activated.
  • ACC Adaptive Cruise Control
  • Computer program or the corresponding operating sub-modules (plug-ins), must always be present in the engine control. That is, even if certain functionality is not realized in a motor vehicle, appropriate resources must be provided and maintained to enable the desired functionality when needed.
  • the present invention enables a simple, fully automatic integration of new plug-ins into an existing system during initialization of the electronic system.
  • the invention provides the prerequisite for a particularly advantageous visibility concept for the variables used in the system (eg, variables, functions, structures, etc.).
  • new or modified functionalities can be integrated on a control unit via additional plug-ins without the interfaces, or processes, having to be known in advance to the rest of the system of this control unit.
  • the proposed concept allows for subsequent updates and upgrades of functionalities, without having to reprogram (flash) the entire control unit, for example in a workshop. After downloading the new functionalities to the control unit, these automatically log on in the system and are then fully functional.
  • mechanisms are proposed for automatically coordinating the variable accesses and automatically integrating the processes, taking into account priorities of processes and variables.
  • Figure 1 is an inventive electronic system in its entirety with the
  • the system 1 comprises a basic interface 2 and a plurality of plug-in components 3.1 to 3.n connected thereto.
  • the electronic system 1 can be realized in terms of hardware, with the plug-in 3.1 to 3. n then representing hardware components that can be mechanically plugged into an existing system and electronically contacted.
  • An example of such a hardware implemented plug-in is, for example, a plug-in card with processor, memory and computer program for controlling and / or regulating an ACC functionality in a motor vehicle.
  • the additionally provided processor prevents that or the other processors of the electronic system 1 are stressed too much by the additional ACC functionality.
  • the integration of an additional hardware plug-in is accompanied by the integration of a corresponding software plug-in.
  • the plug-in 3.1 to 3.n realized by software.
  • the entire electronic system 1 is thus a computer program whose functionality can be extended, changed or reduced by adding or removing plug-ins 3.1 to 3. n.
  • basic software 4 is provided, which comprises a fixed, permanent part of the computer program, which is not changed by adding or removing plug-ins.
  • the basic software relates, for example, to communication via bus drivers (for example, a CAN software).
  • the basic software 4 defines the manner in which the plug-ins 3.1 to 3. n communicate with the rest of the computer program, regardless of the number and type of plug-ins 3.1 to 3.n.
  • the base software 4 comprises a so-called identification list 5, to which the basic interface 2 can at least indirectly access during the initialization of the electronic system 1.
  • identification list 5 all theoretically available variables (variables, functions etc.) are listed in the electronic system 1 (compare left column of FIG.
  • Identification list 5 (IDl to IDm) and explained (see right column of the identification list 5; A, B, C to M).
  • the identification list 5 is created for the entire system 1 and not for the currently connected plug-ins 3.1 to 3. n. Therefore, regardless of the number and type of connected plug-ins 3.1 to 3. n, it always has the same content. More precisely, the quantities are resolved via the corresponding names or Ids. These names or Ids are agreed in advance and managed in the identification list 5.
  • the basic interface 2 is set up on the basic software 4 of the electronic system 1 and is responsible for the resolution of the interfaces between the individual plug-ins 3.1 to 3. n.
  • the base software 4 represents the part of the computer program that is not structured according to the plug-in concept (for example, low-level software).
  • the structure of the plug-in 3.1 to 3. n is shown in more detail in FIG. Part 9 of the plug-in 3.1 to 3. n contains the actual functionality of the plug-in 3.1 to 3. n and part 10 the actual initialization function.
  • the part 9 of the plug-ins 3.1 to 3. n comprises at least one additional or changed functionality that is to be made available to the system 1 during runtime. This functionality may be realized by one or more processes included in the functionality part 9.
  • the plug-in interface 10 has no functionality at runtime of the computer program, but contains the information 8 (such as the used sizes of the functionality 9), the Initialization of the function will be needed. The initialization itself takes over the basic interface 2.
  • initialization table 22 Starting from the initialization function 10, a so-called initialization table 22 is called (reference numeral 23). Through the initialization table 22, the base interface 2 knows the addresses of the initialization functions. As an argument, call 23 contains a pointer to initialization routines stored in another table 24. The initialization routines from Table 24 contain the actual functionality of the initialization functions. The base interface 2 then returns an address (or a pointer) to the corresponding initialization routine in the table 24 to the initialization function 10 (reference numeral 25).
  • FIG. 4 shows another electronic system 1 according to the invention in accordance with a further preferred embodiment.
  • the system 1 comprises a plurality of base interfaces 2 arranged in cascaded fashion.
  • a lower base interface 2 is designed as a master interface 2.1.
  • the base interfaces 2 arranged above are designed as so-called subinterfaces 2.2.
  • Plug-ins 3.1 to 3.n and / or sub-interfaces 2.2 are connected to all interfaces 2.1, 2.2.
  • the connected to the interfaces 2.1, 2.2 plug-in 3.1 to 3. n are shown in Figure 4 only symbolically, dashed and in small numbers.
  • FIG. 4 there are some embodiment of the system structure illustrated in FIG. 4, there are some
  • Plug-ins 3.1 to 3. n not directly, but only indirectly connected via sub-interfaces 2.2 to the master interface 2.1.
  • the interfaces 2.1, 2.2 comprise different areas.
  • the visibility concept offers the possibility of using several mutually delimited variable areas, for example public, private, protected, etc.).
  • the variables are encapsulated in the corresponding areas.
  • the interfaces 2.1, 2.2 are subdivided into only two different areas, namely the public area 11 and the private area 12. Only the voltage applied to the public area 11 an interface 2.1, 2.2 public sizes are visible to a subordinate (and therefore higher-ranking) interface 2.1, 2.2.
  • the public area 11 of the sub-interface F is visible to the public area 11 of the sub-interface D.
  • the public area 11 of the sub-interface E is visible for the sub-interface C, but not for the master interface A. The reason for this is that the quantities applied to the public area 11 of the sub-interface E abut the private area 12 of the sub-interface C and are therefore not visible from the underlying interface A.
  • the inventive initialization method for an electronic system 1 begins in a function block 30.
  • the base interface 2 or the master interface 2.1 turns to a first plug-in 3.1 or to a sub-interface 2.2. of the electronic system 1.
  • the plug-in 3.1 transmits to the basic interface 2 information regarding the processes that it carries out. This information relates, for example, to the time grid of the processes, the priorities of the individual processes, etc.
  • the plug-in 3.1 communicates in a function block 32 which variables (variables, functions, structures, etc.) it needs to process the processes.
  • Sub-interfaces 2.2. are treated the same as plug-ins 3.1 to 3.n.
  • a sub-interface 2.2 sends information to the subordinate (ie, higher-level) base interface 2 regarding the processes executed by the plug-ins connected to the sub-interface 2.2.
  • sub-interface 2.2 tells what sizes are needed by the plug-ins attached to them to process their processes.
  • the plug-in 3.1 begins with the transmission of the first required size to the base interface 2. For this purpose, the plug-in 3.1 transmits the corresponding identifier of the size to the base interface 2. Then, in a function block 33 in turn For all other plug-ins 3.2 to 3.n or for all connected to the base interface 2 sub-interfaces 2.2 asked if they can provide the required size.
  • the further search can be set. It can also be adjusted if one
  • Sub-interface 2.2 was found, which can provide the needed size. In this case, the plug-in 3.2 to 3.n or the sub-interface 2.2 would then supply the required size, from which or from which the base interface 2 first learns that he or she needs the required size Can provide.
  • the search will continue until all further plug-ins 3.2 to 3.n and all sub-interfaces 2.2 have been queried as to whether they can provide the required size. From all the plug-ins 3.1 to 3.n and sub-interfaces 2.2, which can provide the required size, the plug-in or the sub-interface 2.2 can be selected, the or the process for determining the required
  • the plug-in 3.2 to 3.n or sub-interface 2.2 would be selected with the highest priority process for determining the required size.
  • the base interface 2 can also be between public and private sizes. This means that the base interface 2 queries the plug-ins 3.1 to 3. n and the sub-interfaces 2.2, whether they can provide the required size in the desired (private or public) area.
  • a plug-in 3.2 to 3.n or a sub-interface 2.2 is selected, which provides a certain size that the plug-in 3.1 needs during the execution of its processes. During the execution of its processes the plugin 3.1 must be able to access the provided size.
  • a pointer 13 is stored in the first plug-in 3.1 (cf., FIG. 1), which points to a memory area 14 in one of the remaining plug-ins 3.2.
  • the size required by the first plug-in 3.1 is stored by the other plug-in 3.2 and possibly updated regularly.
  • a field 15 is provided in the plug-in 3.1, in which the destination address of the pointer 13 can be stored.
  • more fields 16 are provided in which also pointers can be stored in memory areas where the required sizes can be picked up during the processing of the processes.
  • a pointer 18 is stored, which refers to a structure 19.
  • the structure 19 may be stored in any plug-in 3.1 to 3. n or in the base software 4.
  • certain quantities are stored at predetermined positions or in predetermined fields.
  • the sizes can either be stored directly in the fields of the structure 19, or in the fields further pointers 20 are stored, which refer to a corresponding memory area 21 in one of the plugins 3.1 to 3.n or in the base interface 2, where the required size is then stored.
  • the plug-in 3.3 when a certain size is needed, first jump to the beginning of the structure 19. There is then jumped depending on the size required in the corresponding field of the structure 19. In the illustrated embodiment, the third field of the structure 19 is jumped, where an address of the pointer 20 is stored on the memory area 21 in the plug-in 3.n. From there, the current value of the required size is fetched. Thereafter, the processing of the interrupted process in the plug-in 3.3 continues.
  • a query block 35 it is checked whether the plug-in 3.1 has been provided with information for all the quantities it requires, which allows it to access the sizes during the execution of its processes. If not, a branch is made to the function block 32, where the plug-in 3.1 continues with the transmission of the next required size to the base interface 2. The loop comprising the function blocks 32 to 34 and the query block 35 is run through until the plug-in 3.1 information has been transmitted for all sizes required by him.
  • a branch is made to a further query block 36, where it is checked whether all plug-ins 3.1 to 3.sub.n connected to the base interface 2 and all sub-interfaces 2.2 have informed the basic interface 2 which sizes they are need to process their processes. If not, the system branches to the function block 31, where the next plug-in 3.2 or the next sub-interface 2.2 of the basic interface 2 informs about their processes. In the subsequent loop comprising the blocks 32 to 35, information is then transmitted to the next plug-in 3.2, where it can access the quantities it requires. The loop comprising the functional blocks 31 to 34 and the Query blocks 35 and 36 are run through until all connected to the base interface 2 plug-in 3.1 to 3. n and all sub-interfaces 2.2 have informed the base interface 2, which sizes they need to process their processes. As soon as this is the case, the method according to the invention is terminated in a function block 37.
  • the connected to the system 1 plug-in 3.1 to 3. n information regarding the executed by them functionalities, that is, for example, in terms of priority, the time frame, etc. the in them realized processes, spend.
  • the plug-ins 3.1 to 3.n would have to specify the quantities they need to process the processes they implement, and specify the sizes that they can provide by processing the processes they implement. All of this information flows together in the base interface 2 and is processed there in a suitable manner.
  • the plug-ins 3.1 to 3.n which require certain sizes, become pointers
  • the inventive method is realized by a communication protocol that is processed on at least one computing device of the electronic system 1.
  • a computing device is in particular a microprocessor or a microcontroller.
  • Such a computing device for Processing of the communication protocol is, for example, in the base interface 2 and in each of the plug-in 3.1 to 3. n or in the sub-interfaces 2.2 available.
  • the communication protocol for processing by the computing devices is loaded in addition to the operating system and executed fully automatically.
  • the communication protocol can also be executed after a reset of the system 1 (so-called reset), without requiring a complete restart of the system 1.
  • the sub-interface 2.2 forwards the request Framework of the visibility concept to the plug-ins 3.1 to 3. n next.
  • n and the basic software 4 are entered in lists. These lists are provided by the master interface 2.1 for certain operating system task periods (for example, 10 ms). During initialization, the processes to be called in the operating system tasks are entered in the corresponding lists of the scheduler. For split times (for example 30 ms), dividers are calculated which only start this call on the nth task pass (for example, in a 10 ms task every third time). The process lists of the master interface 2.1 are entered in the task management or the entries are retrieved from there.
  • n does not necessarily have to include a process.
  • the plug-in functions use the pointers 13, 18 to access the quantities they require.
  • all variables are referenced via a unique identifier, a so-called identification number ID.
  • identifiers include information about the physical content, unit, data type, and conversion formulas of the corresponding quantities.
  • this requires a central point, which coordinates or manages all available identifiers. The coordination or management of all available identifiers is carried out by the base interface 2 with access to an identification list 5.
  • the supplier is responsible for structuring the plug-ins according to the visibility concept presented above.
  • the plug-in needs to be inserted into the rest of System 1. Everything else is handled master-interface 2.1 during initialization fully automatically. That is, the integrator no longer needs to make any adjustments to the residual system 1 (such as processes integration or the like).
  • the system structure according to the invention can be used, for example, for a control unit, in particular for a motor vehicle control unit (for example an engine control unit), on which applications or functionalities are integrated by different suppliers.
  • a desired functionality can be downloaded (flashed) to a defined area of the control unit. After initialization according to the method according to the invention, this functionality is available in the overall system 1 or in the vehicle without the customer having to intervene in any way.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Initialisieren eines elektronischen Systems (1), das eine Basis-Schnittstelle (2) und mehrere daran angeschlossene modulartige Plug-ins (3.1 bis 3.n) aufweist. Um ein flexibles Hinzufügen und Entfernen von Plug-ins (3.1 bis 3.f) zu ermöglichen, wird erfindungsgemäß vorgeschlagen, dass im Rahmen der Initialisierung des Systems (1) die Basis-Schnittstelle (2) und die Plug-ins Informationen austauschen. Die Plug-ins teilen mit, welche Prozesse (Priorität, Zeitraster etc.) sie enthalten. Außerdem teilen sie mit, welche Größen (Variablen, Funktionen, Strukturen, etc.) sie zur Abarbeitung der Prozesse benötigen und welche Größen sie im Rahmen der Abarbeitung der Prozesse zur Verfügung stellen können. Anhand der erhaltenen Informationen führt die Basis-Schnittstelle (2) eine Verknüpfung der einzelnen Plug¬ ins untereinander durch, so dass die Plug-ins entsprechende Verweise erhalten, wo sie während der Abarbeitung der Prozesse auf die benötigten Größen zugreifen können. Die Verweise sind beispielsweise Zeiger (13) auf einen Speicherbereich (14) oder Zeiger (18) auf eine Struktur (19) in einem anderen Plug-in.

Description

Verfahren zum Initialisieren eines elektronischen Systems umfassend mehrere Plug-ins
Die vorliegende Erfindung betrifft ein Verfahren zum Initialisieren eines elektronischen Systems, das eine Basis-Schnittstelle und mehrere daran angeschlossene modulartige Plug-ins aufweist.
Die Erfindung betrifft außerdem ein Kommunikationsprotokoll zur Abarbeitung auf mindestens einem Rechengerät eines elektronischen Systems während der Initialisierung des elektronischen Systems. Das elektronische System umfasst eine Basis-Schnittstelle und mehrere daran angeschlossene modulartige Plug-ins.
Des weiteren betrifft die Erfindung ein Computerprogramm zur Abarbeitung auf einem Rechengerät einer Datenverarbeitungsanlage. Das Computerprogramm umfasst mehrere Plug-ins und eine Basis-Schnittstelle, wobei die Plug-ins an die Basis-Schnittstelle angeschlossen sind.
Schließlich betrifft die vorliegende Erfindung auch ein elektronisches System mit einem
Rechengerät zur Abarbeitung eines Kommunikationsprotokolls. Das elektronische System umfasst eine Basis-Schnittstelle und mehrere daran angeschlossene modulartige Plug-ins.
Im Automobilbereich wurde Elektronik ursprünglich nur in Form einzelner, elektrifizierter Komponenten eingesetzt, wobei diese Komponenten isoliert und unabhängig voneinander agierten. Später wurden diese Komponenten zunehmend zu Systemen integriert, wobei die Komponenten in den Systemen zum Zwecke eines Datenaustausches und einer gegenseitigen Beeinflussung miteinander in Verbindung gebracht wurden. Beispiele für solche integrierten Systeme sind Motorsteuerungssysteme, Bremsregelungssysteme oder Fahrerinformationssysteme. Derzeit ist ein Trend hin zur Vernetzung aller Fahrzeugsysteme untereinander und zunehmend auch mit der Fahrzeugumwelt zu beobachten.
Dieses erkennbare Zusammenwachsen der Systeme bringt nun erhebliche technische und organisatorische Herausforderungen mit sich: neue Fahrzeugfunktionen sind häufig nur noch im Verbund unterschiedlicher Teilsysteme realisierbar und effektiv nutzbar, - damit wird eine funktionale Integration von Teilsystemen auch unterschiedlicher
Zulieferer erforderlich, die Wertigkeit und der Charakter von Fahrzeugen werden zunehmend durch komplexe Softwarefunktionen bestimmt, und die Beherrschung der wachsenden Systemkomplexität wird für Fahrzeughersteller und Zulieferer in zunehmendem Maße wettbewerbsentscheidend hinsichtlich Geschwindigkeit, Kosten und Qualität der integrierten Systeme.
Stand der Technik
Aus der DE 10044 319 Al ist ein elektronisches System für Fahrzeuge bekannt, welches aus ersten Komponenten zur Durchführung von Steuerungsaufgaben bei Betriebsabläufen und zweiten Komponenten, die ein Zusammenwirken der ersten Komponenten koordinieren, besteht. Die ersten Komponenten führen die Steuerungsaufgaben durch ein Zusammenwirken von Betriebsfunktionen und Basisfunktionen aus. Die Betriebsfunktionen sind in Betriebsteilmodulen (sog. Plug-ins) realisiert und sind in das elektronische System modular einbindbar, wiederverwendbar und jederzeit austauschbar bzw. veränderbar. Die Basisfunktionen sind in einer Basisschicht zusammengefasst, die mit den Betriebsmodulen über eine geeignete Schnittstelle in Verbindung steht.
Zwischen der Basisschicht und der Schnittstelle ist eine Systemschicht vorgesehen, welche die zweiten Komponenten zur Koordination des Zusammenwirkens der ersten Komponenten zur Durchführung der Steuerungsaufgaben umfasst. In der Systemschicht ist also eine Intelligenz vorhanden, welche zum Einbinden der Plug-ins in das Gesamtsystem erforderlich ist. Mit anderen Worten, bauen die Funktionalitäten der Plug Ins auf den Funktionalitäten der Systemschicht auf und setzen diese sogar voraus. Die Plug-ins müssen also auf die Funktionalitäten der Systemschicht abgestimmt sein und können nicht ohne weiteres in anderen elektronischen
Systemen mit anderen Funktionalitäten in der Systemschicht eingesetzt werden. Vor dem Einsatz der Plug-ins in einer anderen Systemumgebung ist eine zeit- und kostenintensive Adaption der Plug-ins erforderlich. Des weiteren kann es erforderlich sein, bei einer Änderung oder Ergänzung der Funktionalitäten der ersten Komponenten auch die Funktionalitäten der Systemschicht anzupassen, da eine Überarbeitung der ersten Komponenten Auswirkungen auf die Koordination der Komponenten, das heißt auf die Systemschicht, haben kann. In den bekannten Systemen werden also bezüglich der Behandlung von Plug Ins lediglich Insellösungen zur Verfügung gestellt, die ohne umfangreiche Adaptionen nicht einfach auf andere Systeme übertragbar sind.
Außerdem wird bei dem bekannten elektronischen System die Initialisierung des Systems und die Verknüpfung der Plug Ins untereinander nicht durch die Plug-ins selbst, sondern allein durch die Systemschicht und/oder eine darunter liegende Betriebssystemschicht realisiert. Die Initialisierung wird also zentral gesteuert, eine Kommunikation zwischen den Plug-ins des Systems vor oder während der Initialisierung findet nicht statt.
Ausgehend von diesem Stand der Technik liegt der vorliegenden Erfindung die Aufgabe zugrunde, das bekannte Verfahren dahingehend auszugestalten und weiterzubilden, dass die Initialisierung des elektronischen Systems wesentlich flexibler als bisher ausgeführt werden kann. Insbesondere sollen die Verknüpfungen der Plug-ins untereinander im Rahmen der Initialisierung vollautomatisch erzeugt werden, ohne dass dem elektronischen System die Art und Anzahl der angeschlossenen Plug-ins und deren Funktionalitäten bzw. Prozesse im Vorfeld bekannt sein müssen.
Zur Lösung dieser Aufgabe wird ausgehend von dem Verfahren der eingangs genannten Art vorgeschlagen, dass beim Initialisieren des elektronischen Systems der Basis-Schnittstelle durch die Plug-ins jeweils Informationen zur Verfügung gestellt werden betreffend: + mindestens eine von dem jeweiligen Plug-in ausgeführte Funktionalität;
+ Größen, die von dem jeweiligen Plug-in zur Ausführung der mindestens einen
Funktionalität benötigt werden;
+ Größen, die von dem jeweiligen Plug-in nach Ausführung der mindestens einen Funktionalität zur Verfügung gestellt werden, den einzelnen Plug-ins durch die Basis-Schnittstelle Informationen zur Verfügung gestellt werden betreffend:
+ welcher der übrigen Plug-ins eine von dem Plug-in benötigte Größe zur
Verfügung stellt, und - ein entsprechender Verweis auf denjenigen Plug-in, der die Größe zur Verfügung stellt, in demjenigen Plug-in abgelegt wird, der die Größe benötigt.
Vorteile der Erfindung
Nach dem erfindungsgemäßen Verfahren wird im Rahmen der Initialisierung des elektronischen Systems zunächst jeder der die Basis-Schnittstelle angeschlossenen Plug-ins nach bestimmten Informationen abgefragt. Diese Informationen betreffen beispielsweise die in dem Plug-in realisierten Funktionalitäten bzw. die entsprechenden Prozesse. Außerdem betreffen die Informationen die durch die Abarbeitung der Prozesse ermittelten und durch den Plug-in zur Verfügung gestellten Größen, sowie die Größen, die der Plug-in zur Ausführung der Funktionalitäten bzw. zur Abarbeitung der Prozesse benötigt. Größen im Sinne der vorliegenden Erfindung sind beispielsweise Variablen, Funktionen, Strukturen, etc. Die Plug-ins des erfindungsgemäßen elektronischen Systems verfügen also über eine zusätzliche Initialisierungs- Funktionalität, um auf die entsprechenden Anfragen der Basis-Schnittstelle zu antworten und die gewünschten Informationen zu übermitteln.
Nach dem Erhalt der Informationen von einem ersten Plug-in fragt die Basis-Schnittstelle die übrigen Plug-ins, ob sie zumindest eine der benötigten Größen zur Verfügung stellen können. Falls das der Fall ist, werden dem ersten Plug-in durch die Basis-Schnittstelle Informationen zur
Verfügung gestellt betreffend welcher der übrigen Plug-ins die von dem ersten Plug-in benötigte Größen zur Verfügung stellt. Dann wird an einer bestimmten Stelle in dem ersten Plug-in ein entsprechender Verweis auf diejenigen Plug-ins eingetragen, welche die benötigten Größen zur Verfügung stellen. Ein Plug-in des erfindungsgemäßen elektronischen Systems verfügt also über die zusätzliche Initialisierungs-Funktionalität, um die empfangenen Verweise auf eine oder mehrere Plug-ins, welche die von dem Plug-in benötigten Größen zur Verfügung stellen, an geeigneter Stelle abzuspeichern.
Vorzugsweise ist in den Plug-ins mindestens ein leeres Feld vorgesehen, wo der Verweis abgelegt werden kann. Jedes Mal wenn im Rahmen der Abarbeitung eines Prozesses in einem ersten Plugin eine bestimmte Größe von einem anderen Plug-in benötigt wird, wird die Größe über den Verweis von dem anderen Plug-in geholt. Selbstverständlich können in den Plug-ins auch mehrere Verweise auf verschiedene andere Plug-ins abgelegt werden, insbesondere dann wenn in einem Plug-in verschiedene Größen benötigt werden. Die Verweise auf die anderen Plug-ins können beliebiger Art sein.
Mit dem erfindungsgemäßen Verfahren können in Laufzeit während der Initialisierung des elektrischen Systems die Verknüpfungen zwischen den Plug-ins erstellt werden und zwar unabhängig davon, welche Plug-ins tatsächlich an die Basis-Schnittstelle angeschlossen sind, und ohne dass im Vorfeld bekannt sein muss, welche Plug-ins angeschlossen sind. Das erfindungsgemäße Verfahren ermöglicht ein Höchstmaß an Flexibilität hinsichtlich Hinzufügen, Entfernen und Ändern von Plug-ins eines elektronischen Systems.
Die Plug-ins können als Hardware (bspw. als Einsteckkarten mit zusätzlichen Input/Output- Schnittstellen, zusätzlichen Treibern, zusätzlichen Speicher- oder Rechenkapazitäten, etc. für ein Steuergerät) oder als Software (bspw. als Betriebsteilmodule eines Computerprogramms) ausgebildet sein. Die Basis-Schnittstelle verfügt über keinerlei Funktionalität zur Ergänzung der
Funktionalitäten der Plug-ins. Die Aufgabe der Basis-Schnittstelle betrifft lediglich die Verknüpfung der Plug-ins während der Initialisierung und die Kommunikation zwischen den Plug-ins während des Betriebs des elektrischen Systems. Die dazu erforderlichen Informationen über die Plug-ins erhält die Basis-Schnittstelle direkt von den Plug-ins während der Initialisierungsphase des elektronischen Systems durch eine Kommunikation mit den Plug-ins.
Gemäß einer vorteilhaften Weiterbildung der Erfindung wird vorgeschlagen, dass die mindestens eine Funktionalität durch mindestens einen Prozess realisiert ist. Das heißt die Funktionalitäten der Plug-ins werden durch einen oder mehrere Prozesse realisiert. Die Übermittlung von Informationen hinsichtlich der Funktionalität der Plug-ins betrifft somit beliebige Informationen hinsichtlich der in dem Plug-in realisierten Prozesse. Vorteilhafterweise umfassen die Informationen betreffend die Funktionalität der Plug-ins ein Zeitraster, in dem der mindestens eine Prozess abgearbeitet wird, und eine Priorität des mindestens einen Prozesses.
Gemäß einer bevorzugten Ausführungsform der Erfindung wird vorgeschlagen, dass in dem Plugin, der eine bestimmte Größe benötigt, als Verweis ein Zeiger auf einen Speicherplatz abgelegt wird, an dem die benötigte Größe durch einen der übrigen Plug-ins gespeichert wird. Der Speicherplatz, auf den verwiesen wird, kann in einem der Plug-ins, aber auch in der Basis- Schnittstelle oder einer untergeordneten Basisfunktionalität oder Basissoftware vorgesehen sein. Das Arbeiten mit Zeigern hat mehrere Vorteile. Ein Vorteil besteht darin, dass bei einem Update der Software in einem Plug-in die alte Software im Speicher verbleiben kann, die neue Software an eine andere neue Stelle im Speicher abgelegt wird und der Zeiger einfach auf die neue Speicherstelle umgesetzt wird. Ein erneutes Programmieren (sog. Flashen) des gesamten Speichers (Löschen des alten Inhalts und Beschreiben mit der neuen Software) ist somit nicht erforderlich.
Gemäß einer anderen bevorzugten Ausführungsform der vorliegenden Erfindung wird vorgeschlagen, dass in dem Plug-in, der eine Größe benötigt, als Verweis ein Zeiger auf eine Struktur abgelegt wird, in der an einer vorgegebenen Position die benötigte Größe durch einen der übrigen Plug-ins gespeichert wird. Gemäß dieser Ausführungsform wird also nicht für jede benötigte Größe ein gesonderter Zeiger auf einen Speicherplatz abgelegt, wo die benötigte Größe abgespeichert ist, sondern lediglich ein einziger Zeiger auf eine Struktur abgelegt, wo sämtliche benötigten Größen abgelegt sind. Die Struktur umfasst eine bestimmte Anzahl an Feldern, wobei in bestimmten Feldern bestimmte Größen abgespeichert sind. So wird beispielsweise vorab definiert, dass eine Größe A immer an der dritten Position in der Struktur abgelegt wird. Wenn in einem Plug-in die Größe A benötigt wird, wird aus dem Plug-in an den Anfang der Struktur gesprungen, auf den der Zeiger zeigt. In Abhängigkeit von der benötigten Größe wird an die entsprechende Position bzw. das entsprechende Feld der Struktur gesprungen, das heißt für die Größe A wird an die dritte Position gesprungen, die benötigte Größe wird ausgelesen und dann wieder zu dem Plug-in zurückgekehrt. Die Struktur kann in der Basis-Schnittstelle oder der untergeordneten Basisfunktionalität oder Basissoftware enthalten sein. Der Inhalt der Struktur wird durch die Plug-ins, welche die entsprechenden Größen zur Verfugung stellen, kontinuierlich aktualisiert. Diese Ausfuhrungsform hat den Vorteil, dass in den Plug-ins lediglich ein Feld für den Zeiger, der auf den Anfang der Struktur zeigt, benötigt wird, selbst wenn in dem Plug-in mehr als eine Größe benötigt wird.
Falls eine bestimmte Größe von mehreren Plug-ins zur Verfügung gestellt wird, stellt sich die Frage, welche der Plug-ins die Größe für die übrigen Plug-ins, welche die Größe benötigen, zur Verfügung stellen soll. In einem solchen Fall wird vorteilhafterweise die Größe von demjenigen Plug-in zur Weiterverarbeitung herangezogen, dessen Prozess zur Ermittlung der Größe die höchste Priorität aufweist. Da dieser Prozess die höchste Priorität aufweist, wird er vor den anderen Prozessen die benötigte Größe zur Verfügung stellen können.
Des weiteren kann es unter bestimmten Bedingungen vorteilhaft sein, dass in einem solchen Fall die Größe von demjenigen Plug-in zur Verfügung gestellt wird, von dem die Basis-Schnittstelle als erstes die Information erhält, dass der Plug-in bzw. ein Prozess des Plug-ins die benötigte Größe zur Verfügung stellen kann. Alternativ wird vorgeschlagen, dass die Größe von demjenigen Plug-in zur Verfügung gestellt wird, von dem die Basis-Schnittstelle als letztes die Information erhält, dass der Plug-in bzw. ein Prozess des Plug-ins die benötigte Größe zur Verfügung stellen kann.
Es sinnvoll, dass die Basis-Schnittstelle Zugriff auf eine Initialisierungstabelle mit Informationen hat, wo die einzelnen Plug-ins abgelegt sind. Diese Tabelle kann - wenn die Plug-ins als Software ausgebildet sind - beim Flashen neuer Plug-ins aktualisiert werden. Bei als Software, aber auch als Hardware ausgebildeten Plug-ins ist es aber auch denkbar, dass zu Beginn der Initialisierung die an die Basis-Schnittstelle angeschlossenen Plug-ins und ihre (Anfangs-) Adressen ermittelt werden und die Tabelle dementsprechend aktualisiert wird. Die Tabelle ist vorzugsweise in der Basis-Schnittstelle abgespeichert. Anhand dieser Tabelle kann die Basis-Schnittstelle dann die einzelnen Plug-ins abfragen und die gewünschten Informationen einholen.
Falls das elektronische System als ein Computerprogramm ausgebildet ist, ist eine Strukturierung des Computerprogramms in eine Basis-Software ohne Plug-ins, eine darüber angeordnete Master- Schnittstelle und daran angeschlossene Plug-ins und/ oder Sub-Schnittstellen, an die weitere SubSchnittstellen und/ oder weitere Plug-ins angeschlossen sind, denkbar. Die Basis-Software umfasst einen festen, permanenten Teil der Software, der beispielsweise für die Kommunikation über Bus-Treiber, etc. zuständig ist. Auf diese Weise lässt sich gewissermaßen eine kaskadierte Struktur des elektronischen Systems erzielen. Für diese Struktur kann ein Sichtbarkeitskonzept realisiert werden, durch das es möglich ist, die Sichtbarkeit bestimmter Größen von unten, das heißt von ranghöheren Bereichen aus, auf bestimmte rangniedrigere Bereiche der Struktur zu beschränken. Diesbezüglich wird ein Verfahren zum Initialisieren eines elektronischen Systems umfassend eine Basis-Schnittstelle und mehrere daran angeschlossene modulartige Plug-ins vorgeschlagen, wobei eine der Basis-Schnittstellen als eine Master-Schnittstelle und die übrigen Basis-Schnittstellen als Sub-Schnittstellen ausgebildet sind und an die Master-Schnittstelle außer den Plug-ins noch Sub-Schnittstellen angeschlossen sind, an die wiederum weitere SubSchnittstellen und/ oder weitere Plug-ins und so weiter angeschlossen sind. Die Schnittstellen sind in unterschiedliche Bereiche (z. B. privat, öffentlich, geschützt, etc.) unterteilt. Lediglich die innerhalb des gleichen Bereichs der Schnittstellen anliegenden Größen (Variablen, Funktionen, etc.) sind für untergeordnete (das heißt höherrangige) Schnittstellen sichtbar und damit auch zugänglich. Die gleiche Größe kann an unterschiedlichen Bereichen einer Schnittstelle anliegen. Dadurch können die Größen in bestimmten Bereichen gekapselt werden und ähneln gewissermaßen lokalen Variablen.
Vorteilhafterweise sind die Schnittstellen in einen privaten Bereich und einen öffentlichen Bereich unterteilt. Lediglich die an dem öffentlichen Bereich einer Schnittstelle anliegenden öffentlichen Größen (Variablen, Funktionen, etc.) sind für eine untergeordnete Schnittstelle sichtbar und damit auch zugänglich. Die an dem privaten Bereich der Schnittstelle anliegenden privaten Größen sind lediglich in der betreffenden Schnittstelle und öffentlichen Bereichen von darüber angeordneten Schnittstellen sichtbar.
Mit dieser kaskadierten Struktur des elektronischen Systems und der Aufteilung der Schnittstellen in einen privaten und eine öffentlichen Bereich können bspw. bei einem Computerprogramm abgeschlossene Programmbereiche geschaffen werden. Dies ist von Vorteil, wenn ein bestimmter Programmbereich von externen Zulieferern entwickelt und programmiert wird. Wie der Entwurf, die Struktur und die eigentliche Programmierung (welche Größen, Funktionen, Strukturen verwendet wurden, welche Algorithmen ausgeführt werden, etc.) im Detail ausgestaltet ist, ist für den Auftraggeber nicht von Bedeutung. Wichtig ist allein, dass der Programmbereich die von ihm geforderte Funktionalität erfüllt, das heißt dass in ihm die geforderten Prozesse realisiert sind, und dass er untergeordneten (das heißt ranghöheren) Schnittstellen die geforderten öffentlichen Größen zur Verfügung stellt.
Eine untergeordnete Schnittstelle hat nur Zugriff auf die an den öffentlichen Bereichen der übergeordneten Schnittstellen anliegenden Größen. Die an den privaten Bereichen anliegenden Größen sind für die untergeordnete Schnittstelle nicht sichtbar und somit auch nicht zugänglich. Damit wird also auf einfache Weise eine Kapselung von Programmbereichen bzw. der darin realisierten Funktionalitäten ermöglicht. Die fremdentwickelten Programmbereiche können mit Hilfe dieses Sichtbarkeitskonzepts auch einfach und schnell in ein bestehendes Computerprogramm integriert werden.
Zur leichteren Handhabbarkeit der Größen innerhalb der Plug-ins und der Basis-Schnittstelle wird vorgeschlagen, dass jeder von den Plug-ins benötigten oder von den Plug-ins zur Verfügung gestellten Größe eine für einen definierten Bereich des elektronischen Systems eindeutige Kennung zugeordnet wird. Der definierte Bereich ist vorzugsweise der mittels des Sichtbarkeitskonzepts abgeschlossene Bereich des elektronischen Systems. Die Kennung umfasst bspw. eine Identifikationsnummer und eine Angabe, ob die Größe öffentlich oder privat ist. Selbstverständlich ist es denkbar, nicht nur den Variablen, sondern auch Funktionen, Strukturen u. a. eine solche oder eine andere eindeutige Kennung zuzuordnen.
Vorteilhafterweise sind die Kennungen der Größen in einer Kennungsliste abgelegt, auf welche die Basis-Schnittstelle während der Initialisierung des elektronischen Systems zugreifen kann. Es ist denkbar, dass in der Kennungsliste alle in dem elektronischen System theoretisch verfügbaren Größen (Variablen, Funktionen, etc.) aufgelistet und erläutert sind. Die Liste wird für das Gesamtsystem und nicht für die derzeit angeschlossenen Plug-ins erstellt. Deshalb hat sie unabhängig von der Art und Anzahl der angeschlossenen Plug-ins stets den gleichen Inhalt.
Insofern kann auch davon gesprochen werden, dass bei der Erfindung die Basis-Schnittstelle vorab keine Informationen über die tatsächlich angeschlossenen Plug-ins zur Verfügung stehen. Die Liste stellt vorzugsweise die Basis für eine Schnittstellenvereinbarung bzw. Schnittstellendefinition dar und dient sowohl dem Zulieferer von Software bzw. Plug-ins als auch dem Integrator als Basis.
Als eine weitere Lösung der Aufgabe der vorliegenden Erfindung wird ausgehend von dem Kommunikationsprotokoll der eingangs genannten Art vorgeschlagen, dass das Kommunikationsprotokoll derart programmiert ist, dass beim Initialisieren des elektronischen Systems der Basis-Schnittstelle durch die Plug-ins jeweils Informationen zur Verfügung gestellt werden betreffend: + mindestens eine von dem jeweiligen Plug-in ausgeführte Funktionalität;
+ Größen, die von dem jeweiligen Plug-in zur Ausführung der mindestens einen
Funktionalität benötigt werden;
+ Größen, die von dem jeweiligen Plug-in nach Ausführung der mindestens einen
Funktionalität zur Verfügung gestellt werden, - den einzelnen Plug-ins durch die Basis-Schnittstelle Informationen zur Verfügung gestellt werden betreffend:
+ welcher der übrigen Plug-ins eine von dem Plug-in benötigte Größe zur
Verfügung stellt, und ein entsprechender Verweis auf denjenigen Plug-in, der die Größe zur Verfügung stellt, in demjenigen Plug-in abgelegt wird, der die Größe benötigt.
Als noch eine Lösung der Aufgabe der vorliegenden Erfindung wird ausgehend von dem Computerprogramm der eingangs genannten Art vorgeschlagen, dass beim Initialisieren des elektronischen Systems die Plug-ins der Basis-Schnittstelle jeweils Informationen zur Verfügung stellen betreffend:
+ mindestens eine von dem jeweiligen Plug-in ausgeführte Funktionalität,
+ Größen, die von dem jeweiligen Plug-in zur Ausführung der mindestens einen
Funktionalität benötigt werden, und
+ Größen, die von dem jeweiligen Plug-in nach Ausführung der mindestens einen Funktionalität zur Verfügung gestellt werden; die Basis-Schnittstelle den einzelnen Plug-ins Informationen zur Verfügung stellt betreffend: + welcher der übrigen Plug-ins eine von dem Plug-in benötigte Größe zur
Verfugung stellt; und ein entsprechender Verweis auf denjenigen Plug-in, der die Größe zur Verfügung stellt, in demjenigen Plug-in abgelegt wird, der die Größe benötigt.
In diesem Fall ist also das elektronische System als ein Computerprogramm ausgebildet, so dass es sich bei den Plug-ins um Betriebsteilmodule eines Computerprogarmms handelt. Demnach wird also die Erfindung durch das Computerprogramm realisiert.
Als eine weitere Lösung der Aufgabe der vorliegenden Erfindung wird ausgehend von dem elektronischen System der eingangs genannten Art vorgeschlagen, dass die Plug-ins im Rahmen der Initialisierung des elektronischen Systems der Basis- Schnittstelle jeweils Informationen zur Verfügung stellen betreffend: + mindestens eine von dem jeweiligen Plug-in ausgeführte Funktionalität; + Größen, die von dem jeweiligen Plug-in zur Ausführung der mindestens einen
Funktionalität benötigt werden;
+ Größen, die von dem jeweiligen Plug-in nach Ausführung der mindestens einen
Funktionalität zur Verfügung gestellt werden, den einzelnen Plug-ins durch die Basis-Schnittstelle Informationen zur Verfügung gestellt werden betreffend:
+ welcher der übrigen Plug-ins eine von dem Plug-in benötigte Größe zur Verfügung stellt, und ein entsprechender Verweis auf denjenigen Plug-in, der die Größe zur Verfügung stellt, in demjenigen Plug-in abgelegt wird, der die Größe benötigt.
Zeichnungen
Nachfolgend werden bevorzugte Ausführungsbeispiele der Erfindung anhand der Figuren näher erläutert. Es zeigen: Figur 1 ein erfindungsgemäßes elektronisches System gemäß einer ersten bevorzugten Ausfuhrungsform;
Figur 2 der Aufbau eines Plug-ins;
Figur 3 ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens gemäß einer bevorzugten Ausfuhrungsform; und
Figur 4 ein erfindungsgemäßes elektronisches System gemäß einer weiteren bevorzugten Ausfuhrungsform.
Beschreibung der Ausführungsbeispiele
In Steuergeräten, insbesondere in Kraftfahrzeugsteuergeräten, sind aus dem Stand der Technik sowohl für Software als auch für Hardware Plug-and-Play-Mechanismen realisiert. Dadurch kann beispielsweise in einem Steuergerät durch einfaches Programmieren eines Betriebsteilmoduls (eines sogenannten Plug-ins) eine zusätzliche oder eine andere Funktionalität zur Verfügung gestellt werden. In einem solchen Fall wäre die Plug-In-Komponente als Software ausgebildet.
Ebenso ist es möglich, durch mechanisches Einstecken und elektrisches Kontaktieren eines zusätzlichen Hardwaremoduls die Funktionalität des Steuergerätes zu ändern oder zu erweitern. In einem solchen Fall wäre die Plug-In-Komponente als Hardware ausgebildet. Ein besonders bevorzugter Einsatzbereich von Plug-In-Komponenten ist in einem Steuergeräte- Verbund, wo zusätzliche Steuergeräte hinzugefügt werden können und beispielsweise über einen CAN-Bus mit den übrigen Steuergeräten verbunden werden können. Dadurch können dem Steuergeräte- Verbund zusätzliche oder andere Funktionalitäten zur Verfügung gestellt werden.
Die bekannten Plug-In-Mechanismen haben jedoch den Nachteil, dass sowohl die
Funktionalitäten als auch die Schnittstellen der Plug-ins, das heißt welche Größen sie zur Verfügung stellen können und welche Größen sie benötigen, vorab bekannt sein müssen und entsprechende Ressourcen vorgehalten werden müssen, unabhängig davon ob die Plug-InKomponenten tatsächlich angeschlossen sind oder nicht. Vorab bedeutet in diesem Zusammenhang zum Zeitpunkt der Integration einer neuen Plug-In-Komponente. Mit anderen Worten, bevor das neue Plug-in integriert werden kann, müssen die angegebenen Informationen bekannt sein. Deshalb werden die Informationen an zentraler Stelle in dem elektronischen System vorgehalten und können von dort bei Bedarf abgerufen werden.
Ein Beispiel für einen solchen bekannten Plug-In-Mechanismus ist beispielsweise die Integration einer ACC (Adaptive Cruise Control)-Funktion in einen bestehenden Steuergeräteverbund in einem Kraftfahrzeug. Sobald die für die ACC-Funktion erforderlichen Hardware-Bauteile in das Kraftfahrzeug eingebaut werden, senden diese entweder sofort oder erst nach einem erneuten Hochfahren des Systems definierte CAN-Botschaften, die in einer Motorsteuerung die entsprechenden Funktionalitäten in einem Computerprogramm, beziehungsweise die Schnittstellen der Funktionalitäten, aktiviert. Nachteilig ist dabei jedoch, dass unabhängig davon ob die ACC- Hardware in dem Kraftfahrzeug verbaut ist oder nicht, die ACC-Funktionalität in dem
Computerprogramm, beziehungsweise die entsprechenden Betriebsteilmodule (Plug-ins), in der Motorsteuerung immer vorhanden sein muss. Das heißt, dass selbst wenn eine bestimmte Funktionalität in einem Kraftfahrzeug nicht realisiert ist, müssen entsprechende Ressourcen bereitgestellt und vorgehalten werden, um im Bedarfsfall die gewünschte Funktionalität freizuschalten.
Darüber hinaus ist es bei den bekannten Plug-In-Mechanismen nachteilig, dass eine zu integrierende Funktionalität immer auch eine manuelle Modifikation des übrigen Systems, beispielsweise ein Einbinden der neuen Prozesse der zusätzlich vorgesehenen Betriebsteilmodule (Plug-ins), vorgenommen werden muss. Eine nachträgliche Integration einer zusätzlichen
Funktionalität in ein bereits programmiertes (geflashtes) Steuergerät, das heißt ein sogenannter Update oder Upgrade im Feld, ist ebenfalls nicht oder nur mit großem Aufwand möglich.
Genau hier setzt die vorliegende Erfindung an. Sie ermöglicht eine einfache, vollautomatische, während der Initialisierung des elektronischen Systems in Laufzeit ausgeführte Integration von neuen Plug-ins in ein bereits bestehendes System. Zudem bietet die Erfindung die Voraussetzung für ein besonders vorteilhaftes Sichtbarkeitskonzept für die in dem System verwendeten Größen (zum Beispiel Variablen, Funktionen, Strukturen, etc.).
Mit Hilfe der Erfindung können über zusätzliche Plug-ins neue, beziehungsweise geänderte, Funktionalitäten auf einem Steuergerät integriert werden, ohne dass dem restlichen System dieses Steuergerätes die Schnittstellen, beziehungsweise Prozesse, im Vorfeld bekannt sein müssen. Das vorgeschlagene Konzept erlaubt nachträgliche Updates und Upgrades von Funktionalitäten, ohne dass hierfür das komplette Steuergerät, zum Beispiel in einer Werkstatt, neu programmiert (geflasht) werden muss. Nach dem Herunterladen der neuen Funktionalitäten auf das Steuergerät melden sich diese im System automatisch an und sind danach in vollem Umfang funktionsfähig. Insbesondere werden erfindungsgemäß Mechanismen zur automatischen Koordinierung der variablen Zugriffe und zur automatischen Einbindung der Prozesse unter Beachtung von Prioritäten von Prozessen und Variablen vorgeschlagen.
In Figur 1 ist ein erfindungsgemäßes elektronisches System in seiner Gesamtheit mit dem
Bezugszeichen 1 bezeichnet. Das System 1 umfasst eine Basis-Schnittstelle 2 und mehrere daran angeschlossene Plug-In-Komponenten (kurz: Plug-ins) 3.1 bis 3.n. Das elektronische System 1 kann hardwaremäßig realisiert sein, wobei die Plug-ins 3.1 bis 3. n dann Hardware-Komponenten darstellen, die in ein bestehendes System mechanisch eingesteckt und elektronisch kontaktiert werden können. Ein Beispiel für einen solchen hardwaremäßig realisierten Plug-in ist beispielsweise eine Steckkarte mit Prozessor, Speicher und Computerprogramm zur Steuerung und/oder Regelung einer ACC-Funktionalität in einem Kraftfahrzeug. Durch den zusätzlich vorgesehenen Prozessor wird verhindert, dass der oder die übrigen Prozessoren des elektronischen Systems 1 durch die zusätzliche ACC-Funktionalität zu sehr beansprucht werden. In der Regel geht die Integration eines zusätzlichen Hardware-Plug-ins mit der Integration eines entsprechenden Software-Plug-ins einher.
Bei dem in Figur 1 dargestellten Ausführungsbeispiel sind die Plug-ins 3.1 bis 3.n jedoch softwaremäßig realisiert. Das gesamte elektronische System 1 ist also ein Computerprogramm, dessen Funktionalität durch Hinzufügen oder Entfernen von Plug-ins 3.1 bis 3. n erweitert, geändert oder verringert werden kann. Unterhalb der Basis-Schnittstelle 2 ist eine Basis-Software 4 vorgesehen, die einen festen, permanenten Teil des Computerprogramms umfasst, der durch Hinzufügen oder Entfernen von Plug-ins nicht verändert wird. Die Basis-Software betrifft beispielsweise die Kommunikation über Bus-Treiber (zum Beispiel eine CAN-Software). Außerdem ist in der Basis-Software 4 die Art und Weise definiert, wie sich die Plug-ins 3.1 bis 3. n mit dem restlichen Computerprogramm unterhalten, unabhängig von der Anzahl und der Art der angeschlossenen Plug-ins 3.1 bis 3.n. Außerdem umfasst die Basis-Software 4 eine sogenannte Kennungsliste 5, aufweiche die Basis- Schnittstelle 2 während der Initialisierung des elektronischen Systems 1 zumindest indirekt zugreifen kann. In der Kennungsliste 5 sind alle in dem elektronischen System 1 theoretisch verfügbaren Größen (Variablen, Funktionen etc.) aufgelistet (vergleiche linke Spalte der
Kennungsliste 5; IDl bis IDm) und erläutert (vergleiche rechte Spalte der Kennungsliste 5; A, B, C bis M). Die Kennungsliste 5 wird für das gesamte System 1 und nicht für die derzeit angeschlossenen Plug-ins 3.1 bis 3. n erstellt. Deshalb hat sie unabhängig von der Anzahl und der Art der angeschlossenen Plug-ins 3.1 bis 3. n stets den gleichen Inhalt. Genauer gesagt, werden die Größen über die entsprechenden Namen bzw. Ids aufgelöst. Diese Namen bzw. Ids werden vorab vereinbart und in der Kennungsliste 5 verwaltet.
Die Basis-Schnittstelle 2 ist auf die Basis-Software 4 des elektronischen Systems 1 aufgesetzt und ist für die Auflösung der Schnittstellen zwischen den einzelnen Plug-ins 3.1 bis 3. n verantwortlich. Die Basis-Software 4 stellt den Teil des Computerprogramms dar, der nicht nach dem Plug-In-Konzept strukturiert ist (zum Beispiel Low-Level-Software).
Bei der vorliegenden Erfindung wird unterschieden zwischen eigentlichem Plug-In-Teil 9 und Plug-In-Schnittstelle 10. Der Aufbau des Plug-ins 3.1 bis 3. n ist in Figur 2 näher dargestellt. Der Teil 9 des Plug-in 3.1 bis 3. n beinhaltet die eigentliche Funktionalität des Plug-in 3.1 bis 3. n und der Teil 10 die eigentliche Initialisierungsfunktion. Der Teil 9 der Plug-ins 3.1 bis 3. n umfasst mindestens eine zusätzliche oder geänderte Funktionalität, die dem System 1 während der Laufzeit zur Verfügung gestellt werden soll. Diese Funktionalität kann durch einen oder mehrere Prozesse realisiert sein, die in dem Teil 9 für die Funktionalität enthalten sind. Die Plug-In- Schnittstelle 10 besitzt keine Funktionalität zur Laufzeit des Computerprogramms, sondern enthält die Informationen 8 (wie z. B. die verwendeten Größen der Funktionalität 9), die zur Initialisierung der Funktion benötigt werden. Die Initialisierung selbst übernimmt die Basis- Schnittstelle 2.
Ausgehend von der Initialisierungsfunktion 10 wird eine sogenannte Initialisierungstabelle 22 aufgerufen (Bezugszeichen 23). Durch die Initialisierungstabelle 22 kennt die Basis-Schnittstelle 2 die Adressen der Initialisierungsfunktionen. Als Argument enthält der Aufruf 23 einen Zeiger auf Initialisierungsroutinen, die in einer anderen Tabelle 24 abgelegt sind. Die Initialisierungsroutinen aus der Tabelle 24 enthalten die eigentliche Funktionalität der Initialisierungsfunktionen. Von der Basis-Schnittstelle 2 wird dann eine Adresse (bzw. ein Zeiger) auf die entsprechende Initialisierungsroutine in der Tabelle 24 an die Initialisierungsfunktion 10 zurückgegeben (Bezugszeichen 25).
In Figur 4 ist ein anderes erfindungsgemäßes elektronisches System 1 gemäß einer weiteren bevorzugten Ausführungsform dargestellt. Das System 1 umfasst eine Mehrzahl übereinander kaskadiert angeordneter Basis-Schnittstellen 2. Eine untere Basis-Schnittstelle 2 ist als eine Master-Schnittstelle 2.1 ausgebildet. Die darüber angeordneten Basis-Schnittstellen 2 sind als sogenannte Sub-Schnittstellen 2.2 ausgebildet. An alle Schnittstellen 2.1, 2.2 sind Plug-ins 3.1 bis 3.n und/oder Sub-Schnittstellen 2.2 angeschlossen. Die an die Schnittstellen 2.1, 2.2 angeschlossenen Plug-ins 3.1 bis 3. n sind in Figur 4 lediglich symbolisch, gestrichelt und in geringer Anzahl, dargestellt. Bei der in Figur 4 dargestellten Systemstruktur sind also einige
Plug-ins 3.1 bis 3. n nicht unmittelbar, sondern lediglich mittelbar über Sub-Schnittstellen 2.2 an die Master-Schnittstelle 2.1 angeschlossen.
Die Schnittstellen 2.1, 2.2 umfassen unterschiedliche Bereiche. Durch das Sichtbarkeitskonzept gibt es die Möglichkeit der Nutzung mehrerer gegeneinander abgegrenzter Variablenbereiche, zum Beispiel öffentlich, privat, geschützt etc.). Dabei werden die Variablen in den entsprechenden Bereichen gekapselt.
Bei dem in Figur 4 dargestellten Ausführungsbeispiel sind die Schnittstellen 2.1, 2.2 lediglich in zwei unterschiedliche Bereiche, nämlich den öffentlichen Bereich 11 und den privaten Bereich 12 unterteilt. Lediglich die an dem öffentlichen Bereich 11 einer Schnittstelle 2.1, 2.2 anliegenden öffentlichen Größen sind für eine untergeordnete (und damit ranghöhere) Schnittstelle 2.1, 2.2 sichtbar.
Nach erfolgter Initialisierung sind in dem System 1 aus Figur 4 also die folgenden Sichten gegeben: Der öffentliche Bereich 11 , ausgehend von der Master-Schnittstelle 2.1, erstreckt sich über die öffentlichen Bereiche 11 der Sub-Schnittstellen 2.2 mit den Bezeichnungen C, D und F. Das heißt aus dem öffentlichen Bereich 11 der Master-Schnittstelle A heraus kann auf den öffentlichen Bereich 11 der Sub-Schnittstelle C, sowie auf den öffentlichen Bereich 11 der SubSchnittstelle D zugegriffen werden. Mit andere Worten sind die öffentlichen Bereiche der Sub- Schnittstellen C, D von dem öffentlichen Bereich 11 der Master-Schnittstelle A aus zugänglich. Der öffentliche Bereich 11 der Sub-Schnittstelle F ist für den öffentlichen Bereich 11 der SubSchnittstelle D sichtbar.
Der öffentliche Bereich 11 der Sub-Schnittstelle E ist für die Sub-Schnittstelle C, nicht aber für die Master-Schnittstelle A, sichtbar. Das hat seinen Grund darin, dass die an dem öffentlichen Bereich 11 der Sub-Schnittstelle E anliegenden Größen an dem privaten Bereich 12 der SubSchnittstelle C anliegen und deshalb von der darunter liegenden Schnittstelle A nicht sichtbar sind. Der private Bereich 12, ausgehend von der Master-Schnittstelle A, erstreckt sich über den privaten Bereich 12 der Master-Schnittstelle A und den öffentlichen Bereich 11 der Sub- Schnittstelle B.
Das erfindungsgemäße Initialisierungsverfahren für ein elektronisches System 1 wird anhand des Ablaufdiagramms aus Figur 3 nachfolgend näher erläutert. Das Verfahren beginnt in einem Funktionsblock 30. In einem Funktionsblock 31 wendet sich die Basis-Schnittstelle 2 bzw. die Master-Schnittstelle 2.1 an einen ersten Plug-in 3.1 oder an eine Sub-Schnittstelle 2.2. des elektronischen Systems 1. Der Plug-in 3.1 übermittelt an die Basis-Schnittstelle 2 Informationen bezüglich der Prozesse, die er ausführt. Diese Informationen betreffen beispielsweise das Zeitraster der Prozesse, die Prioritäten der einzelnen Prozesse, etc. Außerdem teilt der Plug-in 3.1 in einem Funktionsblock 32 mit, welche Größen (Variablen, Funktionen, Strukturen etc.) er zur Abarbeitung der Prozesse benötigt. Sub-Schnittstellen 2.2. werden genauso behandelt wie Plug-ins 3.1 bis 3.n. Auch eine SubSchnittstelle 2.2 sendet Informationen an die untergeordnete (d.h. ranghöhere) Basis-Schnittstelle 2 betreffend die Prozesse, die von den Plug-ins ausgeführt werden, die an die Sub-Schnittstelle 2.2 angeschlossen sind. Außerdem teilt die Sub-Schnittstelle 2.2 mit, welche Größen von den an sie angeschlossenen Plug-ins für die Abarbeitung ihrer Prozesse benötigt werden.
In dem Funktionsblock 32 beginnt der Plug-in 3.1 mit der Übermittlung der ersten benötigten Größe an die Basis-Schnittstelle 2. Dazu übermittelt der Plug-in 3.1 die entsprechende Kennung der Größe an die Basis-Schnittstelle 2. Dann wird in einem Funktionsblock 33 reihum bei allen übrigen Plug-ins 3.2 bis 3.n beziehungsweise bei allen an die Basis-Schnittstelle 2 angeschlossenen Sub-Schnittstellen 2.2 angefragt, ob sie die benötigte Größe zur Verfügung stellen können.
Sobald ein Plug-in 3.2 bis 3.n gefunden wurde, der die benötigte Größe zur Verfügung stellen kann, kann die weitere Suche eingestellt werden. Sie kann auch eingestellt werden, wenn eine
Sub-Schnittstelle 2.2 gefunden wurde, welche die benötigte Größe zur Verfügung stellen kann. In diesem Fall würde dann derjenige Plug-in 3.2 bis 3.n bzw. diejenige Sub-Schnittstelle 2.2 die benötigte Größe liefern, von dem bzw. von der die Basis-Schnittstelle 2 als erstes erfährt, dass er bzw. sie die benötigte Größe zur Verfügung stellen kann.
Es ist aber auch denkbar, dass die Suche fortgesetzt wird bis alle weiteren Plug-ins 3.2 bis 3.n und alle Sub-Schnittstellen 2.2 daraufhin abgefragt wurden, ob sie die benötigte Größe zur Verfügung stellen können. Aus all den Plug-ins 3.1 bis 3.n und Sub-Schnittstellen 2.2, welche die benötigte Größe zur Verfügung stellen können, kann derjenige Plug-in bzw. diejenige Sub- Schnittstelle 2.2 ausgewählt werden, der bzw. die den Prozess zur Ermittlung der benötigten
Größe mit der höchsten Priorität aufweist. In diesem Fall würde der Plug-in 3.2 bis 3.n bzw. die Sub-Schnittstelle 2.2 mit dem am höchsten prioren Prozess zur Ermittlung der benötigten Größe ausgewählt werden.
Schließlich ist es auch denkbar, dass einfach der letzte Plug-in 3.2 bis 3.n, der die benötigte
Größe zur Verfügung stellen kann, ausgewählt wird. Alternativ kann auch die letzte SubSchnittstelle 2.2 ausgewählt werden, welche die benötigte Größe zur Verfügung stellen kann. Bei der Suche nach einem Plug-in 3.2 bis 3.n, der die benötigte Größe zur Verfügung stellen kann, bzw. nach einer Sub-Schnittstelle 2.2, welche die benötigte Größe zur Verfügung stellen kann, kann die Basis-Schnittstelle 2 auch zwischen öffentlichen und privaten Größen unterscheiden. Das bedeutet, dass die Basis-Schnittstelle 2 die Plug-ins 3.1 bis 3. n und die SubSchnittstellen 2.2 abfragt, ob diese die benötigte Größe in dem gewünschten (privaten oder öffentlichen) Bereich zur Verfügung stellen können.
Entscheidend ist, dass ein Plug-in 3.2 bis 3.n oder eine Sub-Schnittstelle 2.2 ausgewählt wird, welcher bzw. welche eine bestimmte Größe zur Verfügung stellt, die der Plug-in 3.1 während der Abarbeitung seiner Prozesse benötigt. Während der Abarbeitung seiner Prozesse muss der Plugin 3.1 auf die zur Verfügung gestellte Größe zugreifen können.
Zu diesem Zweck werden in einem Funktionsblock 34 dann dem Plug-in 3.1 Informationen übermittelt, die es ihm erlauben, während der Abarbeitung seiner Prozesse auf die benötigte
Größe an entsprechender Stelle zuzugreifen. So wird beispielsweise vorgeschlagen, dass in dem ersten Plug-in 3.1 ein Zeiger 13 abgelegt wird (vgl. Figur 1), der auf einen Speicherbereich 14 in einem der übrigen Plug-ins 3.2 verweist. In dem Speicherbereich 14 wird die von dem ersten Plug-in 3.1 benötigte Größe von dem anderen Plug-in 3.2 abgelegt und unter Umständen regelmäßig aktualisiert. Für den Zeiger 13 ist in dem Plug-in 3.1 ein Feld 15 vorgesehen, in dem die Zieladresse des Zeigers 13 abgelegt werden kann. Für andere Größen, die von dem Plug-in 3.1 für die Abarbeitung der Prozesse benötigt werden, sind weitere Felder 16 vorgesehen, in denen ebenfalls Zeiger auf Speicherbereiche abgelegt werden können, wo die benötigten Größen während der Abarbeitung der Prozesse abgeholt werden können.
Alternativ ist es aber auch möglich, dass in einem Plug-in, beispielsweise in dem Plug-in 3.3, lediglich ein einziges Feld 17 reserviert ist, obwohl in den Prozessen des Plug-ins 3.3 mehrere Größen benötigt werden. In dem Feld 17 ist die Adresse eines Zeigers 18 abgelegt, der auf eine Struktur 19 verweist. Die Struktur 19 kann in einem beliebigen Plug-in 3.1 bis 3. n oder in der Basis-Software 4 abgelegt sein. In der Struktur 19 sind an vorgegebenen Positionen beziehungsweise in vorgegebenen Feldern bestimmte Größen abgelegt. Die Größen können entweder direkt in den Feldern der Struktur 19 abgelegt sein, oder aber in den Feldern sind weitere Zeiger 20 abgelegt, die auf einen entsprechenden Speicherbereich 21 in einem der Plugins 3.1 bis 3.n oder in der Basis-Schnittstelle 2 verweisen, wo die benötigte Größe dann abgespeichert ist.
In diesem Fall wird aus dem Plug-in 3.3, wenn eine bestimmte Größe benötigt wird, zunächst an den Anfang der Struktur 19 gesprungen. Dort wird dann in Abhängigkeit von der benötigten Größe in das entsprechende Feld der Struktur 19 gesprungen. In dem dargestellten Ausführungsbeispiel wird in das dritte Feld der Struktur 19 gesprungen, wo eine Adresse des Zeigers 20 auf den Speicherbereich 21 in dem Plug-in 3.n abgelegt ist. Von dort wird der aktuelle Wert der benötigten Größe geholt. Danach wird die Abarbeitung des unterbrochenen Prozesses in dem Plug-in 3.3 fortgesetzt.
Durch den Einsatz von Strukturen 19 kann in den Plug-ins Speicherplatz für die Zeiger 13, 18 eingespart werden, da statt der Felder 15, 16 in Plug-in 3.1 lediglich ein Feld in Plug-in 3.3 vorgehalten werden muss.
In einem Abfrageblock 35 wird überprüft, ob dem Plug-in 3.1 für alle von ihm benötigten Größen Informationen übermittelt wurden, die es ihm erlauben, während der Abarbeitung seiner Prozesse auf die Größen zuzugreifen. Falls nicht, wird zu dem Funktionsblock 32 verzweigt, wo der Plug- In 3.1 mit der Übermittlung der nächsten benötigten Größe an die Basis-Schnittstelle 2 fortfährt. Die Schleife umfassend die Funktionsblöcke 32 bis 34 und den Abfrageblock 35 wird so lange durchlaufen, bis dem Plug-in 3.1 für alle von ihm benötigten Größen Informationen übermittelt wurden.
Sobald das der Fall ist, wird zu einem weiteren Abfrageblock 36 verzweigt, wo überprüft wird, ob alle an die Basis-Schnittstelle 2 angeschlossenen Plug-ins 3.1 bis 3. n und alle SubSchnittstellen 2.2 der Basis-Schnittstelle 2 mitgeteilt haben, welche Größen sie zur Abarbeitung ihrer Prozesse benötigen. Falls nicht, wird zu dem Funktionsblock 31 verzweigt, wo der nächste Plug-in 3.2 bzw. die nächste Sub-Schnittstelle 2.2 der Basis-Schnittstelle 2 Informationen betreffend ihrer Prozesse mitteilt. In der nachfolgenden Schleife umfassend die Blöcke 32 bis 35 werden an den nächsten Plug-in 3.2 dann Informationen übermittelt, wo er auf die von ihm benötigten Größen zugreifen kann. Die Schleife umfassend die Funktionsblöcke 31 bis 34 und die Abfrageblöcke 35 und 36 wird so lange durchlaufen, bis alle an die Basis-Schnittstelle 2 angeschlossenen Plug-ins 3.1 bis 3. n und alle Sub-Schnittstellen 2.2 der Basis-Schnittstelle 2 mitgeteilt haben, welche Größen sie zur Abarbeitung ihrer Prozesse benötigen. Sobald das der Fall ist wird das erfindungsgemäße Verfahren in einem Funktionsblock 37 beendet.
Selbstverständlich ist es in Abweichung des in Figur 3 dargestellten Verfahrens auch möglich, zunächst sämtliche Plug-ins 3.1 bis 3. n und sämtliche Sub-Schnittstellen 2.2 bezüglich der von ihnen benötigten Größen abzufragen und die Antworten der Plug-ins 3.1 bis 3. n und SubSchnittstellen 2.2 zunächst in einer Tabelle oder ähnlichem abzulegen. Danach könnten alle Plug- Ins 3.1 bis 3. n und alle Sub-Schnittstellen 2.2 daraufhin abgefragt werden, welche Größen sie im Rahmen der Abarbeitung der in ihnen realisierten Prozesse zur Verfügung stellen können. Auch diese Größen könnten in einer Tabelle oder ähnlichem abgespeichert werden. Anschließend müssten die in den Tabellen abgelegten benötigten und zur Verfügung gestellten Größen in geeigneter Weise in eine Beziehung zueinander gebracht werden und müssten die Plug-ins 3.1 bis 3.n und die Sub-Schnittstellen 2.2 mittels der Zeiger 13, 18 miteinander verbunden werden.
Unabhängig von der konkreten Realisierung des erfindungsgemäßen Verfahrens im Einzelnen ist es entscheidend, dass die an das System 1 angeschlossenen Plug-ins 3.1 bis 3. n Informationen bezüglich der von ihnen ausgeführten Funktionalitäten, das heißt bspw. hinsichtlich der Priorität, des Zeitrasters etc. der in ihnen realisierten Prozesse, ausgeben. Ebenso müssten die Plug-ins 3.1 bis 3.n die Größen angeben, die sie zur Abarbeitung der in ihnen realisierten Prozesse benötigen, und diejenigen Größen benennen, die sie durch die Abarbeitung der in ihnen realisierten Prozesse zur Verfügung stellen können. All diese Informationen fließen in der Basis-Schnittstelle 2 zusammen und werden dort in geeigneter Weise verarbeitet. Als Ergebnis der Verarbeitung in der Basis-Schnittstelle 2 werden an die Plug-ins 3.1 bis 3.n, die bestimmte Größen benötigen, Zeiger
13, 18 auf Speicherbereiche 14, 21 oder Strukturen 19 übergeben, wo sie sich während der Abarbeitung der Prozesse, das heißt während der Laufzeit des Computerprogramms, die benötigten Größen abholen können.
Das erfindungsgemäße Verfahren wird durch ein Kommunikationsprotokoll realisiert, das auf mindestens einem Rechengerät des elektronischen Systems 1 abgearbeitet wird. Ein Rechengerät ist insbesondere ein Mikroprozessor oder ein MikroController. Ein solches Rechengerät zur Abarbeitung des Kommunikationsprotokolls ist bspw. in der Basis-Schnittstelle 2 und in jedem der Plug-ins 3.1 bis 3. n bzw. in den Sub-Schnittstellen 2.2 vorhanden. Beim Hochfahren des Systems 1 wird neben dem Betriebssystem auch das Kommunikationsprotokoll zur Abarbeitung durch die Rechengeräte geladen und vollautomatisch ausgeführt. Selbstverständlich kann das Kommunikationsprotokoll auch nach einem Zurücksetzen des Systems 1 (sog. Reset) ausgeführt werden, ohne dass es eines vollständigen erneuten Hochfahrens des Systems 1 bedarf.
Falls im Rahmen des erfindungsgemäßen Initialisierungsverfahrens eine Anfrage der Master- Schnittstelle 2.1 an eine Sub-Schnittstelle 2.2 nach Informationen bezüglich der ausgeführten Funktionalitäten, beziehungsweise Prozesse, der benötigten Größen und der zur Verfügung gestellten Größen gerichtet wird, leitet die Sub-Schnittstelle 2.2 die Anfrage im Rahmen des Sichtbarkeitskonzepts an die an sie angeschlossenen Plug-ins 3.1 bis 3. n weiter.
Um im Rahmen der Initialisierung aus den verschiedenen Plug-ins 3.1 bis 3. n und aus der Basis- Software 4 ein funktionsfähiges und ablauffähiges Programm zu erzeugen, werden während der Initialisierung außer den oben beschriebenen Schritten auch folgende Schritte ausgeführt:
Die Anfangsadressen der auszuführenden Prozesse aus den Plug-ins 3.1 bis 3. n und der Basis- Software 4 werden in Listen eingetragen. Diese Listen werden von der Master-Schnittstelle 2.1 für bestimmte Task-Perioden des Betriebssystems (zum Beispiel 10 ms) bereitgestellt. Bei der Initialisierung werden die in den Betriebssystem-Tasks aufzurufenden Prozesse in die entsprechenden Listen des Schedulers eingetragen. Für Zwischenzeiten (zum Beispiel 30 ms) werden Teiler errechnet, die diesen Aufruf erst beim n-ten Taskdurchlauf starten (zum Beispiel in einer 10 ms-Task jedes 3. Mal). Die Prozesslisten der Master-Schnittstelle 2.1 werden in die Task- Verwaltung eingetragen beziehungsweise die Einträge werden von dort abgerufen.
Anzumerken ist noch, dass ein Plug-in 3.1 bis 3. n nicht zwangsläufig einen Prozess beinhalten muss.
Während der Laufzeit des Computerprogramms, das heißt nach erfolgter Initialisierung, greifen die Plug-In-Funktionen über die Zeiger 13, 18 auf die von ihnen benötigten Größen zu. Um eine eindeutige Kommunikation zwischen den Plug-ins 3.1 bis 3. n zu gewährleisten, werden alle Größen über eine eindeutige Kennung, eine sogenannte Identifikationsnummer ID, referenziert. Diese Kennungen beinhalten Angaben über den physikalischen Inhalt, die Einheit, den Datentyp, sowie Umrechnungsformeln der entsprechenden Größen. Dies setzt allerdings eine zentrale Stelle voraus, welche alle zur Verfügung stehenden Kennungen koordiniert beziehungsweise verwaltet. Die Koordination beziehungsweise Verwaltung aller zur Verfügung stehender Kennungen erfolgt durch die Basis-Schnittstelle 2 unter Zugriff auf eine Kennungsliste 5.
Das erfindungsgemäße Initialisierungsverfahren hat einige wesentlichen Vorteile:
Zum einen führt es zu einer erheblichen Zeitersparnis zum Zeitpunkt der Integration der verschiedenen Plug-ins. Wenn einer oder mehrere der Plug-ins von einem Zulieferer zugeliefert werden, obliegt dem Zulieferer die Aufgabe, die Plug-ins nach dem oben vorgestellten Sichtbarkeitskonzept zu strukturieren. Zum Zeitpunkt der Integration muss nur noch der Plug-in in das restliche System 1 eingefügt werden. Alles weitere erledigt die Master-Schnittstelle 2.1 während der Initialisierung vollautomatisch. Das heißt der Integrator muss keinerlei Anpassungen an dem Restsystem 1 (wie beispielsweise Einbinden von Prozessen oder ähnliches) mehr vornehmen. Die erfindungsgemäße Systemstruktur kann beispielsweise für ein Steuergerät, insbesondere für ein Kraftfahrzeugsteuergerät (z.B. ein Motorsteuerungsgerät), eingesetzt werden, auf dem Applikationen, beziehungsweise Funktionalitäten, von verschiedenen Zulieferern integriert werden.
Nachträgliche Upgrades, das heißt ein Nachladen von Funktionalitäten auf ein Steuergerät im Feld, ist möglich, ohne dieses komplett neu programmieren (flashen) zu müssen. Das oben dargestellte Systemkonzept ermöglicht das nachträgliche Flashen von Funktionalitäten. Nachträglich bedeutet hierbei, dass ein Kunde nach Art einer "Software-Tankstelle" neue Programmteile herunterladen kann. An einer entsprechenden Ladevorrichtung, bspw. bei einer
Tankstelle oder einer Werkstatt, kann eine gewünschte Funktionalität in einen definierten Bereich des Steuergeräts heruntergeladen (geflasht) werden. Nach der Initialisierung gemäß dem erfindungsgemäßen Verfahren ist diese Funktionalität im Gesamtsystem 1 beziehungsweise in dem Fahrzeug verfügbar, ohne dass der Kunde in irgendeiner Weise noch eingreifen müsste.

Claims

Ansprüche
1. Verfahren zum Initialisieren eines elektronischen Systems (1) umfassend mindestens eine Basis-Schnittstelle (2) und mehrere daran angeschlossene modulartige Plug-ins (3.1, ... 3.n), dadurch gekennzeichnet, dass - beim Initialisieren des elektronischen Systems (1) der Basis-Schnittstelle (2) durch die
Plug-ins (3.1, ... 3. n) jeweils Informationen zur Verfügung gestellt werden betreffend:
+ mindestens eine von dem jeweiligen Plug-in (3.1, ... 3.n) ausgeführte Funktionalität;
+ Größen, die von dem jeweiligen Plug-in (3.1, ... 3.n) zur Ausführung der mindestens einen Funktionalität benötigt werden; + Größen, die von dem jeweiligen Plug-in (3.1, ... 3.n) nach Ausführung der mindestens einen Funktionalität zur Verfügung gestellt werden, den einzelnen Plug-ins (3.1, ... 3. n) durch die Basis-Schnittstelle (2) Informationen zur
Verfügung gestellt werden betreffend:
+ welcher der übrigen Plug-ins (3.1, ... 3. n) eine von dem Plug-in (3.1, ... 3. n) benötigte Größe zur Verfügung stellt, und ein entsprechender Verweis auf denjenigen Plug-in (3.1, ... 3.n), der die Größe zur
Verfügung stellt, in demjenigen Plug-in (3.1, ... 3.n) abgelegt wird, der die Größe benötigt.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die mindestens eine Funktionalität durch mindestens einen Prozess realisiert ist.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Informationen betreffend die Funktionalität ein Zeitraster zum Abarbeiten des mindestens einen Prozesses und eine Priorität des mindestens einen Prozesses umfassen.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass in dem Plug- In (3.1, ... 3.n), der eine Größe benötigt, als Verweis ein Zeiger (13) auf einen Speicherplatz (14) abgelegt wird, an dem die benötigte Größe durch einen der übrigen Plug-ins (3.1, ... 3. n) gespeichert wird.
5. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass in dem Plugin (3.1, ... 3.n), der eine Größe benötigt, als Verweis ein Zeiger (18) auf eine Struktur (19) abgelegt wird, in der an einer vorgegebenen Position die benötigte Größe durch einen der übrigen Plug-ins gespeichert wird.
6. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass, falls eine bestimmte Größe von mehreren Plug-ins (3.1, ... 3. n) zur Verfügung gestellt wird, die Größe von demjenigen Plug-in (3.1, ... 3. n) zur Weiterverarbeitung herangezogen wird, dessen Prozess zur Ermittlung der Größe die höchste Priorität aufweist.
7. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass, falls eine bestimmte Größe von mehreren Plug-ins (3.1, ... 3. n) zur Verfügung gestellt wird, die Größe von demjenigen Plug-in (3.1, ... 3.n) zur Weiterverarbeitung herangezogen wird, von dem die Basis- Schnittstelle (2) als erstes die Information erhält, dass der Plug-in (3.1, ... 3. n) bzw. ein Prozess des Plug-ins (3.1, ... 3. n) die benötigte Größe zur Verfügung stellen kann.
8. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass, falls eine bestimmte Größe von mehreren Plug-ins (3.1, ... 3. n) zur Verfügung gestellt wird, die Größe von demjenigen Plug-in (3.1, ... 3.n) zur Weiterverarbeitung herangezogen wird, von dem die Basis- Schnittstelle (2) als letztes die Information erhält, dass der Plug-in (3.1, ... 3. n) bzw. ein Prozess des Plug-ins (3.1, ... 3. n) die benötigte Größe zur Verfügung stellen kann.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Basis- Schnittstelle (2) Zugriff auf eine Initialisierungstabelle (22) mit Informationen hat, wo die einzelnen Plug-ins (3.1, ... 3. n) abgelegt sind.
10. Verfahren zum Initialisieren eines elektronischen Systems (1) umfassend mindestens eine Basis-Schnittstelle (2) und mehrere daran angeschlossene modulartige Plug-ins (3.1, ... 3.n), insbesondere nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass eine der Basis- Schnittstellen (2) als eine Master-Schnittstelle (2.1) und die übrigen Basis-Schnittstellen (2) als Sub-Schnittstellen (2.2) ausgebildet sind, wobei an die Master-Schnittstelle (2.1) außer den Plugins (3.1, ... 3.n) Sub-Schnittstellen (2.2) angeschlossen sind, an die wiederum weitere SubSchnittstellen (2.2) und/ oder weitere Plug-ins (3.1, ... 3. n) und so weiter angeschlossen sind, wobei die Schnittstellen (2.1, 2.2) in unterschiedliche Bereiche (11, 12) unterteilt sind und lediglich die innerhalb des gleichen Bereichs der Schnittstellen (2.1, 2.2) anliegenden Größen für untergeordnete Schnittstellen (2.1 , 2.2) sichtbar sind.
11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die Schnittstellen (2.1, 2.2) in einen privaten Bereich (12) und einen öffentlichen Bereich (11) unterteilt sind und lediglich die an dem öffentlichen Bereich (11) einer Schnittstelle (2.2) anliegenden öffentlichen Größen für eine untergeordnete Schnittstelle (2.1, 2.2) sichtbar sind.
12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass jeder von den Plug-ins (3.1, ... 3. n) benötigten oder von den Plug-ins (3.1, ... 3. n) zur Verfügung gestellten Größe eine für einen definierten Bereich des elektronischen Systems (1) eindeutige Kennung (Id i) zugeordnet wird.
13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die Kennungen (ID i) der Größen in einer Kennungsliste (5) abgelegt sind, aufweiche die Basis-Schnittstelle (2) während der Initialisierung des elektronischen Systems (1) zugreifen kann.
14. Kommunikationsprotokoll zur Abarbeitung auf mindestens einem Rechengerät eines elektronischen Systems (1), das mindestens eine Basis-Schnittstelle (2) und mehrere daran angeschlossene modulartige Plug-ins (3.1, ... 3. n) umfasst, während der Initialisierung des elektronischen Systems (1), dadurch gekennzeichnet, dass das Kommunikationsprotokoll derart programmiert ist, dass beim Initialisieren des elektronischen Systems (1) der Basis-Schnittstelle (2) durch die Plug-ins (3.1, ... 3. n) jeweils Informationen zur Verfügung gestellt werden betreffend: + mindestens eine von dem jeweiligen Plug-in (3.1, ... 3.n) ausgeführte Funktionalität; + Größen, die von dem jeweiligen Plug-in (3.1, ... 3.n) zur Ausführung der mindestens einen Funktionalität benötigt werden;
+ Größen, die von dem jeweiligen Plug-in (3.1, ... 3.n) nach Ausführung der mindestens einen Funktionalität zur Verfügung gestellt werden, - den einzelnen Plug-ins (3.1, ... 3. n) durch die Basis-Schnittstelle (2) Informationen zur
Verfügung gestellt werden betreffend:
+ welcher der übrigen Plug-ins (3.1, ... 3. n) eine von dem Plug-in (3.1, ... 3. n) benötigte
Größe zur Verfügung stellt, und ein entsprechender Verweis auf denjenigen Plug-in (3.1, ... 3.n), der die Größe zur Verfügung stellt, in demjenigen Plug-in (3.1, ... 3.n) abgelegt wird, der die Größe benötigt.
15. Computerprogramm zur Abarbeitung auf einem Rechengerät einer Datenverarbeitungsanlage, wobei das Computerprogramm mindestens eine Basis-Schnittstelle (2) und mehrere daran angeschlossene Plug-ins (3.1, ... 3. n) umfasst, dadurch gekennzeichnet, dass beim Initialisieren des Computerprogramms die Plug-ins (3.1, ... 3. n) der Basis- Schnittstelle (2) jeweils Informationen zur Verfügung stellen betreffend:
+ mindestens eine von dem jeweiligen Plug-in (3.1, ... 3.n) ausgeführte Funktionalität,
+ Größen, die von dem jeweiligen Plug-in (3.1, ... 3.n) zur Ausführung der mindestens einen Funktionalität benötigt werden, und
+ Größen, die von dem jeweiligen Plug-in (3.1, ... 3.n) nach Ausführung der mindestens einen Funktionalität zur Verfügung gestellt werden; die Basis-Schnittstelle (2) den einzelnen Plug-ins (3.1, ... 3. n) Informationen zur
Verfügung stellt betreffend:
+ welcher der übrigen Plug-ins (3.1, ... 3. n) eine von dem Plug-in (3.1, ... 3. n) benötigte
Größe zur Verfügung stellt; und - ein entsprechender Verweis auf denjenigen Plug-in (3.1, ... 3.n), der die Größe zur
Verfügung stellt, in demjenigen Plug-in (3.1, ... 3.n) abgelegt wird, der die Größe benötigt.
16. Elektronisches System (1) mit einem Rechengerät zur Abarbeitung eines Kommunikationsprotokolls, wobei das elektronische System (1) mindestens eine Basis- Schnittstelle (2) und mehrere daran angeschlossene modulartige Plug-ins (3.1, ... 3. n) umfasst, dadurch gekennzeichnet, dass die Plug-ins (3.1, ... 3. n) im Rahmen der Initialisierung des elektronischen Systems (1) der Basis-Schnittstelle (2) jeweils Informationen zur Verfügung stellen betreffend: + mindestens eine von dem jeweiligen Plug-in (3.1, ... 3.n) ausgeführte Funktionalität;
+ Größen, die von dem jeweiligen Plug-in (3.1, ... 3.n) zur Ausführung der mindestens einen Funktionalität benötigt werden; + Größen, die von dem jeweiligen Plug-in (3.1, ... 3.n) nach Ausführung der mindestens einen Funktionalität zur Verfügung gestellt werden, den einzelnen Plug-ins (3.1, ... 3. n) durch die Basis-Schnittstelle (2) Informationen zur Verfügung gestellt werden betreffend:
+ welcher der übrigen Plug-ins (3.1, ... 3. n) eine von dem Plug-in (3.1, ... 3. n) benötigte Größe zur Verfügung stellt, und ein entsprechender Verweis auf denjenigen Plug-in (3.1, ... 3.n), der die Größe zur Verfügung stellt, in demjenigen Plug-in (3.1, ... 3.n) abgelegt wird, der die Größe benötigt.
PCT/EP2005/056224 2004-12-15 2005-11-25 Verfahren zum initialisieren eines elektronischen systems umfassend mehrere plug-ins WO2006063924A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP05811127A EP1828886A1 (de) 2004-12-15 2005-11-25 Verfahren zum initialisieren eines elektronischen systems umfassend mehrere plug-ins
CN2005800429552A CN101080692B (zh) 2004-12-15 2005-11-25 用于初始化包含多个插件的电子系统的方法
US11/792,737 US20080155405A1 (en) 2004-12-15 2005-11-25 Method for Initializing an Electronic System Comprising Several Plug-Ins
JP2007546011A JP2008523519A (ja) 2004-12-15 2005-11-25 複数のプラグインを含む電子システムを初期化する方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004060301A DE102004060301A1 (de) 2004-12-15 2004-12-15 Verfahren zum Initialisieren eines elektronischen Systems umfassend mehrere Plug-Ins
DE102004060301.4 2004-12-15

Publications (1)

Publication Number Publication Date
WO2006063924A1 true WO2006063924A1 (de) 2006-06-22

Family

ID=36123565

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/056224 WO2006063924A1 (de) 2004-12-15 2005-11-25 Verfahren zum initialisieren eines elektronischen systems umfassend mehrere plug-ins

Country Status (6)

Country Link
US (1) US20080155405A1 (de)
EP (1) EP1828886A1 (de)
JP (1) JP2008523519A (de)
CN (1) CN101080692B (de)
DE (1) DE102004060301A1 (de)
WO (1) WO2006063924A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009129083A (ja) * 2007-11-21 2009-06-11 Denso Corp 車両制御装置およびそれを用いた車両制御システム

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008062255A1 (en) * 2006-11-21 2008-05-29 Renault Trucks Truck and bodybuilder module for this truck, method, memory and software to configure the bodybuilder module
DE102007039428A1 (de) 2007-08-21 2009-02-26 Beckhoff Automation Gmbh Programmiervorrichtung für ein Netzwerk aus Steuerknoten und Anlage mit einer solchen Programmiervorrichtung
JP4924373B2 (ja) * 2007-11-14 2012-04-25 住友電装株式会社 通信ユニット及び通信システム
US8155829B2 (en) * 2007-11-21 2012-04-10 Denso Corporation Common control apparatus and vehicle control system
CN101604371B (zh) 2009-07-22 2012-02-08 阿里巴巴集团控股有限公司 插件权限的控制方法及系统
JP5891794B2 (ja) * 2011-02-09 2016-03-23 株式会社リコー 情報処理装置及びプログラム
DE102011012187A1 (de) * 2011-02-23 2012-08-23 Continental Automotive Gmbh Verfahren zum Konfigurieren einer Steuervorrichtung für ein Kraftfahrzeug, Computerprogramm und Steuervorrichtung
JP6375310B2 (ja) 2014-01-09 2018-08-15 川崎重工業株式会社 車両およびその運転支援方法
DE102016009857A1 (de) * 2016-08-12 2018-02-15 WAGO Verwaltungsgesellschaft mit beschränkter Haftung Automatische Initialisierungsroutine in einem Automatisierungs-System
CN115904544A (zh) * 2022-12-27 2023-04-04 哈尔滨工大卫星技术有限公司 一种插件化的数字化卫星系统及其管理方法和介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10000997A1 (de) * 1999-01-28 2001-01-04 Ibm Elektronisches Steuersystem
US20020147903A1 (en) * 2001-04-10 2002-10-10 Discreet Logic Inc. Initialising modules
US20030078699A1 (en) * 2000-09-07 2003-04-24 Klaus Harms Electronic system for a vehicle and system layer for operational functions

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5519866A (en) * 1993-06-28 1996-05-21 Taligent, Inc. Method and apparatus of incrementally linking components of a modeled computer program
EP1176496A1 (de) * 2000-07-24 2002-01-30 Hewlett-Packard Company, A Delaware Corporation Spannungsregelung in einer integrierbaren Schaltungsanordnung
US6842856B2 (en) * 2001-05-11 2005-01-11 Wind River Systems, Inc. System and method for dynamic management of a startup sequence
US7284246B2 (en) * 2002-04-23 2007-10-16 Canon Kabushiki Kaisha Extensible device driver
JP2003330756A (ja) * 2002-05-14 2003-11-21 Mitsubishi Electric Corp 監視制御ソフトウェアの構成管理方法
US7584471B2 (en) * 2002-09-23 2009-09-01 Telefonaktiebolaget L M Ericsson (Publ) Plug-in model
US7509638B2 (en) * 2004-08-02 2009-03-24 International Business Machines Corporation Method and apparatus for providing a pluggable and extendable J2EE architecture

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10000997A1 (de) * 1999-01-28 2001-01-04 Ibm Elektronisches Steuersystem
US20030078699A1 (en) * 2000-09-07 2003-04-24 Klaus Harms Electronic system for a vehicle and system layer for operational functions
US20020147903A1 (en) * 2001-04-10 2002-10-10 Discreet Logic Inc. Initialising modules

Non-Patent Citations (1)

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

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009129083A (ja) * 2007-11-21 2009-06-11 Denso Corp 車両制御装置およびそれを用いた車両制御システム

Also Published As

Publication number Publication date
JP2008523519A (ja) 2008-07-03
EP1828886A1 (de) 2007-09-05
CN101080692B (zh) 2010-10-06
DE102004060301A1 (de) 2006-06-22
CN101080692A (zh) 2007-11-28
US20080155405A1 (en) 2008-06-26

Similar Documents

Publication Publication Date Title
EP1828886A1 (de) Verfahren zum initialisieren eines elektronischen systems umfassend mehrere plug-ins
EP0577919A1 (de) Zugriffssteuerung für gekoppelte maskenprogrammierte Mikrocontroller
EP3230856B1 (de) Verfahren zum update von firmware von geräten
DE102005010476A1 (de) Steuergerät mit konfigurierbaren Hardwaremodulen
EP2881858B1 (de) Verfahren zur Änderung der Software im Speicher eines elektronischen Steuergerätes
EP3538960A1 (de) Ablaufsteuerung von programmmodulen
EP1700211B1 (de) Laden von software-modulen
DE102011007714B4 (de) Verfahren für die Verwendung mit einem Batterieüberwachungssystem, Batterieüberwachungssystem und Verwendung des Verfahrens
WO2005078540A1 (de) Verfahren zum konfigurieren einer automatisierungskomponente eines automatisierungssystems und entsprechendes automatisierungssystem
WO2019162122A1 (de) System zum übertragen zumindest eines aktualisierungspakets für zumindest ein steuergerät eines kraftfahrzeugs sowie verfahren
EP3015995A1 (de) Verfahren zum konfigurieren einer schnittstelleneinheit eines computersystems
DE102017130552B3 (de) Verfahren zur Datenverarbeitung und speicherprogrammierbare Steuerung
DE102019117954A1 (de) Laufzeitserver zum gleichzeitigen Ausführen mehrerer Laufzeitsysteme einer Automatisierungsanlage
EP4289123A1 (de) Verfahren und vorrichtung zur konfiguration einer applikation
EP0499213A2 (de) Modular strukturiertes ISDN-Kommunikationssystem
EP3285162A1 (de) Verfahren zum projektieren eines projektes sowie anordnung zur durchführung des verfahrens
WO2012072180A2 (de) Verfahren zum betreiben einer arbeitsmaschine und arbeitsmaschine
DE102012218665B4 (de) Applikationssystem für Steuergeräte
DE60307172T2 (de) Ein Verfahren und Netzwerkvorrichtung bestehend aus einem flexiblem EEPROM um Konfigurationseinstellungen einzustellen
DE10064339B4 (de) Integrierte Schaltungsanordnung in einem Bremskraftregelsystem
EP3482467A1 (de) Steckverbinderbauteil, steckverbinder, steckverbindersystem und verfahren zum zusammensetzen und betreiben eines steckverbinders
DE102016121542A1 (de) Ablaufsteuerung von Programmmodulen
DE102017100118A1 (de) Skalierbares Steuersystem für ein Kraftfahrzeug
DE102022132909A1 (de) Orchestrierungssystem zum Aktualisieren von Containern mit darin enthaltenen Applikationen sowie hierauf basiertes Orchestrierungsverfahren
WO2016092006A1 (de) Firmware-management-system sowie firmware-management-verfahren zum update von firmware von geräten

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2005811127

Country of ref document: EP

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 11792737

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2007546011

Country of ref document: JP

Ref document number: 200580042955.2

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 3114/CHENP/2007

Country of ref document: IN

WWP Wipo information: published in national office

Ref document number: 2005811127

Country of ref document: EP