EP1639464A2 - Procede pour verifier la securite et la fiabilite de systemes electroniques a base de logiciels - Google Patents

Procede pour verifier la securite et la fiabilite de systemes electroniques a base de logiciels

Info

Publication number
EP1639464A2
EP1639464A2 EP04738766A EP04738766A EP1639464A2 EP 1639464 A2 EP1639464 A2 EP 1639464A2 EP 04738766 A EP04738766 A EP 04738766A EP 04738766 A EP04738766 A EP 04738766A EP 1639464 A2 EP1639464 A2 EP 1639464A2
Authority
EP
European Patent Office
Prior art keywords
functions
reliability
components
security
monitoring
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.)
Withdrawn
Application number
EP04738766A
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 EP1639464A2 publication Critical patent/EP1639464A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/008—Reliability or availability analysis

Definitions

  • the invention relates to a method for checking the security and reliability of software-based electronic systems using a reliability function for checking the required functions of the system on the basis of the hardware components of the system required for this. Furthermore, the invention relates to uses of this method and to a computer program and computer program product for implementing the method.
  • Reliability and safety requirements for example on vehicle functions, result from customer requirements, taking into account the technical, legal and financial constraints.
  • Reliability requirements for vehicle functions are specified, for example, in the form of short repair times or long service intervals.
  • Safety requirements determine the safe behavior of the vehicle in the event of failures and Faults in components of the vehicle.
  • the reliability and safety requirements placed on vehicle functions also set requirements for technical implementation and verification requirements from the start.
  • One of the most powerful measures to increase security and reliability is redundancy. As vehicle functions or parts of vehicle functions are increasingly implemented by software, systematic methods for reliability and safety analysis also have an increasing influence on the
  • Reliability analyzes include, for example, failure rate and failure type analyzes, such as failure type and impact analysis (FMIA) or fault tree analysis (FTA).
  • FMIA failure type and impact analysis
  • FTA fault tree analysis
  • the systematic examination of the failure rate of a viewing unit enables the reliability of the viewing unit to be predicted by calculation. This prediction is important in order to identify weaknesses at an early stage, to evaluate alternative solutions and to be able to quantitatively determine relationships between reliability, security and availability. In addition, studies of this type are necessary in order to be able to place reliability requirements on system components, for example.
  • the calculated, predicted reliability can only be one
  • the observation unit is always a technical system or a system component of the vehicle.
  • the observation unit can also be expanded and, for example, also include the driver of the vehicle.
  • the failure rate analysis is a multi-stage process and can be "top down ⁇ from the system level to the various
  • Failure rate analysis must be repeated after changes to the technical system architecture.
  • the first step of the failure rate analysis will be explained in more detail below.
  • Possible improvements include limiting or reducing the load on the components during operation, such as static or dynamic loads, the load on the interfaces, the use of more suitable components, the simplification of the system or component design, the pretreatment of critical components, and the use of redundancy.
  • the required function specifies the task of the system.
  • the definition of the system limits and the required functions forms the starting point of every reliability analysis because this also defines the failure.
  • B. the temperature range has a major impact on the failure rate of hardware components.
  • the vehicle include B. the required temperature range, use under Moisture, dust or corrosive atmosphere, or exposure to vibrations, shocks or fluctuations, such as the supply voltage to the environmental conditions. If the required functions and environmental conditions also depend on the time, a requirement profile must be defined.
  • An example of legally required requirement profiles in the vehicle are the driving cycles to demonstrate compliance with the exhaust gas regulations. In this case one speaks of representative requirement profiles.
  • the reliability block diagram provides answers to the questions as to which hardware components ⁇ of a system must fundamentally function in order to fulfill the required function and which hardware components do not fundamentally impair the function in the event of a failure because they are redundant.
  • the reliability block diagram is prepared by looking at the components of the technical system architecture. These components are connected in a block diagram in such a way that the components required to fulfill the function are connected in series and redundant
  • Components are connected in a parallel connection.
  • Figure 1 schematically represents a so-called brake-by-wire system 1, the brake pedal 2, the control unit 3 and the four brake units, namely the brake unit 4 front left, the brake unit 5 rear left, the brake unit 6 front right and the Brake unit 7 rear right, are shown.
  • the hardware components required for a function of the system 1 are denoted by K.
  • K The hardware components required for a function of the system 1
  • the system limit is first defined.
  • the system consists of the components of the brake pedal unit (Ki), the control unit (K 2 ), the wheel brake units (K 5 ,, K 7 , K 9 , K ⁇ ) and the electrical connections (K 3 ,, K, K 6 , K 8 , Kio ) •
  • the function "braking" should be considered.
  • the overall reliability of the system should be determined. It is assumed that the failure rates ⁇ i to ⁇ of the components _ ⁇ to Kn are known.
  • the reliability block diagram for the “braking” function looks as shown in FIG. 2.
  • the reliability function of the system R s (t) can be calculated taking into account the basic rules for reliability block diagrams shown in Table 3 below. Table 3: Some basic rules for calculating the reliability function for the system
  • the system reliability for a function increases due to redundant components in the reliability block diagram compared to that Component reliability.
  • the system reliability is reduced compared to the component reliability.
  • Software-based electronic systems consist mainly of hardware components and software components, whereby the software components can usually be distributed over some of the hardware components of the system. There is a strong need to be able to reliably check both the security and the reliability of such software-based electronic systems.
  • a reliability function for calculating the reliability of at least one of the required functions of the system and a further reliability function for calculating the reliability of at least one of the Security functions of the system are determined, software components of the system also being taken into account when determining these reliability functions.
  • the software components are based on the hardware components on which they are based
  • Software components are distributed, taken into account. This consideration can extend to the hardware component (s) themselves and also to the corresponding hardware connections that are influenced by the respective software component (e.g. by outputting an output signal). This makes it possible for the first time to make statements about the security and reliability of a software-based electronic system, these statements relating to the system consisting of hardware and software components, including the respective connections, and not limited to the hardware components.
  • Systems comprising software components are checked using a reliability function, which can be determined for the system, for example, using the reliability block diagram explained at the beginning.
  • a reliability function which can be determined for the system, for example, using the reliability block diagram explained at the beginning.
  • the software components of the system are also taken into account when determining the reliability function.
  • This is equivalent to a new system definition, since previously only a system consisting of hardware components was considered for reliability analyzes and the software components were subjected to their own separate analysis, if at all.
  • the early evaluation of different monitoring concepts of electronic control units in particular and of functions of electronic systems in general, which are implemented by software and hardware is possible with regard to the achievable system security and system reliability.
  • the results particularly influence the distribution of software functions on the microcontrollers of networked control units and thus the development of software for distributed and networked control units.
  • Reliability functions generally take up a certain range of values, for example from 0 to 1, it being assumed in the following without restricting the general applicability that a high value (1) for a high value, a low value (0) for a low value Reliability should stand.
  • the invention
  • Reliability functions relate on the one hand to the reliability of the required system functions, and on the other hand to the reliability of the safety functions of the system. After determining the corresponding reliability functions, it is advantageous to calculate the concrete values of these reliability functions for the selected system architecture (or system configuration) in order to make concrete statements about the Maintain reliability of the system functions and the safety functions.
  • system architecture can be changed as follows: by specifying the hardware components necessary for the implementation of the required system functions and security functions (type of hardware components, arrangement and redundancies of these components); Definition of the software components necessary for the implementation of the required system functions and security functions and finally the assignment of the software components to specific hardware components.
  • the system architecture can be changed by varying one or more of these specifications or assignments.
  • the calculated reliabilities can refer either to the required system functions or to the safety functions of the system. However, it is advantageous to maximize both reliabilities in order to find a system architecture that is both regarding Reliability and security achieved high values.
  • Security can be further increased in that the monitoring functions for monitoring the system functions are in turn monitored by system monitoring functions.
  • the system monitoring functions at least partially monitor the system section that contains the monitoring functions for monitoring the system functions.
  • the entire system section for example a microcontroller
  • System monitoring functions are divided into two system sections, one system section of which contains the said monitoring functions and the required system functions which are controlled by these monitoring functions. Such a configuration enables the two to be monitored System sections in any direction, especially mutual monitoring of these system sections.
  • the method according to the invention can advantageously be used to optimally assign software components to hardware components (such as microcontrollers) in a distributed and networked system (control device). Furthermore, the method according to the invention is advantageously suitable for determining the system architecture of a software-based electronic system, in particular a control device, such as an engine control device.
  • a control device such as an engine control device.
  • the method according to the invention can expediently be implemented for the mostly occurring complex electronic systems by means of a computer program.
  • This computer program determines the associated reliability functions in a given system architecture and uses this to calculate the corresponding values for the reliability and security of the system.
  • the system architecture in particular can be efficiently optimized, whereby known optimization methods (such as Monte Carlo methods) can be used.
  • known optimization methods such as Monte Carlo methods
  • the computer program can quickly determine the corresponding reliability function using the basic rules described at the beginning (see table above).
  • the computer program can be stored on suitable data carriers, such as EEPROMs, flash memories, but also DVDs, CD-ROMs, floppy disks or hard disk drives. Also downloading the computer program via internal or publicly usable networks (intranet or internet) is possible.
  • suitable data carriers such as EEPROMs, flash memories, but also DVDs, CD-ROMs, floppy disks or hard disk drives. Also downloading the computer program via internal or publicly usable networks (intranet or internet) is possible.
  • FIG. 1 shows a schematic illustration of a brake-by-wire system as an example of an electronic system
  • FIG. 2 shows the reliability block diagram associated with the system shown in FIG. 1 for the “braking” function
  • FIG. 3 shows the example of a sequence of steps in the reliability and security analysis and the specification of reliable and safe systems
  • FIG. 4 schematically shows components of a control unit as an example of a distributed and networked system which is monitored according to the invention with regard to security and reliability;
  • FIG. 5 shows various reliability block diagrams for functions of the system shown in FIG. 4.
  • the failure mode analysis provides an assessment of the risk for all functions of the system.
  • the permissible limit risk is usually implicitly specified by safety-related stipulations such as laws, standards or ordinances.
  • the determined risk for the functions of the system and the permissible limit risk are then used to derive safety requirements for the system, for example based on standards such as IEC 61508, which often have a major influence on the system, hardware and software design in the Have electronics development.
  • FIG. 3 shows two main blocks 9 and 10, the first main block 9 relating to reliability and security analysis, the second main block 10 relating to the specification of reliable and safe systems.
  • the reliability and security analysis (main block 9) includes the logical system architecture 11 as well as the technical system architecture 12.
  • the technical system architecture 12 is in turn a result of the system specification, one being changed System specification (system architecture) requires a new reliability and security analysis.
  • the hazard analysis 13 On the other hand the identification of relevant components and subsystems (block labeled 14).
  • the hazard analysis 13 results in the specific dangerous situations 15 and, in connection therewith, the risk failure types and failure rate analysis 17, as described in detail at the beginning of the description.
  • the result of this analysis 17 is the reliability and security requirements 18 for the system.
  • the result of the identification 14 of relevant components and subsystems is the reliability and security-relevant components and subsystems 16 of the system.
  • a necessary and possible system specification (main block 10) is derived from the two results of the reliability and security analysis, namely the reliability and security-relevant components and subsystems 16 and the reliability and security requirements 18 for the system.
  • the relevant components and subsystems influence definition 19 of the verification and validation process and definition 20 of the requirements for technical components and subsystems.
  • the reliability and security requirements 18 on the system influence the definition of the software development process (block 21).
  • FIG. 4 shows the monitoring concept for safety-related control functions f n .
  • FIG. 4 shows a control device 30 as a software-based electronic system.
  • a first microcontroller 31 serves as a functional computer, while a second one
  • Microcontroller 32 is used as a monitoring computer. Signals reach the input stage 33 of the control unit 30 and are fed from there to the A / D converter 34 in the microcontroller 31. The digitized signal triggers the actual control and regulation functions f n (block 41). In parallel, the signals are fed to block 42, which contains the functions for monitoring the control and regulation functions fo n . Block 41 is connected to block 42 to monitor the control functions.
  • Monitoring functions f 0n are in turn checked by functions for monitoring the microcontrollers, ie the so-called system monitoring functions.
  • block 42 is connected to block 43.
  • the blocks 41, 42 and 43 are part of the software 45 of the microcontroller 31.
  • the blocks 42 and 43 have pure monitoring functions.
  • microcontroller 32 serving as the monitoring computer, the software 46 of which includes the functions for monitoring the microcontrollers (block 44). From this it can be seen that these functions for monitoring the microcontrollers (system monitoring functions) on the two microcontrollers 31 and 32 are distributed. This will be discussed later. Blocks 42, 43 and 44 represent monitoring functions 29.
  • control unit The control and executed by the control unit
  • Control functions f n (block 41) are applied in the form of an output signal to a D / A converter 35, the output of which is at the output stage 40.
  • the outputs 36, 37 and 38 of the monitoring blocks 42, 43 and 44 are fed to an adder 39, so that the detection of an error by one of the three blocks 42, 43 or 44 leads to a corresponding output signal of the adder 39.
  • the latter is connected to the output stage 40, so that depending on the type of error, the output stage can be influenced in a defined manner.
  • the safety-related control functions f n are continuously monitored by the monitoring functions f Un .
  • the monitoring functions f 0n use the same input variables as the control and regulation functions f n , but work with different data and with different algorithms.
  • the functions for monitoring the microcontrollers 31, 32 are distributed to the function computer and the monitoring computer. Both prefer to monitor each other in a question-answer game.
  • the current cutoff for the electromechanical throttle valve is defined as a safe state.
  • the throttle valve is designed so that it automatically assumes the idle position after a power cut. The transition to the safe state can therefore be initiated by switching off the output stages 40 of the control unit, which control the throttle valve. The engine can thus continue to be operated in emergency operation.
  • Both the monitoring functions f u n and the functions for monitoring the microcontroller on the function and on the monitoring computer can switch off so the throttle output stages of the controller 30th If a fault is detected, an entry is made in the fault memory in addition to this safety response. In addition, information is usually also given to the driver, for example via a display in the instrument cluster.
  • Components K 7 and K 8 (connection of blocks 43 and 44 in FIG. 4) which do not appear in the block diagrams of the individual functions are connected in series.
  • the rules for computing with multiple elements in the reliability block diagrams must be observed (see Alessandro Birolini: Reliability of devices and systems, comments above).
  • the reliability R s it standardize these safety reaction is the reliability of the monitoring functions f ün or functions specified for monitoring the microcontroller and is therefore higher than the reliability of the Functions R x .
  • the reliability of the ⁇ components KR and Ks RE n is not included in the calculation of R s safety.
  • the reliability function for the reliability of the safety function (reaction) is as follows:
  • the reliability and security analyzes have a major influence on software development. As shown in the example of the evaluation of the monitoring concept, they influence, for example, the assignment of the software functions to the microcontrollers in a distributed and networked system or the necessary quality assurance measures in software development. This is an enormous advance over the state of the art and leads to great advantages in system development.
  • the method according to the invention enables the following procedure for checking the security and reliability of software-based electronic systems (cf. FIGS. 4 and 5): Step 1: definition of the hardware network of the electronic system, ie in particular specification of the microcontrollers 31, 32 and their networking; Step 2: Definition of the software components 41-44, which are necessary for the implementation of the functions of the electronic system, and specification of the communication between the software components 41-44; Step 3: Assignment of the software components 41-44 to the microcontrollers 31, 32 of the hardware network; Step 4: setting up the
  • Step 5 Proof of security and reliability by calculating the reliability for the security functions and the reliability for the entire required functions of the electronic system (30);
  • Step 6 Repeat steps 1 to 5 and correct the system architecture, if necessary. H. of the software and hardware network, as well as the assignment of the software components to hardware components.

Landscapes

  • Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)
  • Valves And Accessory Devices For Braking Systems (AREA)

Abstract

L'invention concerne un procédé pour vérifier la sécurité et la fiabilité de systèmes électroniques à base de logiciels au moyen d'une fonction de fiabilité servant à vérifier les fonctions requises du système sur la base des composants matériels requis du système. Ce procédé consiste à déterminer une fonction de fiabilité servant à calculer la fiabilité d'au moins une des fonctions requises du système et une autre fonction de fiabilité servant à calculer la fiabilité d'au moins une des fonctions de sécurité du système. Pour la détermination de ces fonctions de fiabilité, des composants logiciels du système sont également pris en considération sur la base de composants matériels, sur lesquels les composants logiciels sont répartis. On obtient ainsi une évaluation précoce de différents concepts de surveillance pour de tels systèmes et de fonctions de ces systèmes, réalisés par l'intermédiaire de logiciels et de matériels.
EP04738766A 2003-06-24 2004-06-23 Procede pour verifier la securite et la fiabilite de systemes electroniques a base de logiciels Withdrawn EP1639464A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10328239 2003-06-24
PCT/DE2004/001317 WO2005003972A2 (fr) 2003-06-24 2004-06-23 Procede pour verifier la securite et la fiabilite de systemes electroniques a base de logiciels

Publications (1)

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

Family

ID=33559736

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04738766A Withdrawn EP1639464A2 (fr) 2003-06-24 2004-06-23 Procede pour verifier la securite et la fiabilite de systemes electroniques a base de logiciels

Country Status (5)

Country Link
US (1) US20070016840A1 (fr)
EP (1) EP1639464A2 (fr)
JP (1) JP2007506591A (fr)
DE (1) DE112004001617D2 (fr)
WO (1) WO2005003972A2 (fr)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7674912B2 (en) 2005-04-25 2010-03-09 H. Lundbeck A/S Pro-drugs of N-thiazol-2-yl-benzamide derivatives
JP4818664B2 (ja) * 2005-09-05 2011-11-16 富士通株式会社 機器情報送信方法、機器情報送信装置、機器情報送信プログラム
DE102007045509B4 (de) * 2007-09-24 2011-06-22 Continental Automotive GmbH, 30165 Fahrzeug-Steuereinheit mit einem Versorgungspannungsüberwachten Mikrocontroller sowie zugehöriges Verfahren
US7920988B2 (en) * 2008-11-13 2011-04-05 Caterpillar Inc. Capturing system interactions
WO2011129038A1 (fr) * 2010-04-13 2011-10-20 日本電気株式会社 Dispositif d'évaluation de fiabilité de système
DE102012024818A1 (de) * 2012-03-06 2013-09-12 Conti Temic Microelectronic Gmbh Verfahren zur Verbesserung der funktionalen Sicherheit und Steigerung der Verfügbarkeit eines elektronischen Regelungssystems sowie ein elektronisches Regelungssystem
DE102014208177A1 (de) * 2014-04-30 2015-11-05 Robert Bosch Gmbh Bilden eines logischen Mikrocontrollers durch wenigstens zwei physikalische Mikrocontrollern auf einem gemeinsamen Halbleitersubstrat
JP6864992B2 (ja) * 2016-04-28 2021-04-28 日立Astemo株式会社 車両制御システム検証装置及び車両制御システム
US10282062B2 (en) 2016-10-03 2019-05-07 Sas Institute Inc. Techniques for repairable system simulations
DE102017213764A1 (de) 2017-08-08 2019-02-14 Robert Bosch Gmbh Vorrichtung zur Zuverlässigkeitsanalyse eines mechatronischen Systems

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3997988B2 (ja) * 2001-05-31 2007-10-24 オムロン株式会社 安全ユニット及びコントローラシステム並びにコントローラの連結方法及びコントローラシステムの制御方法
AU2003217662A1 (en) * 2002-02-25 2003-09-09 General Electric Company Protection system for power distribution systems
US7962319B2 (en) * 2004-03-04 2011-06-14 Halliburton Energy Services, Inc. Method and system for updating reliability prediction models for downhole devices
US7340541B2 (en) * 2004-08-16 2008-03-04 National Instruments Corporation Method of buffering bidirectional digital I/O lines
US7181364B2 (en) * 2005-04-15 2007-02-20 Network Appliance, Inc. Automated detecting and reporting on field reliability of components

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
US20070016840A1 (en) 2007-01-18
JP2007506591A (ja) 2007-03-22
WO2005003972A3 (fr) 2006-08-17
DE112004001617D2 (de) 2006-05-11
WO2005003972A2 (fr) 2005-01-13

Similar Documents

Publication Publication Date Title
EP2146262B1 (fr) Procédé de détermination de composants défectueux dans un système
DE19933086B4 (de) Verfahren und Vorrichtung zur gegenseitigen Überwachung von Steuereinheiten
AT513714B1 (de) Verfahren zur Beurteilung der Beherrschbarkeit eines Fahrzeuges
DE102013216530A1 (de) Fahrzeugsteuerungseinheit und fahrzeugsteuerungssystem
EP2078253A2 (fr) Procédé et dispositif de gestion des pannes
DE102022112904A1 (de) Fahrzeug-Bremsvorrichtung
EP1521697B1 (fr) Procede permettant de garantir ou de conserver du fonctionnement d'un systeme global vital complexe
EP1600831B1 (fr) Méthode et dispositif pour surveiller plusieurs appareils de commande en utilisant une communication interrogation-réponse
EP1639464A2 (fr) Procede pour verifier la securite et la fiabilite de systemes electroniques a base de logiciels
DE10142511B4 (de) Fehlerbehandlung von Softwaremodulen
EP2171585A2 (fr) Procédé d'exploitation d'un microcontrôleur et d'une unité d'exécution, microcontrôleur et unité d'exécution correspondants
WO2006037415A1 (fr) Dispositif de commande dynamique longitudinale pour vehicules a moteur
EP1483745A2 (fr) Systeme et procede pour evaluer la securite de systemes et l'ameliorer, et programme informatique correspondant
WO2023180100A1 (fr) Procédé d'activation d'un système de capteur, système de capteur, véhicule, produit de programme informatique et support de stockage
DE102012221277A1 (de) Fahrzeugsteuervorrichtung
DE10331872A1 (de) Verfahren zur Überwachung eines technischen Systems
DE102019006719A1 (de) Verfahren und System zum Überwachen einer funktionalen Sicherheit einer Antriebskomponente
DE102022202068A1 (de) Verfahren zum Bestimmen einer E/E-Architektur eines Fahrzeugs
DE10332202A1 (de) Bayesnetz-basiertes Expertensystem zur Diagnose, Risikoanalyse und Funktions-Wiederherstellung, insbesondere bei Kraftfahrzeugen
DE102018217728B4 (de) Verfahren und Vorrichtung zum Schätzen von mindestens einer Leistungskennzahl eines Systems
DE102020211541A1 (de) Verfahren zum Erkennen eines Stillstands eines Fahrzeugs
DE102013200932A1 (de) Verfahren und Vorrichtung zur Überwachung einer Funktion eines Motorsteuergeräts zum Einsatz in einem Motorsystem mit einem Verbrennungsmotor
DE10315344A1 (de) Verfahren und Vorrichtung zur Erkennung fehlerhafter Komponenten in Fahrzeugen
DE10312557B4 (de) Verfahren zur Überprüfung der funktionalen Sicherheit von elektronischen Systemen eines Fahrzeugs
EP4362363A1 (fr) Procédés et systèmes de traitement de données utiles

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

AK Designated contracting states

Kind code of ref document: A2

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

AX Request for extension of the european patent

Extension state: AL HR LT LV MK

PUAK Availability of information related to the publication of the international search report

Free format text: ORIGINAL CODE: 0009015

DAX Request for extension of the european patent (deleted)
17P Request for examination filed

Effective date: 20070219

RBV Designated contracting states (corrected)

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

17Q First examination report despatched

Effective date: 20071121

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20080402