[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2005001582A1 - Elektronische steuereinheit und verfahren zur spezifikation einer software-architektur für eine elektronische steuereinheit - Google Patents

Elektronische steuereinheit und verfahren zur spezifikation einer software-architektur für eine elektronische steuereinheit Download PDF

Info

Publication number
WO2005001582A1
WO2005001582A1 PCT/DE2004/001333 DE2004001333W WO2005001582A1 WO 2005001582 A1 WO2005001582 A1 WO 2005001582A1 DE 2004001333 W DE2004001333 W DE 2004001333W WO 2005001582 A1 WO2005001582 A1 WO 2005001582A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
control unit
electronic control
interfaces
components
Prior art date
Application number
PCT/DE2004/001333
Other languages
English (en)
French (fr)
Inventor
Thomas Zurawka
Joerg Schaeuffele
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 JP2006515279A priority Critical patent/JP2007507017A/ja
Priority to EP04738782A priority patent/EP1639416A1/de
Priority to US10/561,737 priority patent/US20070271551A1/en
Priority to DE112004001620T priority patent/DE112004001620D2/de
Publication of WO2005001582A1 publication Critical patent/WO2005001582A1/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/23—Pc programming
    • G05B2219/23188—Software independent and dependent of hardware
    • 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/25184—Number of modules interfaces optimized in relation to applications with which to link
    • 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/26—Pc applications
    • G05B2219/2637—Vehicle, car, auto, wheelchair

Definitions

  • the invention relates to an electronic control unit and a method for specifying a software architecture for an electronic control unit according to the independent claims.
  • the invention further relates to a computer program with program code means for executing a method for specifying a software architecture.
  • control units for the use of control units in the vehicle network, it is known to use control units other than those used in production or service, such as series control units, during development, which are then also referred to as development, prototype, sample or application control units.
  • series control units for the use of control units in the vehicle network
  • control units generally differ from series control units, inter alia, by a so-called off-board interface modified for the respective development application, which is usually linked to hardware and software adaptations. Communication between a tool and a microcontroller of the control unit then takes place via various interfaces. For example, procedures are standardized in ASAM for the functions measuring, calibration, diagnosis and flash programming.
  • an electronic control unit with a component implemented thereon is implemented
  • Software which has a plurality of software interfaces optimized for exchanging information for the optional coupling of a plurality of applications, the software for each connectable application comprising at least one application-specific software code of a component which is activated when the application is coupled.
  • Strikes for example, a so-called CAN (Controller Area Network) message, i.e. one
  • CAN Controller Area Network
  • a message received via a CAN bus is input to a microprocessor, this first gives the microprocessor a signal that a message has arrived, which is also referred to as an interrupt. This is then control information.
  • the content of the CAN message such as the value of a transmitted signal, can be data information.
  • the electronic control unit is generally integrated into a higher-level network, such as a vehicle network.
  • the limits of the software of the electronic control unit are now determined or established on the basis of this combination. It defines exactly what belongs to the software of the electronic control unit and what belongs to the environment or context of the software. This then determines which input and output interfaces the electronic control unit has.
  • those software interfaces to composite internal applications are referred to as “on-board” interfaces in the context of the present invention, and those to external applications are referred to as “off-board” interfaces in the context of the present invention, 'exactly determined.
  • the "on-board” interfaces are, for example, interfaces to setpoint devices, sensors and actuators, and interfaces for one
  • the control unit has, as “off-board” interfaces, all software interfaces that are necessary for off-board communication. If the electronic control unit is integrated into a vehicle network, for example, then it has all the software interfaces that are used in the Course of development in which Production or in the service of the vehicle for communication with vehicle external electronic units are necessary.
  • the external units can, for example, be tools that perform certain functions, such as measuring, calibrating,
  • Each tool requires a description of the "off-board" interface to which it can be connected.
  • This description is stored, for example, in the form of a file, a so-called description file.
  • this contains hardware and software information of the "off-board" Interface described, on the other hand, information for the access of the tool to the data of the electronic control unit, such as the memory addresses of signals, variables and parameters, is stored.
  • the software of the electronic control unit has a hierarchical layer architecture with regard to the mutual accessibility of the software components, with each software component being assigned to a layer.
  • the layers are characterized by the fact that software components can access each other within a layer, but strict rules apply between different layers.
  • the layers are arranged according to their assigned levels of abstraction. Layers with a lower level of abstraction can be accessed from layers with a lower level of abstraction. However, access from lower layers to higher layers is severely restricted or inadmissible.
  • the software components are therefore strictly divided into task-related, i.e. functional layers.
  • the layer architecture preferably realizes a separation of hardware-independent software components from hardware-dependent software components.
  • Information-optimized software interfaces are standardized for access to the control unit. This makes it possible to use standardized methods or tools tailored to these standard interfaces during development, production and service, such as for rapid prototyping, debugging, measuring and calibrating.
  • the software components of the application software can be specified independently of the hardware and are therefore portable on different control unit platforms.
  • the software assumes one of several possible operating states, depending on information available at the software interfaces, and then only supports state-specific functionalities.
  • a parameterization of software components and a software update take place in production and in service For example, mostly in a specific operating state of the software, in which control / regulation and monitoring functions may only be carried out partially or not at all for security reasons.
  • the software can use an “software update”, “software parameterization”, “software diagnosis”, “follow-up”, “monitoring”, “on” or “operating mode” Which state the control unit takes depends on the information available at its software interfaces.
  • the operating state "on" can be assumed, for example, when the ignition of the vehicle is switched on become. In this operating state, all display functions of the electronic control unit are then available, for example.
  • the software is in the "software update” operating state, only flash programming via an "off-board” diagnostic interface is supported in production and service, for example.
  • the operating state "software parameterization” is intended for setting software parameters via the "off-board" diagnostic interface mentioned in production or in service. In the case of a group of vehicles, this can be, for example, a switchover of distance and speed displays between kilometers and miles or a switchover between different language variants.
  • the software diagnostics operating state of the software, the software only supports
  • Diagnostic functions such as functions for sensor and actuator diagnosis, as well as reading and deleting the error memory.
  • These functionalities are advantageously only available in this operating state Available or supported by the software only in this operating state of the software.
  • the software can assume the “monitoring” operating state, for example after turning the ignition key to a specific position in a vehicle, which then supports monitoring functions on the part of the software.
  • the software can assume an “after-running” operating state, such as after a shutdown the engine of a vehicle in which the electronic control unit is integrated. Storage functionalities and more time-consuming monitoring functionalities are then supported, for example.
  • an operating state “emergency operation” is conceivable, which the software assumes, for example, in the event of a failure of safety-relevant components, and in which the software supports functionalities that enable continued operation with limited functionality.
  • the present invention comprises the use of an electronic control unit according to the invention in automotive electronics, preferably for controlling operating processes in a vehicle.
  • the present invention provides a method for specifying a software architecture for an electronic control unit.
  • defined software interfaces specified This means that the "on-board” and “off-board” interfaces of the software described above are defined here.
  • software components and their interfaces are specified. Communication between the software components is also determined.
  • software layers and possible software operating states are determined.
  • the software components are automatically assigned to the software layers and to the software operating states, with the assignments being verified by subsequent analysis and checking of the interactions realized on the basis of the assignments.
  • the software components are subdivided into defined subcomponents and / or the software layers are subdivided into sub-layers and / or the software operating states are subdivided into sub-states, after which a new assignment is carried out automatically.
  • the invention when specifying a software architecture for an electronic control unit, it is taken into account that there are numerous interactions between the specification of software components, software layers and operating states of the software. By taking these factors into account in the development of the software architecture, the software can be used universally for all applications and, when using the electronic control unit, does not require any adjustments to be made until then. Furthermore, the invention provides a computer program and a computer program product with program code means, the method according to the invention being carried out automatically when the program code means are executed on a computer or on a computer system.
  • Figure 1 shows a schematic representation of a
  • Embodiment of an electronic control unit according to the invention Embodiment of an electronic control unit according to the invention.
  • FIG. 2 shows a schematic representation of a software architecture of a further embodiment of an electronic control unit according to the invention.
  • FIG. 1 shows an electronic control unit 100.
  • the electronic control unit 100 is integrated in a higher-level network, such as a vehicle, in particular with a number of control units, sensors and actuators.
  • a higher-level network such as a vehicle
  • control units sensors and actuators.
  • interfaces of the internal components of the control unit 100 that is to say interfaces within the control unit 100
  • applications within the superordinate network which represent the “on-board” interfaces.
  • the control unit 100 shows as “on-board” Interfaces a CAN interface 101 and a MOST (Media Oriented Systems Transport) interface 102, via which information can be exchanged mutually.
  • MOST Media Oriented Systems Transport
  • sensors and actuators of the higher-level network can be coupled to the interface.
  • the associated drivers for the CAN interface or the MOST interface are 101A or 102A.
  • an analog (103) and a digital (104) input and output (analog I / O, digital I / O) with the respective drivers 103A and 104A are shown.
  • interfaces 105, 106 and 107 are shown, to which, for example, various display applications 108 can be coupled, which are provided by corresponding drivers
  • the display applications can be, for example, a pointer control 108A, a display control 108B or an LED control 108C.
  • the drivers 109A are designed as pointer drivers, 109B as display drivers and 109C as LED drivers.
  • element 120 further functions of the control unit, e.g. Calculation functions or processing functions with the corresponding objects on which these are to be executed are shown.
  • FIG. 2 shows a software architecture of an electronic control unit 100.
  • the software components are assigned to layers.
  • a platform layer 110 and an application layer 111 Here is a layer in the platform
  • the platform software 110 includes the operating system, for example OSEK-OS, and the so-called hardware abstraction layer (HAL) Definition of general standardized interfaces for connecting to these hardware-dependent software components for various, selectable, hardware-independent software components.
  • the HAL contains the pointer drivers 123, display drivers 124, LED drivers 125 and I / O drivers 126 already mentioned, for example.
  • the hardware-independent software components in layer 111 can contain, for example, the software functions 115 for controlling the operating sequences in a vehicle.
  • the software-internal interfaces SISS between platform software 110 and application software 111 are shown schematically and are not to be seen as restrictive with regard to their exact position and connection. That is, for example, the connections SISS1 and SISS2 between HAL and objects 114 are shown as examples and schematically. This also applies to the other software interfaces SISS3 to SISS ⁇ , whereby any other connection and position is also possible.
  • Control or control interfaces can be distinguished. This distinction applies both to the input and output interfaces of a software system, which are referred to here as SESS, i.e. interfaces external to the software, as well as to the interfaces SISS, the internal ones
  • the software interfaces can be grouped into “on-board” and “off-board” interfaces depending on the applications that can be coupled to them, and can be further refined.
  • the electronic control unit is generally integrated into a higher-level network, such as a vehicle network.
  • the limits of the software of the electronic control unit are now determined or established on the basis of this combination. It defines exactly what belongs to the software of the electronic control unit and what belongs to the environment or context of the software. This then determines which input and output interfaces the electronic control unit has.
  • those software interfaces to composite internal applications referred to in the context of the present invention as “on-board” interfaces, and, on the other hand, those to composite external applications, as stated above, as “off-board” within the scope of the present invention. Interfaces designated, precisely defined.
  • the "on-board” interfaces are, for example, interfaces to setpoint transmitters, sensors and actuators as well as interfaces for internal communication, a so-called on-board communication with other electronic systems in the network, such as a vehicle.
  • the interfaces SESS on-board interfaces such as SESS1 and SESS2 on in-vehicle hardware through the HAL or off-board interfaces such as via the CAN driver 113 can be the interface SESS4 to an external diagnostic device.
  • the SESS4 interface can also be on-board interface within the vehicle, for example on actuators, sensors or other control units via CAN-BUS. The same applies to the MOST interface 122 and SESS3.
  • an ISO diagnostic protocol and designated 128 an ISO network layer.
  • 129 represents an interaction layer OSEK-COM in the platform software 110 and 130 a network management OSEK-NM.
  • the hierarchical layer architecture mentioned is shown here by way of example with two layers 110 and 111, each software component being assigned to a layer.
  • the layers are characterized by the fact that software components can access each other within a layer, but strict rules apply between the different layers via the SISS interfaces.
  • the layers are arranged according to their assigned levels of abstraction. Layers with a lower level of abstraction can be accessed from layers with a lower level of abstraction. However, access from lower layers to higher layers is severely restricted or inadmissible. Further
  • Layers could be, for example, a sensor layer or an actuator layer, but these are not explicitly shown here for reasons of clarity.
  • the software components are therefore strictly divided into task-related, i.e. functional layers.
  • the layer architecture preferably realizes a separation of hardware-independent software components and hardware-dependent software components. This means that the actual control unit functionality, that is to say the hardware-independent software components, such as application software, is separated from the hardware-dependent software components of the platform software with the advantages which have already been explained, the software interfaces optimized according to the invention in this regard in terms of exchanging information are standardized for access to the control unit.
  • the software can assume one of several possible operating states and then only supports state-specific functionalities.
  • the operating state is e.g. conceivable to assume a "software update”, “software parameterization”, “software diagnostics”, “run-on”, “monitoring”, “on” or “emergency operation” state. Which state the control unit is in , depends on the information available at your software interfaces.
  • sub-layers or sub-components may exist in the layers in order to subdivide the software components into defined sub-components and / or the software layers into defined sub-layers and / or the software operating states into defined sub-states, whereupon a new assignment is carried out automatically can be.
  • the software can be used universally for all applications and, when using the electronic control unit, does not require any adjustments to be carried out until then.

Landscapes

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

Abstract

Die vorliegende Erfindung betrifft eine elektronische Steuereinheit (100) mit einer darauf implementierten aus Komponenten bestehenden Software und eine Mehrzahl von hinsichtlich Austauschen von Informationen optimierten Software-Schnittstellen (101, 102, 103, 104, 105, 106) zur wahlweisen Ankopplung von einer Mehrzahl von Anwendungen, wobei die Software für jede ankoppelbare Anwendung mindestens einen anwendungspezifischen Softwarecode einer Komponente umfasst, welcher bei Ankopplung der Anwendung aktiviert wird. Ferner betrifft die Erfindung ein entsprechendes Verfahren zur Spezifikation einer Software Architektur einer elektronischen Steuereinheit (100).

Description

Elektronische Steuereinheit und Verfahren zur Spezifikation einer Software-Architektur für eine elektronische Steuereinheit
Die Erfindung betrifft eine elektronische Steuereinheit und ein Verfahren zur Spezifikation einer Software-Architektur für eine elektronische Steuereinheit gemäß den unabhängigen Ansprüchen. Weiterhin betrifft die Erfindung ein Computerprogramm mit Programmcodemitteln zur Ausführung eines Verfahrens zur Spezifikation einer Software- Architektur gemäß Anspruch 10.
Stand der Technik
Die zunehmende Komplexität der Funktionen einer elektronischen Steuereinheit sowie die zunehmende Vernetzung und Interaktion von Steuereinheiten untereinander, wie beispielsweise in einem Fahrzeugverbund, und mit externen Anwendungen erhöhen die Software- Anforderungen derartiger Steuereinheiten enorm. Dies gilt nicht nur für Steuereinheiten im Fahrzeugverbund sondern auch für eine Vernetzung und Interaktion von Steuereinheiten und Modulen in anderen technischen Gebieten, wie beispielsweise der Automatisierung.
Ausgehend von den Software-Anforderungen beginnt eine Software-Entwicklung mit deren Analyse und einer
Spezifikation einer entsprechenden Software-Architektur. Dabei müssen zunächst die Grenzen der auf einer entsprechenden elektronischen Steuereinheit zu implementierenden Software bestimmt bzw. spezifiziert werden.
Für den Einsatz von Steuereinheiten im Fahrzeugverbund ist es bekannt, während der Entwicklung andere als in der Produktion oder im Service verwendete Steuereinheiten, wie beispielsweise Seriensteuergeräte, zu verwenden, welche dann auch als Entwicklungs-, Prototyp-, Muster- oder Applikationssteuergeräte bezeichnet werden. Diese Steuergeräte unterscheiden sich von Seriensteuergeräten in der Regel unter anderem durch eine für die jeweilige Entwicklungsänwendung modifizierte sogenannte Off-Board- Schnittstelle, was meist mit Hard- und Software-Anpassungen verknüpft ist. Eine Kommunikation zwischen einem Werkzeug und einem MikroController des Steuergerätes erfolgt dann über verschiedenartige Schnittstellen. So werden beispielsweise für die Funktionen Messen, Kalibrieren, Diagnose und Flash- Programmierung Verfahren in ASAM standardisiert.
Vorteile der Erfindung
Es werden eine erfindungsgemäße elektronische Steuereinheit nach Anspruch 1 sowie ein erfindungsgemäßes Verfahren nach Anspruch 8 und ein entsprechendes Computerprogramm nach Anspruch 10 vorgeschlagen. Weitere bevorzugte Ausführungsformen sind in den entsprechenden Unteransprüchen aufgeführt.
Gemäß Anspruch 1 wird eine elektronische Steuereinheit mit einer darauf implementierten aus Komponenten bestehenden
Software bereitgestellt, die eine Mehrzahl von hinsichtlich Austauschen von Informationen optimierten Software- Schnittstellen zur wahlweisen Ankopplung von einer Mehrzahl von Anwendungen aufweist, wobei die Software für jede ankoppelbare Anwendung mindestens einen anwendungspezifischen Softwarecode einer Komponente umfaßt, welcher bei Ankopplung der Anwendung aktiviert wird.
Im allgemeinen werden zwei Arten von Informationen unterschieden, die den Ablauf bzw. die Aktivierung eines Softwarecodes einer Software-Komponente beeinflussen und über Software-Schnittstellen übertragen werden. Dabei handelt es sich einerseits um Dateninformationen und andererseits um Kontroll- bzw. Steuerinformationen. Bei den Software-Schnittstellen wird entsprechend zwischen
Datenschnittstellen und Kontroll- bzw. Steuerschnittstellen unterschieden. Die Verarbeitung einer Information in einem Software-System wird als Datenfluß bzw. Kontrollfluß bezeichnet. Trifft beispielsweise eine sogenannte CAN- (Controller Area Network) -Nachricht, das heißt eine
Nachricht, die über einen CAN-Bus empfangen wird, bei einem Mikroprozessor ein, so gibt dies zunächst dem Mikroprozessor ein Signal, daß eine Nachricht eingetroffen ist, was auch als Interrupt bezeichnet wird. Dabei handelt es sich dann um eine Kontrollinformation. Der Inhalt der CAN-Nachricht, wie beispielsweise der Wert eines übertragenen Signals, kann demgegenüber eine Dateninformation sein. Diese Unterscheidung gilt sowohl für Ein- und Ausgabeschnittstellen eines Software-Systems als auch für die Schnittstellen der internen Komponenten eines Software-Systems .
In einer weiteren bevorzugten Ausführungsform der erfindungsgemäßen elektronischen Steuereinheit sind die
Software-Schnittstellen in Abhängigkeit der an sie jeweils ankoppelbaren Anwendungen in „on-board"- und „off-board"- Schnittstellen gruppiert. Die elektronische Steuereinheit ist im allgemeinen in einen übergeordneten Verbund eingebunden, wie beispielsweise in einen Fahrzeugverbund. Anhand dieses Verbundes sind nun die Grenzen der Software der elektronischen Steuereinheit bestimmt bzw. festgelegt. Es ist genau definiert, was zu der Software der elektronischen Steuereinheit gehört und was zur Umgebung oder zum Kontext der Software gehört. Darüber ist dann bestimmt, welche Ein- und Ausgangsschnittstellen die elektronische Steuereinheit aufweist. Ferner sind dann diejenigen Software-Schnittstellen zu Verbund internen Anwendungen, im Rahmen der vorliegenden Erfindung als „On- Board"-Schnittstellen bezeichnet, und demgegenüber diejenigen zu Verbund externen Anwendungen, im Rahmen der vorliegenden Erfindung als „Off-Board"-Schnittstellen bezeichnet,' genau bestimmt. Die „On-Board"-Schnittstellen sind beispielsweise Schnittstellen zu Sollwertgebern, Sensoren und Aktuatoren sowie Schnittstellen für eine
Verbund interne Kommunikation, eine sogenannte On-Board- Kommunikation mit anderen elektronischen Systemen des Verbundes, wie beispielsweise eines Fahrzeuges. Die erfindungsgemäße Steuereinheit weist als „Off-Board"- Schnittstellen alle Software-Schnittstellen auf, die für eine Off-Board-Kommunikation notwendig sind. Ist die elektronische Steuereinheit beispielsweise in einen Fahrzeugverbund eingebunden, so weist sie alle Software- Schnittstellen auf, die im Verlauf der Entwicklung, in der Produktion oder im Service des Fahrzeuges für eine Kommunikation mit Fahrzeug externen elektronischen Einheiten notwendig sind. Bei den externen Einheiten kann es sich dabei beispielsweise um Werkzeuge handeln, die bestimmte Funktionen, wie Messen, Kalibrieren,
Diagnostizieren oder Programmieren ausführen. Jedes Werkzeug benötigt eine Beschreibung der „Off-Board"- Schnittstelle, an welche es ankoppelbar ist. Diese Beschreibung ist beispielsweise in Form einer Datei, einer sogenannten Beschreibungsdatei, abgelegt. Darin sind einerseits Hardware- und Software-Informationen der „Off- Board"-Schnittstelle beschrieben, andererseits sind Informationen für den Zugriff des Werkzeuges auf die Daten der elektronischen Steuereinheit, wie beispielsweise die Speicheradressen von Signalen, Variablen und Parametern, hinterlegt .
In einer besonders bevorzugten Ausführungsform der elektronischen Steuereinheit weist dabei die Software der elektronischen Steuereinheit eine hinsichtlich einer gegenseitigen Zugriffsmöglichkeit der Software-Komponenten hierarchische Schichtenarchitektur auf, wobei eine jede Software-Komponente einer Schicht zugeordnet ist. Die Schichten zeichnen sich dadurch aus, daß Software- Komponenten innerhalb einer Schicht beliebig aufeinander zugreifen können, zwischen verschiedenen Schichten jedoch strenge Regeln gelten. Die Schichten sind entsprechend nach ihnen zugeordneten Abstraktionsniveaus angeordnet. Von Schichten mit höherem Abstraktionsniveau kann auf Schichten mit niedrigerem Abstraktionsniveau zugegriffen werden. Der Zugriff von niedrigeren Schichten auf höhere Schichten ist dagegen stark eingeschränkt oder unzulässig. Die Software-Komponenten sind somit streng in aufgabenbezogene, das heißt funktionale Schichten, gegliedert. Dabei realisiert die Schichtenarchitektur vorzugsweise eine Trennung von hardwareunabhängigen Software-Komponenten von hardwareabhängigen Software- Komponenten. Das bedeutet, daß dadurch eine Trennung der eigentlichen Steuereinheitfunktionalität, also der hardwareunabhängigen Software-Komponenten, wie Applikationssoftware, von den hardwareabhängigen Software- Komponenten der Plattformsoftware vollzogen ist. Dadurch wird die Erstellung, Wartung und Wiederverwendung der einzelnen Software-Komponenten erheblich erleichtert. Die Plattformsoftware bzw. die entsprechenden Software- Komponenten können projektübergreifend verwendet werden. Die erfindungsgemäß hinsichtlich Austauschen von
Informationen optimierten Software-Schnittstellen sind dabei für einen Zugriff auf die Steuereinheit vereinheitlicht. Damit ist ein Einsatz standardisierter Methoden bzw. auf diese Standardschnittstellen abgestimmter Werkzeuge während der Entwicklung, in der Fertigung und im Service möglich, wie beispielsweise für Rapid Prototyping, Debugging, Messen und Kalibrieren. Außerdem können die Software-Komponenten der Applikationssoftware hardwareunabhängig spezifiziert werden und sind damit auf unterschiedlichen Steuereinheitenplattformen portierbar.
In einer weiteren bevorzugten Ausführungsform der elektronischen Steuereinheit nimmt die Software in Abhängigkeit von an den Software-Schnittstellen vorliegenden Informationen jeweils einen unter mehreren möglichen Betriebszuständen ein und unterstützt sodann ausschließlich zustandsspezifische Funktionalitäten. Eine Parametrisierung von Software-Komponenten und ein Software- Update erfolgen in der Produktion und im Service beispielsweise meist in einem spezifischen Betriebszustand der Software, in dem Steuerungs-/Regelungs- und Überwachungsfunktionen aus Sicherheitsgründen nur teilweise oder gar nicht ausgeführt werden dürfen. In einer bevorzugten Ausführungsform der erfindungsgemäßen elektronischen Steuereinheit kann die Software als Betriebszustand einen „Software-Update"-, „Software- Parametrierung"-, „Software-Diagnose"-, „Nachlauf"-, „Überwachungs"- , „Ein"- oder „Notlauf"-Zustand einnehmen. Welchen Zustand die Steuereinheit einnimmt, hängt von denen an ihren Software-Schnittstellen vorliegenden Informationen ab. Ist die elektronische Steuereinheit beispielsweise in einem Fahrzeug eingebunden, so kann der Betriebszustand „Ein" beispielsweise bei Einschalten der Zündung des Fahrzeuges eingenommen werden. In diesem Betriebszustand stehen dann beispielsweise alle Anzeigefunktionalitäten der elektronischen Steuereinheit zur Verfügung. Nimmt die Software den Betriebszustand „Software-Update" ein, so wird beispielsweise nur eine Flash-Programmierung über eine „Off-Board"-Diagnoseschnittstelle in der Produktion und im Service unterstützt. Der Betriebszustand „Software- Parametrierung" ist für eine Einstellung von Software- Parametern über die genannte „Off-Board"- Diagnoseschnittstelle in der Produktion oder im Service vorgesehen. Im Falle eines Fahrzeugverbundes kann es sich dabei beispielsweise um eine Umschaltung von Weg- und Geschwindigkeitsanzeigen zwischen Kilometern und Meilen oder um eine Umschaltung zwischen verschiedenen Sprachvarianten handeln. Im Betriebszustand „Software- Diagnose" der Software unterstützt die Software nur
Diagnosefunktionalitäten, wie Funktionen zur Sensor- und Aktuatordiagnose, sowie das Auslesen und Löschen des Fehlerspeichers. Diese Funktionalitäten stehen vorteilhafterweise auch nur in diesem Betriebszustand zur Verfügung bzw. werden seitens der Software nur in diesem Betriebszustand der Software unterstützt. Ferner kann die Software den Betriebszustand „Überwachung" einnehmen, wie beispielweise nach Drehen des Zündschlüssels in eine spezifischen Position bei einem Fahrzeug, wodurch dann Überwachungsfunktionalitäten seitens der Software unterstützt werden. Letztlich kann die Software einen Betriebszustand „Nachlauf" einnehmen, wie beispielsweise nach einem Abstellen des Motors eines Fahrzeuges, in welches die elektronische Steuereinheit eingebunden ist. Dabei werden dann beispielsweise Speicherfunktionalitäten und zeitaufwändigere Überwachungsfunktionalitäten unterstützt. Darüber hinaus ist ein Betriebszustand „Notlauf" denkbar, welcher seitens der Software beispielsweise bei einem Ausfall von sicherheitsrelevanten Komponenten eingenommen wird und in welchem die Software Funktionalitäten unterstützt, die einen Weiterbetrieb mit eingeschränkter Funktionalität ermöglicht.
Neben den Betriebszuständen sind vorzugsweise auch zulässige Übergänge zwischen den einzelnen Betriebszuständen sowie Übergangsbedingungen festgelegt. Dabei werden vorteilhafterweise Zustandsautomaten zur Spezifikation eingesetzt.
Ferner umfaßt die vorliegende Erfindung die Verwendung einer erfindungsgemäßen elektronischen Steuereinheit in einer Automobil-Elektronik, vorzugsweise zur Steuerung von Betriebsabläufen bei einem Fahrzeug.
Darüber hinaus stellt die vorliegenden Erfindung ein Verfahren zur Spezifikation einer Software-Architektur für eine elektronische Steuereinheit bereit. Dabei werden in einem ersten Schritt definierte Software-Schnittstellen spezifiziert. Das bedeutet, daß hier die vorstehend beschriebenen „On-Board"- und „Off-Board"-Schnittstellen der Software festgelegt werden. In einem zweiten Schritt werden Software-Komponenten und deren Schnittstellen spezifiziert. Dabei wird auch eine Kommunikation zwischen den Software-Komponenten bestimmt. In einem weiteren Schritt werden Software-Schichten und mögliche Software- Betriebszuständen bestimmt. In einem darauffolgenden Schritt wird automatisch je eine Zuordnung der Software- Komponenten zu den Software-Schichten und zu den Software- Betriebszuständen vorgenommen, wobei durch anschließende Analyse und Überprüfung der aufgrund der Zuordnungen realisierten Wechselwirkungen die Zuordnungen verifiziert werden.
In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens werden bei unzureichenden Zuordnungen die Software-Komponenten in definierte Subkomponenten und/oder die Software-Schichten in definierte Subschichten und/oder die Software-Betriebszustände in definierte Subzustände unterteilt, worauf automatisch eine erneute Zuordnung durchgeführt wird.
Mit Hilfe des erfindungsgemäßen Verfahrens wird bei Spezifikation einer Software-Architektur für eine elektronische Steuereinheit berücksichtigt, daß zwischen Spezifikation von Software-Komponenten, Software-Schichten und Betriebszuständen der Software zahlreiche Wechselwirkungen bestehen. Durch Berücksichtigung dieser Faktoren bei der Entwicklung der Software-Architektur wird die Software für alle Anwendungen universell einsetzbar und erfordert bei Einsatz der elektronischen Steuereinheit keine erst dann durchzuführende Anpassungen. Ferner wird von der Erfindung ein Computerprogramm und ein Computerprogrammprodukt mit Programmcodemitteln bereitgestellt, wobei bei Ausführung der Programmcodemittel auf einem Computer oder auf einem Computersystem das erfindungsgemäße Verfahren automatisch durchgeführt wird.
Weitere Vorteile der Erfindung werden anhand der folgenden Zeichnungen näher erläutert.
Figur 1 zeigt eine schematische Darstellung einer
Ausführungsform einer erfindungsgemäßen elektronischen Steuereinheit .
Figur 2 zeigt eine schematische Darstellung einer Software- Architektur einer weiteren Ausführungsform einer erfindungsgemäßen elektronischen Steuereinheit.
Figur 1 zeigt eine elektronische Steuereinheit 100. Die elektronische Steuereinheit 100 ist eingebunden in einen übergeordneten Verbund, wie beispielweise ein Fahrzeug, insbesondere mit mehreren Steuereinheiten, Sensoren und Aktuatoren. Neben Schnittstellen der internen Komponenten der Steuereinheit 100, das heißt Schnittstellen innerhalb der Steuereinheit 100, gibt es auch Schnittstellen zu Anwendungen innerhalb des übergeordneten Verbundes, welche die „On-Board"-Schnittstellen darstellen. Die Steuereinheit 100 zeigt als „On-Board"-Schnittstellen eine CAN- Schnittstelle 101 und eine MOST- (Media Oriented Systems Transport) -Schnittstelle 102, über welche Informationen wechselseitig ausgetauscht werden können. An die CAN-
Schnittstelle können beispielsweise Sensoren und Aktuatoren des übergeordneten Verbundes, wie beispielsweise des Fahrzeugs, angekoppelt werden. Die zugehörigen Treiber zur CAN-Schittstelle bzw. zur MOST Schnittstelle sind mit 101A bzw. 102A bezeichnet. Ferner ist ein analoger (103) und ein digitaler (104) Ein- und Ausgang (Analog I/O, Digital I/O) mit den jeweils zugehörigen Treibern 103A und 104A gezeigt. Daneben sind Schnittstelle 105, 106 und 107 dargestellt, an welche beispielsweise verschiedene Anzeigenanwendungen 108 angekoppelt werden können, die von entsprechenden Treibern
109 der Steuereinheit Informationen erhalten. Dabei kann es sich bei den Anzeigeanwendungen beispielsweise um eine Zeigeransteuerung 108A, eine Displayansteuerung 108B oder eine LED-Ansteuerung 108C handeln. In diesem Beispiel sind dann die Treiber 109A als Zeigertreiber, 109B als Displaytreiber und 109C als LED Treiber ausgebildet. Mit Element 120 sind weitere Funktionen der Steuereinheit, wie z.B. Berechnungsfunktionen oder Verarbeitungsfunktionen mit den entsprechenden Objekten, auf denen diese Auszuführen sind dargestellt.
In Figur 2 ist eine Software-Architektur einer elektronischen Steuereinheit 100 dargestellt. Dabei sind die Software-Komponenten Schichten zugeordnet. Hier Beispielsweise eine Plattform Schicht 110 und eine Applikationsschicht 111. Hier ist in der Plattform Schicht
110 außerdem ein CAN Treiber 113 und ein MOST Treiber 122 mit zugehörigen MOST Netzservices 131 enthalten. Dabei ergibt sich auch eine Trennung von hardwareabhängigen
Software-Komponenten, der sogenannten Plattform-Software 110 und hardwareunabhängigen Software-Komponenten, der sogenannten Applikations-Software 111. Dabei beinhaltet die Plattform-Software 110 das Betriebssystem, beispielsweise OSEK-OS, und den sogenannten Hardware-Abstraction-Layer (HAL) zur Definition allgemeiner standardisierter Schnittstellen zur Anbindung an diese hardwareabhängigen Software-Komponenten für verschiedene, wählbare, hardwareunabhängige Software-Komponenten. Der HAL enthält dabei beispielsweis die bereits erwähnten Zeigertreiber 123, Displaytreiber 124, LED-Treiber 125 und I/O Treiber 126. Die hardwareunabhängigen Software-Komponenten in Schicht 111 können beispielsweise die Softwarefunktionen 115 zur Steuerung der Betriebsabläufe bei einem Fahrzeug enthalten. Dabei kann es sich beispielhaft um Anzeigefunktionen und/oder um Berechnungsfunktionen und/oder Verarbeitungsfunktionen, bzw. Steuer- und/oder Regelfunktionen Fl bis F5 zusammengefasst unter 115 sowie andererseits um die entsprechenden Objekte 01 bis 013 zusammengefasst unter 114, auf denen diese Funktionen auszuführen sind handeln. Die softwareinternen Schnittstellen SISS zwischen Plattform-Software 110 und Anwendungssoftware 111 sind dabei schematisch dargestellt und nicht einschränkend bezüglich ihrer exakten Position und Verbindung zu sehen. D.h. z.B. die Verbindungen SISS1 und SISS2 zwischen HAL und den Objekten 114 sind beispielhaft und schematisch dargestellt. Dies gilt ebenso für die übrigen softwareinternen Schnittstellen SISS3 bis SISSβ, wobei jede andere Verbindung und Position ebenso möglich ist. Es wird aber das Prinzip deutlich, dass innerhalb der Schichten 110 und 111 verschiedene Komponenten miteinander vernetzt sind, während beispielsweise bei der Plattform-Sofware 110 nur die obersten Komponenten, abgesehen vom Flash-Loader 112, eine Schnittstelle SISS hin zur Anwendungs-Software aufweisen. So gibt es beispielsweise keine Schnittstelle, die eine direkte Weitergabe der einem CAN-Treiber 113 anliegenden Information an die Anwendungs-Software 111 ermöglicht.
Im allgemeinen werden nun wie bereits ausgeführt zwei Arten von Informationen unterschieden, die den Ablauf bzw. die Aktivierung eines Softwarecodes einer Software-Komponente beeinflussen und über Software-Schnittstellen, z.B. vorgenannte softwareinterne Schnittstellen SISS übertragen werden. Dabei handelt es sich einerseits um Dateninformationen und andererseits um Kontroll- bzw. Steuerinformationen. Bei den Software-Schnittstellen kann dann entsprechend zwischen Datenschnittstellen und
Kontroll- bzw. Steuerschnittstellen unterschieden werden. Diese Unterscheidung gilt sowohl für Ein- und Ausgabeschnittstellen eines Software-Systems, die hier als SESS also softwareexterne Schnittstellen bezeichnet sind als auch für die Schnittstellen SISS der internen
Komponenten des beispielhaften Software-Systems in Figur 2.
Dabei können die Software-Schnittstellen in Abhängigkeit der an sie jeweils ankoppelbaren Anwendungen in „on-board"- und „off-board"-Schnittstellen gruppiert und so weiter verfeinert werden. Die elektronische Steuereinheit ist im allgemeinen in einen übergeordneten Verbund eingebunden, wie beispielsweise in einen Fahrzeugverbund. Anhand dieses Verbundes sind nun die Grenzen der Software der elektronischen Steuereinheit bestimmt bzw. festgelegt. Es ist genau definiert, was zu der Software der elektronischen Steuereinheit gehört und was zur Umgebung oder zum Kontext der Software gehört. Darüber ist dann bestimmt, welche Ein- und Ausgangsschnittstellen die elektronische Steuereinheit aufweist. Ferner sind dann diejenigen Software- Schnittstellen zu Verbund internen Anwendungen, im Rahmen der vorliegenden Erfindung als „On-Board"-Schnittstellen bezeichnet, und demgegenüber diejenigen zu Verbund externen Anwendungen wie oben ausgeführt, im Rahmen der vorliegenden Erfindung als „Off-Board"-Schnittstellen bezeichnet, genau bestimmt. Die „On-Board"-Schnittstellen sind beispielsweise Schnittstellen zu Sollwertgebern, Sensoren und Aktuatoren sowie Schnittstellen für eine Verbund interne Kommunikation, eine sogenannte On-Board-Kommunikation mit anderen elektronischen Systemen des Verbundes, wie beispielsweise eines Fahrzeuges. Dabei können die Schnittstellen SESS On-Board Schnittstellen wie z.B. SESS1 und SESS2 an fahrzeuginterne Hardware durch den HAL oder auch Off-Board Schnittstellen wie z.B. über den CAN Treiber 113 die Schnittstelle SESS4 an ein externes Diagnosegerät sein. Die Schnittstelle SESS4 kann aber auch fahrzeugintern also On-Board Schnittstelle sein z.B. an Aktoren, Sensoren oder weitere Steuereinheiten via CAN-BUS. Gleiches gilt auch für die MOST Schnittstelle 122 und SESS3.
Mit 127 ist in diesem Beispiel z.B. ein ISO Diagnoseprotokoll und mit 128 ein ISO Network Layer bezeichnet. 129 stellt in der Plattform-Software 110 eine Interaction Layer OSEK-COM und 130 ein Netzwerkmanagement OSEK-NM dar.
Die genannte hierarchische Schichtenarchitektur ist hier also mit zwei Schichten 110 und 111 beispielhaft dargestellt, wobei jede Software-Komponente einer Schicht zugeordnet ist. Die Schichten zeichnen sich dadurch aus, dass Software-Komponenten innerhalb einer Schicht beliebig aufeinander zugreifen können, zwischen verschiedenen Schichten jedoch strenge Regeln über die Schnittstellen SISS gelten. Die Schichten sind entsprechend nach ihnen zugeordneten Abstraktionsniveaus angeordnet. Von Schichten mit höherem Abstraktionsniveau kann auf Schichten mit niedrigerem Abstraktionsniveau zugegriffen werden. Der Zugriff von niedrigeren Schichten auf höhere Schichten ist dagegen stark eingeschränkt oder unzulässig. Weitere
Schichten könnten dabei z.B. eine Sensorik-Schicht oder auch eine Aktorik-Schicht sein, welche aber hier aus Gründen der Übersichtlichkeit nicht explizit dargestellt sind. Die Software-Komponenten sind somit streng in aufgabenbezogene, das heißt funktionale Schichten, gegliedert. Dabei realisiert die Schichtenarchitektur aber vorzugsweise eine Trennung von hardwareunabhängigen Software-Komponenten und hardwareabhängigen Software- Komponenten. Das bedeutet, dass dadurch eine Trennung der eigentlichen Steuereinheitfunktionalität, also der hardwareunabhängigen Software-Komponenten, wie Applikationssoftware, von den hardwareabhängigen Software- Komponenten der Plattformsoftware vollzogen ist, mit den bereits ausgeführten Vorteilen, wobei die erfindungsgemäß hinsichtlich Austauschen von Informationen optimierten Software-Schnittstellen dabei für einen Zugriff auf die Steuereinheit vereinheitlicht sind.
Dabei kann die Software in Abhängigkeit von an den Software-Schnittstellen vorliegenden Informationen jeweils einen unter mehreren möglichen Betriebszuständen einnehmen und unterstützt sodann ausschließlich zustandsspezifische Funktionalitäten. Als Betriebszustand sind z.B. denkbar einen „Software-Update"-, „Software-Parametrierung"-, „Software-Diagnose"-, „Nachlauf"-, „Überwachungs"- , „Ein"- oder „Notlauf"-Zustand einzunehmen. Welchen Zustand die Steuereinheit einnimmt, hängt wie gesagt von den an ihren Software-Schnittstellen vorliegenden Informationen ab.
Neben den Betriebszuständen sind vorzugsweise auch zulässige Übergänge zwischen den einzelnen Betriebszuständen sowie Übergangsbedingungen festgelegt. Dabei werden vorteilhafterweise Zustandsautomaten zur Spezifikation eingesetzt. In den Schichten können darüber hinaus Subschichten oder Subkomponenten existieren um bei unzureichenden Zuordnungen die Software-Komponenten in definierte Subkomponenten und/oder die Software-Schichten in definierte Subschichten und/oder die Software-Betriebszustände in definierte Subzustände zu unterteilen, worauf automatisch eine erneute Zuordnung durchgeführt werden kann.
Mit Hilfe des erfindungsgemäßen Verfahrens wird bei Spezifikation einer Software-Architektur für eine elektronische Steuereinheit somit berücksichtigt, dass zwischen Spezifikation von Software-Komponenten, Software- Schichten und Betriebszuständen der Software zahlreiche Wechselwirkungen bestehen. Durch Berücksichtigung dieser
Faktoren bei der Entwicklung der Software-Architektur wird die Software für alle Anwendungen universell einsetzbar und erfordert bei Einsatz der elektronischen Steuereinheit keine erst dann durchzuführenden Anpassungen.

Claims

Ansprüche
1. Elektronische Steuereinheit mit einer darauf implementierten aus Komponenten bestehenden Software, bei der eine Mehrzahl von hinsichtlich Austauschen von Informationen optimierten Software-Schnittstellen zur wahlweisen Ankopplung von einer Mehrzahl von Anwendungen vorgesehen ist, wobei die Software für jede ankoppelbare Anwendung mindestens einen anwendungspezifischen Softwarecode einer Komponente umfaßt, der bei Ankopplung der Anwendung aktiviert wird.
2. Elektronische Steuereinheit nach Anspruch 1, bei der die Software eine hinsichtlich einer gegenseitigen Zugriffsmöglichkeit der Software-Komponenten hierarchische Schichtenarchitektur aufweist, wobei eine jede Software- Komponente einer Schicht zugeordnet ist.
3. Elektronische Steuereinheit nach Anspruch 2, bei der die Schichtenarchitektur eine Trennung von hardwareunabhängigen Software-Komponenten von hardwareabhängigen Software-Komponenten realisiert.
4. Elektronische Steuereinheit nach einem der Ansprüche 1, ι
2 oder 3, bei der die Software-Schnittstellen in Abhängigkeit der an sie jeweils ankoppelbaren Anwendungen in „on-board"- und „off-board"-Schnittstellen gruppiert sind.
5. Elektronische Steuereinheit nach einem der vorhergehenden Ansprüche, bei der die Software in Abhängigkeit von an den Software-Schnittstellen vorliegenden Informationen jeweils einen unter mehreren möglichen Betriebszuständen einnimmt und darin ausschließlich zustandsspezifische Funktionalitäten unterstützt.
6. Elektronische Steuereinheit nach einem der vorhergehenden Ansprüche, bei der die Software als Betriebszustand einen „Software-Update"-, „Software- Parametrierung"-, „Software-Diagnose"-, „Nachlauf"-, „Überwachungs"- oder „Ein"- Zustand einnehmen kann.
7. Verwendung einer elektronischen Steuereinheit (100) nach einem der vorhergehenden Ansprüchen in einer Automobil-Elektronik, insbesondere zur Steuerung von Betriebsabläufen bei einem Fahrzeug.
8. Verfahren zur Spezifikation einer Software-Architektur für eine elektronische Steuereinheit (100), bei dem nach Spezifikation von definierten Software-Schnittstellen, von Software-Komponenten, von Software-Schichten und von Software-Betriebszuständen automatisch je eine Zuordnung der Software-Komponenten zu den Software-Schichten und zu den Software-Betriebszuständen vorgenommen wird, wobei durch anschließende Analyse und Überprüfung der aufgrund der Zuordnungen realisierten Wechselwirkungen die Zuordnungen verifiziert werden.
9. Verfahren nach Anspruch 8, bei dem bei unzureichenden Zuordnungen die Software-Komponenten in definierte Subkomponenten und/oder die Software-Schichten in definierte Subschichten und/oder die Software- Betriebszustände in definierte Subzustände unterteilt werden und automatisch eine erneute Zuordnung durchgeführt wird.
10. Computerprogramm mit Programmcodemitteln, durch welches bei Ausführung der Programmcodeelemente auf einem Computer oder auf einem Computersystem ein Verfahren nach einem der Ansprüche 8 oder 9 automatisch durchgeführt wird.
11. Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um ein Verfahren nach einem der Ansprüche 8 oder 9 durchzuführen, wenn das Computerprogramm auf einem Computer zur Ausführung kommt.
PCT/DE2004/001333 2003-06-24 2004-06-24 Elektronische steuereinheit und verfahren zur spezifikation einer software-architektur für eine elektronische steuereinheit WO2005001582A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2006515279A JP2007507017A (ja) 2003-06-24 2004-06-24 電子制御ユニットおよび電子制御ユニット用のソフトウェアアーキテクチャを仕様化する方法
EP04738782A EP1639416A1 (de) 2003-06-24 2004-06-24 Elektronische steuereinheit und verfahren zur spezifikation einer software-architektur f r eine elektronische steuereinheit
US10/561,737 US20070271551A1 (en) 2003-06-24 2004-06-24 Electronic Control Unit and Method for Specifying a Software Architecture for an Electronic Control Unit
DE112004001620T DE112004001620D2 (de) 2003-06-24 2004-06-24 Elektronische Steuereinheit und Verfahren zur Spezifikation einer Software-Architektur für eine elektronische Steuereinheit

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10328240.8 2003-06-24
DE10328240 2003-06-24

Publications (1)

Publication Number Publication Date
WO2005001582A1 true WO2005001582A1 (de) 2005-01-06

Family

ID=33546618

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2004/001333 WO2005001582A1 (de) 2003-06-24 2004-06-24 Elektronische steuereinheit und verfahren zur spezifikation einer software-architektur für eine elektronische steuereinheit

Country Status (6)

Country Link
US (1) US20070271551A1 (de)
EP (1) EP1639416A1 (de)
JP (1) JP2007507017A (de)
CN (1) CN1813226A (de)
DE (1) DE112004001620D2 (de)
WO (1) WO2005001582A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008026452A1 (de) * 2008-06-03 2009-12-10 Claas Selbstfahrende Erntemaschinen Gmbh Kommunikationssystem zum Austausch von Daten

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9128727B2 (en) * 2006-08-09 2015-09-08 Microsoft Technology Licensing, Llc Generation of managed assemblies for networks
US8392882B2 (en) * 2006-11-30 2013-03-05 Caterpillar Inc. Engine state-based control of software functions
CN103105825A (zh) * 2011-11-09 2013-05-15 上海华丰工业控制技术工程有限公司 一种电子控制单元及使用方法
US9160620B2 (en) * 2011-11-30 2015-10-13 GM Global Technology Operations LLC Integrated fault diagnosis and prognosis for in-vehicle communications
DE102017219188A1 (de) * 2017-10-26 2019-05-02 Robert Bosch Gmbh Verfahren zum Aktualisieren von Softwarekomponenten eines Netzwerkteilnehmers eines Netzwerks
US11305978B2 (en) * 2018-08-13 2022-04-19 Carlisle Fluid Technologies, Inc. Modular plural component platform

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19750662A1 (de) * 1997-11-15 1999-05-27 Daimler Benz Ag Prozessoreinheit für ein datenverarbeitungsgestütztes elektronisches Steuerungssystem in einem Kraftfahrzeug
DE19921065A1 (de) * 1999-05-07 2000-11-09 Bosch Gmbh Robert Verfahren und Vorrichtung zum Betrieb einer Steuereinheit zur Steuerung von Betriebsabläufen in einem Fahrzeug
DE10000997A1 (de) * 1999-01-28 2001-01-04 Ibm Elektronisches Steuersystem
DE10012272A1 (de) * 2000-03-14 2001-09-27 Daimler Chrysler Ag Verfahren zur Abspeicherung von Daten

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19909157A1 (de) * 1999-03-02 2000-09-21 Daimler Chrysler Ag Verteiltes Fahrzeuginformationsverarbeitungs- und Fahrzeugsteuersystem
EP1046991B1 (de) * 1999-04-20 2002-12-11 Siemens Aktiengesellschaft Verfahren zum Testen der Unabhängigkeit und Verträglichkeit eines Software-Moduls
JP4427860B2 (ja) * 2000-03-24 2010-03-10 株式会社デンソー 車両用制御装置及び記録媒体
DE10044319A1 (de) * 2000-09-07 2002-03-21 Bosch Gmbh Robert Elektronisches System für ein Fahrzeug und Systemschicht für Betriebsfunktionen

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19750662A1 (de) * 1997-11-15 1999-05-27 Daimler Benz Ag Prozessoreinheit für ein datenverarbeitungsgestütztes elektronisches Steuerungssystem in einem Kraftfahrzeug
DE10000997A1 (de) * 1999-01-28 2001-01-04 Ibm Elektronisches Steuersystem
DE19921065A1 (de) * 1999-05-07 2000-11-09 Bosch Gmbh Robert Verfahren und Vorrichtung zum Betrieb einer Steuereinheit zur Steuerung von Betriebsabläufen in einem Fahrzeug
DE10012272A1 (de) * 2000-03-14 2001-09-27 Daimler Chrysler Ag Verfahren zur Abspeicherung von Daten

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SUNGJOO YOO ET AL: "Building fast and accurate SW simulation models based on hardware abstraction layer and simulation environment abstraction layer", DESIGN, AUTOMATION AND TEST IN EUROPE CONFERENCE AND EXHIBITION, 2003 MUNICH, GERMANY 3-7 MARCH 2003, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 3 March 2003 (2003-03-03), pages 550 - 555, XP010673551, ISBN: 0-7695-1870-2 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008026452A1 (de) * 2008-06-03 2009-12-10 Claas Selbstfahrende Erntemaschinen Gmbh Kommunikationssystem zum Austausch von Daten

Also Published As

Publication number Publication date
CN1813226A (zh) 2006-08-02
JP2007507017A (ja) 2007-03-22
DE112004001620D2 (de) 2006-05-11
EP1639416A1 (de) 2006-03-29
US20070271551A1 (en) 2007-11-22

Similar Documents

Publication Publication Date Title
DE102007026678A1 (de) Verfahren zum Austausch eines defekten Feldgerätes gegen ein neues Feldgerät in einem über digitalen Feldbus kommunizierenden System, insbesondere Automatisierungssystem
WO2004086156A2 (de) Verfahren zur übertragung von softwarecode von einer steuereinheit zu einem feldgerät der prozessautomatisierungstechnik
EP1710647A2 (de) Integration von Feldgeräten in ein Automatisierungssystem
EP1989470B1 (de) Sicherheitskonzept für eine getriebestellvorrichtung
WO2008003615A1 (de) Verfahren zum durchführen eines tests
EP1639416A1 (de) Elektronische steuereinheit und verfahren zur spezifikation einer software-architektur f r eine elektronische steuereinheit
DE102007006614A1 (de) Anwendung einer verteilten Diagnosearchitektur in AUTOSAR
EP1597641A1 (de) Steuergerät zum steuern eines antriebsaggregates eines fahrzeugs
WO2010121798A1 (de) System und verfahren zum verteilen von projektdaten einer sicherheitssteuerung einer automatisierten anlage auf die steuerungskomponenten
EP1758001A2 (de) Verfahren und System zum Abbilden der Struktur einer Automatisierungsanlage auf einem Rechner
WO2005040838A1 (de) System und verfahren zum testen von steuervorgängen bei einem fahrzeug
DE102006062604A1 (de) Verfahren zum Testen von Gerätebeschreibungen für Feldgeräte der Automatisierungstechnik
DE102008023873A1 (de) Verfahren zum Betrieb eines Antriebssystems
DE19921065A1 (de) Verfahren und Vorrichtung zum Betrieb einer Steuereinheit zur Steuerung von Betriebsabläufen in einem Fahrzeug
WO2007065585A1 (de) Diagnoseverfahren und diagnosevorrichtung zur funktionsorientierten diagnose eines systems mit vernetzten komponenten
EP2360540B1 (de) Datenträger mit Schaubildern zur Konfiguration eines Antriebssystems und Rechner mit graphischer Benutzerschnittstelle
DE10332113A1 (de) Steuergerät und Netzwerk für eine Mehrzahl von Vorrichtungen
DE102019132428A1 (de) Funktionsorientierte Elektronik-Architektur
DE102004008869A1 (de) Steuergerät und Computerprogramm zum Steuern eines Antriebsaggregates eines Fahrzeugs
EP4144003B1 (de) Verfahren zum erzeugen einer softwarekomponente für eine elektronische recheneinrichtung eines kraftfahrzeugs, computerprogrammprodukt, computerlesbares speichermedium sowie kraftfahrzeugexternes aktualisierungssystem
EP1179428B1 (de) Verfahren und Vorrichtung zum Abarbeiten von Verfahrensschritten
DE102019134872B4 (de) Verbesserung der Betriebsparameter eines Rechensystems im Fahrzeug
EP3757688B1 (de) Verfahren zur konfiguration einer industriellen maschine
EP1642422B1 (de) Anpassung eines fahrzeugnetzwerks an geänderte anforderungen
DE102022211737A1 (de) Verfahren zum Ermitteln von Regeln für eine Überwachungsvorrichtung

Legal Events

Date Code Title Description
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 DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL 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): BW GH 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 IT LU 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

WWE Wipo information: entry into national phase

Ref document number: 2004738782

Country of ref document: EP

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: 2006515279

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 20048176982

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 1120040016207

Country of ref document: DE

WWP Wipo information: published in national office

Ref document number: 2004738782

Country of ref document: EP

REF Corresponds to

Ref document number: 112004001620

Country of ref document: DE

Date of ref document: 20060511

Kind code of ref document: P

WWE Wipo information: entry into national phase

Ref document number: 112004001620

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 10561737

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10561737

Country of ref document: US

WWR Wipo information: refused in national office

Ref document number: 2004738782

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2004738782

Country of ref document: EP