EP1639416A1 - Unite de commande electronique et procede de definition d'une architecture de logiciel pour une unite de commande electronique - Google Patents

Unite de commande electronique et procede de definition d'une architecture de logiciel pour une unite de commande electronique

Info

Publication number
EP1639416A1
EP1639416A1 EP04738782A EP04738782A EP1639416A1 EP 1639416 A1 EP1639416 A1 EP 1639416A1 EP 04738782 A EP04738782 A EP 04738782A EP 04738782 A EP04738782 A EP 04738782A EP 1639416 A1 EP1639416 A1 EP 1639416A1
Authority
EP
European Patent Office
Prior art keywords
software
control unit
electronic control
interfaces
components
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP04738782A
Other languages
German (de)
English (en)
Inventor
Thomas Zurawka
Joerg Schaeuffele
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
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
Publication of EP1639416A1 publication Critical patent/EP1639416A1/fr
Ceased legal-status Critical Current

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

La présente invention concerne un unité de commande électronique (100) dans laquelle est exploité un logiciel constitué de composants, et une pluralité d'interfaces de logiciel (101, 102, 103, 104, 105, 106) optimisées en ce qui concerne les échanges d'informations, pour la connexion sélective d'une pluralité d'applications. Le logiciel présente, pour chaque application pouvant être connectée, un code de logiciel, spécifique à l'application, d'un composant, lequel est activé lors de la connexion de l'application. L'invention concerne en outre un procédé correspondant de définition d'une architecture de logiciel d'une unité de commande électronique (100).
EP04738782A 2003-06-24 2004-06-24 Unite de commande electronique et procede de definition d'une architecture de logiciel pour une unite de commande electronique Ceased EP1639416A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10328240 2003-06-24
PCT/DE2004/001333 WO2005001582A1 (fr) 2003-06-24 2004-06-24 Unite de commande electronique et procede de definition d'une architecture de logiciel pour une unite de commande electronique

Publications (1)

Publication Number Publication Date
EP1639416A1 true EP1639416A1 (fr) 2006-03-29

Family

ID=33546618

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04738782A Ceased EP1639416A1 (fr) 2003-06-24 2004-06-24 Unite de commande electronique et procede de definition d'une architecture de logiciel pour une unite de commande electronique

Country Status (6)

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

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
DE102008026452A1 (de) * 2008-06-03 2009-12-10 Claas Selbstfahrende Erntemaschinen Gmbh Kommunikationssystem zum Austausch von Daten
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
US11305978B2 (en) * 2018-08-13 2022-04-19 Carlisle Fluid Technologies, Inc. Modular plural component platform

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19750662C2 (de) * 1997-11-15 2002-06-27 Daimler Chrysler Ag Prozessoreinheit für ein datenverarbeitungsgestütztes elektronisches Steuerungssystem in einem Kraftfahrzeug
US6292718B2 (en) * 1999-01-28 2001-09-18 International Business Machines Corp. Electronic control system
DE19909157A1 (de) * 1999-03-02 2000-09-21 Daimler Chrysler Ag Verteiltes Fahrzeuginformationsverarbeitungs- und Fahrzeugsteuersystem
EP1046991B1 (fr) * 1999-04-20 2002-12-11 Siemens Aktiengesellschaft Méthode pour tester l' autonomie et la compatibilité d'un module programme
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
DE10012272B4 (de) * 2000-03-14 2004-04-08 Daimlerchrysler Ag Verfahren zur Abspeicherung von Daten in rechnergestützten Geräten von Verkehrsmitteln
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

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
CN1813226A (zh) 2006-08-02
WO2005001582A1 (fr) 2005-01-06
US20070271551A1 (en) 2007-11-22
JP2007507017A (ja) 2007-03-22
DE112004001620D2 (de) 2006-05-11

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 (fr) Procede de transmission d'un code de logiciel d'une unite de commande a un appareil de terrain associe a la technique d'automatisation de processus
EP1989470B1 (fr) Concept de sécurité pour un dispositif de positionnement à engrenage
DE102007006614A1 (de) Anwendung einer verteilten Diagnosearchitektur in AUTOSAR
WO2010121798A1 (fr) Système et procédé de répartition de données de projets d'une commande de sécurité d'une installation automatisée aux composants de commande
WO2004077180A1 (fr) Appareil de commande et commande d'une unite d'entrainement d'un vehicule
WO2005001582A1 (fr) Unite de commande electronique et procede de definition d'une architecture de logiciel pour une unite de commande electronique
EP1758001A2 (fr) Procédé et système destinés à représenter la structure d' une installation d' automatisation sur un ordinateur
WO2005040838A1 (fr) Systeme et procede pour tester des processus de commande dans un vehicule
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 (fr) Procede et dispositif de diagnostic oriente fonction d'un systeme comportant des composants mis en reseau
EP2360540B1 (fr) Support de données doté de graphiques pour la configuration de systèmes d'entraînement et ordinateur doté d'une interface utilisateur graphique
DE102019132428A1 (de) Funktionsorientierte Elektronik-Architektur
DE10332113A1 (de) Steuergerät und Netzwerk für eine Mehrzahl von Vorrichtungen
EP1117023B1 (fr) Dispositif de diagnostic de fautes pendant le fonctionnement d'un véhicule automobile
DE102004008869A1 (de) Steuergerät und Computerprogramm zum Steuern eines Antriebsaggregates eines Fahrzeugs
EP4144003B1 (fr) Procédé de fabrication d'un composant logiciel pour un dispositif informatique électronique d'un véhicule automobile, produit de programme informatique, support de stockage lisible par ordinateur et système de mise à jour externe de véhicule automobile
EP1179428B1 (fr) Procédé et dispositif pour exécuter des pas d'un procédé
EP3757688B1 (fr) Procédé de configuration d'une machine industrielle
DE102019134872B4 (de) Verbesserung der Betriebsparameter eines Rechensystems im Fahrzeug
EP1642422B1 (fr) Adaptation d'un reseau embarque dans un vehicule a des exigences modifiees
DE102022211737A1 (de) Verfahren zum Ermitteln von Regeln für eine Überwachungsvorrichtung
WO2012139638A1 (fr) Procédé de détermination automatique de la probabilité d'erreur d'une application de sécurité

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060124

AK Designated contracting states

Kind code of ref document: A1

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

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20070301

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20080525