WO2003075104A2 - Einrichtung und verfahren zur beurteilung und erzielung von sicherheit bei systemen sowie entsprechendes computerprogramm - Google Patents

Einrichtung und verfahren zur beurteilung und erzielung von sicherheit bei systemen sowie entsprechendes computerprogramm Download PDF

Info

Publication number
WO2003075104A2
WO2003075104A2 PCT/DE2003/000329 DE0300329W WO03075104A2 WO 2003075104 A2 WO2003075104 A2 WO 2003075104A2 DE 0300329 W DE0300329 W DE 0300329W WO 03075104 A2 WO03075104 A2 WO 03075104A2
Authority
WO
WIPO (PCT)
Prior art keywords
error
functional structure
component
errors
systems
Prior art date
Application number
PCT/DE2003/000329
Other languages
English (en)
French (fr)
Other versions
WO2003075104A3 (de
Inventor
Pio Torre Flores
Andreas Lapp
Wolfgang Laengst
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 EP03706283A priority Critical patent/EP1483745A2/de
Priority to US10/506,372 priority patent/US7469170B2/en
Priority to JP2003573502A priority patent/JP4382494B2/ja
Publication of WO2003075104A2 publication Critical patent/WO2003075104A2/de
Publication of WO2003075104A3 publication Critical patent/WO2003075104A3/de

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0001—Details of the control system
    • B60W2050/0002—Automatic control, details of type of controller or control system architecture
    • B60W2050/0004—In digital systems, e.g. discrete-time systems involving sampling
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0001—Details of the control system
    • B60W2050/0043—Signal treatments, identification of variables or parameters, parameter estimation or state estimation
    • B60W2050/0044—In digital systems
    • B60W2050/0045—In digital systems using databus protocols
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0205—Diagnosing or detecting failures; Failure detection models
    • B60W2050/021—Means for detecting failure or malfunction

Definitions

  • the invention relates to a device and a method for assessing the security of systems, in particular in a motor vehicle, in an early phase of product development, and to a corresponding computer program or computer program product according to the preambles of the independent claims.
  • the method according to the preamble of the independent claim corresponding category is called CARTRONIC ® based security analysis (CSA) and carried out accordingly by the facility or when the computer program is executed.
  • CSA CARTRONIC ® based security analysis
  • the development phase is an abstract way of looking at a system, ie it is known which functions the system should perform and how these functions interact. However, it has not yet been determined how these functions will be implemented (e.g. hardware, software, mechanics).
  • This abstract perspective can be represented by the CARTRONIC ® structuring concept, which is independent of the automobile manufacturer and supplier. This structuring concept forms the basis for the CARTRONIC ® based security analysis.
  • the increasing complexity, particularly of the motor vehicle system is due on the one hand to the increasing complexity and number of the individual subsystems, but is also significantly influenced by their increasing networking.
  • the complexity of the motor vehicle system can be controlled by structuring the subsystems according to CARTRONIC ® , taking into account the interactions with other subsystems.
  • the CARTRONIC ® structuring concept (see Bertram, T., - Bitzer, R.; Mayer, R.; Volkhart, A.; 1998, CARTRONIC - An open architecture for networking the control Systems of an automobile, Detroit / Michigan USA, SAE 98200 ) is based on an object-oriented approach.
  • the motor vehicle system is structured into logical functional units that communicate with one another via standardized interfaces.
  • CARTRONIC ® is a structuring concept for all control and regulation systems of a vehicle.
  • the concept contains modular and expandable architectures for "Function” and "security” on the basis of agreed formal structuring and modeling rules.
  • An architecture is to be understood here as the structuring system (rules) as well as its implementation in a concrete structure.
  • the functional architecture encompasses all control and regulation tasks occurring in the vehicle.
  • the tasks of the system network are assigned to so-called functional components, the interfaces of the components (functional interfaces) and their interaction are defined.
  • the security architecture extends the functional architecture by elements that guarantee the safe operation of the system network.
  • UML Unified Modeling Language
  • Another form of representation results from mapping in UML (Unified Modeling Language), which also facilitates porting to a computer system.
  • UML Unified Modeling Language
  • the mapping of a CARTRONIC 119 functional structure into a UML model is described in (Torre Flores, P.; Läpp, A.; Hermsen, W.; Schirmer, J.; Walther, M.; Bertram, T .; Petersen, J .; 2001, Integration of a structuring concept for vehicle control Systems into the Software development process using UML modeling methods, Detroit / Michigan USA, SAE 2001-01-0066).
  • the basic structure for structuring is the functional component.
  • a functional component represents a function in the motor vehicle system.
  • the term functional component instead of the term functional component, only the term component is used in favor of a compact representation.
  • the components can be refined in the course of development
  • the higher-level function is in turn composed of components within the refinement (detailing), the individual parts of the higher-level function represent.
  • the structuring rules describe permitted communication relationships within the architecture of the overall vehicle. A distinction is made between structuring rules that define the communication relationships on the same level of abstraction and in higher and lower levels, taking into account the specified boundary conditions. Furthermore, the structuring rules clarify the forwarding of communication relationships into the detailing of another functionality.
  • Control elements, sensors and estimators are equivalent information providers and one
  • the invention relates to a device, in particular a computer system, and a computer program or
  • Computer program product as well as a method for performing a safety analysis in systems, in particular in a motor vehicle, the systems or the at least one system consisting of several components between which there are communication relationships, the components and their communication relationships being a functional structure of the systems or the at least one system form, errors advantageously being determined as a function of and ⁇ the functional structure
  • the invention shows a device, in particular a computer system, and a computer program or computer program product, and a method for achieving a predefinable security level in systems, in particular in a motor vehicle, the systems or at least one system consisting of several components, between which
  • a safety analysis is thus advantageously carried out in an early phase of product development, in order to recognize problem areas in good time and the early integration of safety measures into the functional structure (“safety through design”).
  • the security analysis according to the invention is therefore expediently also represented as an iterative analysis and improvement process.
  • the method for assessing the security of systems can advantageously be represented on the basis of CARTRONIC® " functional structures or CARTRONIC ⁇ -UML models, but can also be applied to other system models.
  • the method is expediently carried out using the CSA table.
  • Global effects of errors are identified and evaluated using the CSA table. It documents error dependencies of components and
  • Misconduct is caused by functional structure errors (FS errors) in components or communications.
  • Communication errors (orders, requests) are taken into account in the target component of the communication.
  • FS errors in queries are taken into account in the source component of the communication.
  • Malfunction of the components is assigned to the global impact. This not only enables an assessment of global conditions, but also which components of the functional structure are responsible for this.
  • the method is integrated in a CARTRONIC ® -based development process. This promotes a formal, systematic approach.
  • the security measures are mapped in particular in a CARTRONIC ® - UML model. This enables a formal verification against specified product requirements or the product specification. A validation of the product specification is also possible with this procedure.
  • Figure 2 shows the CARTRONIC ® functional structure of an exemplary considered brake system.
  • FIG. 3 shows an example of a UML modeling of the CARTRONIC function structure according to FIG. 2.
  • Figure 4 shows the table header of the CSA table with the global effects.
  • FIG. 5 shows the assignment of the effects of errors to the security levels in a flow graph.
  • Figure 6 shows an example of an assessment of the global impact.
  • FIG. 7 shows the propagation of errors in the functional structure or the assignment of FS errors to the global effects.
  • Figure 9 shows the classification of the CSA in a development process, in particular according to the V-model
  • the security analysis described below is based on the CARTRONIC ® functional structure or the CARTRONIC ® UML model of the system under consideration.
  • the CARTRONIC ® UML model is the mapping of a CARTRONIC ® functional structure into the UML (Unified modeling language). The mapping into the UML provides a formalized and more precisely specified representation which facilitates an automated implementation of the invention.
  • the CARTRONIC ® based security analysis is a procedure for systematic security analysis at an abstract system level and thus supports the development credo "safety through design".
  • the procedure for CARTRONIC ® based security analysis described in a previous publication (Bertram, T .; Dominke, P.; Müller, B., 1999, The Safety-Related Aspect of CARTRONIC, Detroit / Michigan USA, SAE '99, Session Code PC 26) is fundamentally revised and expanded to include the analysis of structural error dependencies and the causes of which are described in an abstract manner, for example "errors present” or “errors not present”
  • the method thus represents an abstraction of the FMEA (Failure Mode and Effects Analysis or Failure Possibility and Effect Analysis), which is expanded to include structural analysis
  • the FMEA is a recognized methodical procedure for the analysis, evaluation and documentation of systems, components and manufacturing processes and serves primarily to avoid errors.
  • the intention of the CSA is not to replace an FMEA, but only to support the system developers in the early development phase in identifying potential danger spots.
  • Global effects are physical effects that affect the overall motor vehicle system through actuators. You will be noticed by sensors (or a vehicle driver) through loss of function (e.g.
  • Functional structure errors are errors that a
  • FS error causes are reasons for a component to behave incorrectly.
  • the reason for a component to malfunction is the presence of FS errors.
  • FS errors can be further divided into refined error types. The refined types of errors are then again the cause of the FS errors.
  • the refined types of errors can be:
  • Component is active in an uncontrolled manner
  • Figure 1 shows the procedure of the CARTRONIC ® based security analysis.
  • the procedure can be structured as follows:
  • Step 1 Identify global impacts based on the CARTRONIC ® functional structure or the
  • Step 3 Analysis of FS error causes (see definition
  • Step 4 Assignment of a component's misconduct to the global effects
  • Step 5 Measures for error detection and / or
  • Security structure step 7 verification of the resulting functional
  • Brake system coordinator, brake actuator and brake light In the logical, hierarchical functional structure of CARTRONIC ® , the components of the brake system coordinator and brake actuator are in the detailing of the brake system.
  • the components N02r1e.n distributor, propulsion and brake system are details of the propulsion and brake.
  • propulsion and braking is a detailing of the vehicle movement.
  • the brake light component is in the detailing of light and light signals, which is a detailing of exterior lighting. This in turn is a refinement of the visibility and signaling components in the body and interior.
  • the detailing of the vehicle movement and body and interior are placed on the vehicle level.
  • the vehicle level is the top level of the CARTRONIC ® functional structure.
  • the torque distributor is responsible for distributing the torque requests of the driver.
  • the brake system coordinator component in the detailing of the brake system ensures that the moments are implemented by request 03 to the brake actuator and with request R3 that Activation of the brake light, so that the driver's request is signaled to following vehicles.
  • the CSA table provides an assignment of a malfunction of an individual component to error dependencies within the functional structure.
  • the FS errors documented in the CSA table can be those listed above
  • Error types can be refined.
  • the refined types of errors can be interpreted at the abstract system level as the cause of the FS errors.
  • the "internal effects" are assigned to the global effects. In this way, complex dependencies between
  • Step 1 identify global impacts
  • the actuators which are controlled by the subsystem under consideration, represent the interfaces to the environment.
  • the environment means the motor vehicle as a whole.
  • the actuators for the example system shown in FIG. 2 and FIG. 3 are the brake system or, in the detailing, the brake actuator, the Propulsion and the brake light. Only those global effects are considered and, for example, recorded in a computer system that are the responsibility of the subsystem to be examined. For example, it does not make sense for you to have the Adaptive Cruise Control (ACC) subsystem that controls the braking system
  • ACC Adaptive Cruise Control
  • FIG. 4 shows the table header with the global effects of the CSA table.
  • Step 2 Assess global impacts through security levels The assessment of the global effects is based on the requirement classes defined in DIN V 19250.
  • the requirement classes in the standard are generally defined for MSR protective devices (MSR - measuring, controlling, regulating). The requirements set out there cannot be directly applied to motor vehicles. The points flow in this standard
  • safety levels There are objections to adapted “requirement classes” for automobiles, which are referred to as safety levels (SL) in the context of the CSA.
  • SL safety levels
  • the assignment of the safety levels to the effects of errors is shown in the risk graph of FIG. 5.
  • the frequency of events is to be understood as the target quantity that must be at least fulfilled by the later implementation of a component.
  • An a priori verification of the event frequencies is generally not possible, since reliable data is often only available after a series application. However, it is possible to subsequently compare the setpoint of the event frequency associated with a security level with a recorded actual value. If there is a discrepancy, ie the event frequency actually determined is greater than the permissible event frequency of a security level, we must
  • FIG. 6 shows the assessment of the global effects of the braking system by means of security levels.
  • a braking system is an extremely important functionality of a motor vehicle, which must be guaranteed under all circumstances.
  • the global impact "no braking effect” generally represents a threat to life and limb that cannot be controlled by the driver. Therefore, security level SL4 must be assigned here.
  • security level SLl is assigned because here in As a rule, it can be assumed that maximum minor injuries can be expected, e.g. due to rear-end collisions with low speed difference. In individual cases, there may be a risk to life and limb that is manageable, e.g. switch on the hazard warning lights.
  • Step 3 functional structure failure cause analysis
  • the root cause analysis asks the question: What causes a component to malfunction ⁇ torque distributor, propulsion, brake system, brake system coordinator, brake actuator, brake light ⁇ ?
  • the cause analysis examines what could lead to a malfunction of the CARTRONIC ® components (torque distributor, propulsion, brake system, brake system coordinator, brake actuator, brake light). A misconduct is investigated by Components and their details, insofar as they are known.
  • the CARTRONIC ® function structure of the system under consideration is adopted in the "Function structure" header of the CSA table.
  • the CARTRONIC ® function structure is adopted in the "Components malfunction" column (see Figure 7).
  • FS errors of the communication relationships that are relevant for the component are also taken into account. If an FS error in a communication relationship causes misconduct, an assignment to the functional structure is also made, which reflects the type and name of the communication under consideration.
  • the type of communication relationship is identified with the uppercase initial letter of the English expression of communication. As a result, an "0" is used for an order, an "R” for a request, and an "I” for an inquiry. An underscore follows the type of communication " _ ", followed by the name of the communication relationship (eg I_I1).
  • a malfunction of the component torque distributor (fc. ⁇ ) Is due to the fact that a component error in the component torque distributor (fc 1 ) itself
  • the brake system component (fc 2 ) has malfunctioned
  • the entries in the CSA table for the example shown in FIG. 2 can be seen in FIG. 8, in particular FIG. 8a.
  • the column brake system (brake system (fc 2 ) is the envelope of the brake system coordinator and brake actuator) of the "functional structure" must be used for the cause analysis
  • the CSA table thus enables logical error dependencies to be tracked.
  • the columns of the function structure with many entries e.g. column torque distributor (fc x ) and column propulsion (fc 3 ), are important components, since an error affects large parts of the system.
  • Step 4 Mapping a component's misconduct to its global impact
  • step 1 the global impacts identified in step 1 are assigned to the components whose misconduct causes a global impact. These components are the system interfaces (see step 1).
  • the component Nominal distributor (fC j ) in the functional structure is assigned to the line Brake actuator malfunction (fc 22 ), ie an FS error in the Torque distributor component can cause the brake actuator to malfunction. It can be concluded from this that a malfunction of the torque distributor component can also cause the global effects of the brake actuator. The global effects of a malfunction of the brake actuator ("no braking effect” and "insufficient braking effect”) are thus also
  • an FS error in the torque distributor component can cause propulsion to malfunction (fc 3 ).
  • a malfunction of the torque distributor component can therefore also have the global effects of "uncontrolled acceleration” and "no acceleration”.
  • An FS error in the torque distributor component can cause the brake light (fc 4 ) to behave incorrectly.
  • a malfunction of the torque distributor component can cause the global effects "no display” and "continuous display”.
  • a malfunction of the brake system (fc 2 ) as a shell of the components brake system coordinator (fc 2X ) and brake actuator (fc 22 ) can cause the global effects of all its components in the detailing.
  • Step 4.1 Assign security levels to component malfunction
  • Step 5 measures for error detection and / or control
  • Table 2 Compilation of measures for error detection and control for functional components.
  • the measures indicate possibilities for recognizing and mastering the abstract causes. These abstract causes can be understood as error modes (types of errors) of the more general FS errors (see definition 3). At a high level of abstraction, measures can be specified that are already evident in an early development phase.
  • Redundant structures can be used in later development phases, i.e. with detailed knowledge of the implemented topology can be converted into cost-effective measures. Examples of this are codes for error detection and correction.
  • the plain text information in the tables is in the program or
  • Computer system can be shortened and assigned by coding.
  • Step 6 CARTRONIC ® - security structure
  • the CARTRONIC ® representation of a system can be mapped into a CARTRONIC 81 -UML model (FIG. 3).
  • CARTRONIC ® representation of a system
  • UML is also an internationally standardized language.
  • the extension must include the mapping of measures for error detection and control, the partitioning of the functions on control units and the representation of temporal and logical processes.
  • the expanded structure can be used to document the security measures used.
  • a representation in which structure, functionality and topology are included is also suitable for future quantitative system analyzes, in particular for automated implementation.
  • FIG. 12 shows the classification of the CSA in a development process.
  • the development process used is based on the V-model.
  • the V-Modell is a federal development standard for IT systems. It is possible to adapt the V-Modell to specific project conditions. This process is called tailoring. Activities (activities) and their products are defined in the V-Modell.
  • the incremental, iterative V-model (UV-model) adapted for the CARTRONIC ® based development process is applied on the three levels system level, subsystem level and partial realization level.
  • the IIV model is navigated along the arrows. It is possible to go from the left to the right side of a level of the V-model (test cases) and back (iterations). Several increments are also possible between the levels.
  • the motor vehicle is viewed as a whole.
  • the subsystem level details the overall motor vehicle system in subsystems. These subsystems can be, for example, the engine control, the brake system, the transmission or an adaptive cruise control.
  • the subsystem level represents the subsystems of the motor vehicle independently of the implementation, ie only the functionality but not the technical implementation is considered. On the
  • each subsystem is further detailed. A decision is made about a topology and whether a function as software, computer hardware, hydraulics, electronics, electrics, mechanics, etc. is implemented. A corresponding subsystem is then created and, if necessary, the software is implemented.
  • a requirements analysis is carried out on the left side of the V model and a draft is drawn up. The right side of the IIV model is used for integration and verification of the draft created at the corresponding level.
  • a validation can be carried out at the system level. A validation checks whether the system specification meets the requirements placed on it. The verification, however, checks a product against the specification. The steps 1 to 5 are described in the
  • Step 6 is implemented in the design phase of the subsystem level. Based on the considerations in step 5, namely that a specification of measures for error detection and control often only makes sense with a known system topology, one is recommended
  • step 5 and step 6 on the partial realization level.
  • the system topology ie the partitioning of the functionalities on control units, is carried out and the functional realizations are defined.
  • the CSA as described here is mainly used at the subsystem level. However, it is advantageous to continue the CSA at the partial realization level.
  • a requirement analysis is carried out, how security measures are to be designed depending on the topology and the implementation of the subsystem, and a corresponding draft is made. This design and its integration can be verified on the right side of the IIV model.
  • the invention shown can run automatically on a computer system.
  • steps 1 to 7 can be stored as program code and executed in a device, in particular a computer system, in order to carry out a method according to the invention.
  • a device in particular a computer system
  • a transfer of the program via networks such as the Internet from one memory to another memory or network participant is also included.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Testing And Monitoring For Control Systems (AREA)
  • Hardware Redundancy (AREA)

Abstract

Verfahren und Einrichtung sowie Computerprogramm zur Durchführung einer Sicherheitsanalyse bei Systemen, insbesondere in einem Kraftfahrzeug, wobei die Systeme oder das wenigstens eine System aus mehreren Komponenten bestehen, zwischen denen Kommunikationsbeziehungen bestehen, wobei die Komponenten und deren Kommunikationsbeziehungen eine Funktionsstruktur der Systeme oder des wenigstens einen Systems bilden, wobei Fehler in Abhängigkeit von der Funktionsstruktur ermittelt werden und diese Fehlerabhängigkeiten bezüglich der Funktionsstruktur ausgewertet werden.

Description

Einrichtung und Verfahren zur Beurteilung und Erzielung von Sicherheit bei Systemen sowie entsprechendes Computerprogramm
Stand der Technik
Die Erfindung betrifft eine Einrichtung und ein Verfahren zur Beurteilung der Sicherheit von Systemen, insbesondere im Kraftfahrzeug, in einer frühen Phase der Produktentwicklung sowie ein entsprechendes Computerprogramm bzw. Computerprogrammprodukt gemäß der Oberbegriffe der unabhängigen Ansprüche. Das Verfahren gemäß dem Oberbegriff des unabhängigen Anspruches entsprechender Kategorie wird CARTRONIC® basierte Sicherheitsanalyse (CSA) genannt und entsprechend von der Einrichtung bzw. bei Ausführung des Computerprogrammes durchgeführt.
Die Herausforderung nicht nur der Automobilindustrie ist es, steigende Anforderungen an Sicherheit und Zuverlässigkeit bei gleichzeitig verkürzten Produktentwicklungszyklen zu erfüllen. Diese Randbedingungen machen es notwendig
Sicherheitsbetrachtungen bereits sehr früh während der Produktentwicklung zu berücksichtigen. Eine kurze Zeitspanne vom Beginn der Planung bis zur Markteinführung stellt einen entscheidenden Wettbewerbsvorteil dar, um ein Produkt vor den Mitbewerbern am Markt zu etablieren. Die Berücksichtigung einer Sicherheitsanalyse in einer frühen Phase der Produktentwicklung soll langwierige Iterationen zum Testen und Verbessern des Produkts in einer fortgeschrittenen Phase der Produktentwicklung reduzieren und im Idealfall vermeiden. In einer frühen
Entwicklungsphase ist die Betrachtungsweise eines Systems abstrakt, d.h. es ist bekannt welche Funktionen das System erfüllen soll und wie diese Funktionen interagieren. Es ist jedoch noch nicht festgelegt, wie diese Funktionen realisiert werden (z.B. Hardware, Software, Mechanik). Diese abstrakte Sichtweise kann durch das automobilhersteller- und zuliefererneutrale Strukturierungskonzept CARTRONIC® dargestellt werden. Dieses Strukturierungskonzept bildet die Grundlage für die CARTRONIC® basierte Sicherheitsanalyse. Die zunehmende Komplexität insbesondere des Systems Kraftfahrzeug liegt einerseits in der zunehmenden Komplexität und Anzahl der einzelnen Subsysteme, wird aber auch maßgeblich geprägt durch deren steigende Vernetzung. Die Beherrschbarkeit der Komplexität des Systems Kraftfahrzeug wird erreicht durch die Strukturierung der Subsysteme nach CARTRONIC® unter Berücksichtigung der Interaktionen mit anderen Subsystemen.
Das CARTRONIC® Strukturierungskonzept (siehe Bertram, T. ,- Bitzer, R. ; Mayer, R. ; Volkhart, A. ; 1998, CARTRONIC - An open architecture for networking the control Systems of an automobile, Detroit/Michigan USA, SAE 98200) basiert auf einem objektorientierten Ansatz. Das System Kraftfahrzeug wird in logische Funktionseinheiten strukturiert, die über standardisierte Schnittstellen miteinander kommunizieren.
CARTRONIC® ist ein Strukturierungskonzept für alle Steuerungs- und Regelungssysteme eines Fahrzeugs. Das Konzept enthält modulare und erweiterbare Architekturen für „Funktion" und „Sicherheit" auf der Basis vereinbarter formaler Strukturierungs- und Modellierungsregeln.
Unter einer Architektur ist hier sowohl die Strukturierungssystematik (Regeln) zu verstehen als auch deren Umsetzung in eine konkrete Struktur. Die Funktionsarchitektur umfasst sämtliche im Fahrzeug vorkommenden Steuerungs- und Regelungsaufgaben. Die Aufgaben des Systemverbunds werden sog. funktionalen Komponenten zugeordnet, die Schnittstellen der Komponenten (funktionale Schnittstellen) und ihr Zusammenwirken werden festgelegt. Die Sicherheitsarchitektur erweitert die Funktionsarchitektur um Elemente, die einen sicheren Betrieb des Systemverbunds garantieren.
Eine weitere Darstellungsform ergibt sich durch Abbildung in UML (Unified Modelling Language) , was außerdem eine Portierung auf ein Computersystem erleichtert. Die Abbildung einer CARTRONIC119- FunktionsStruktur in ein UML-Modell ist beschrieben in (Torre Flores, P. ; Läpp, A. ; Hermsen, W. ; Schirmer, J. ; Walther, M. ; Bertram, T.; Petersen, J.; 2001, Integration of a structuring concept for vehicle control Systems into the Software development process using UML modeling methods, Detroit/Michigan USA, SAE 2001-01-0066) .
Das Grundgerüst für die Strukturierung bildet die funktionale Komponente. Eine funktionale Komponente repräsentiert eine Funktion im System Kraftfahrzeug. Zu Gunsten einer kompakten Darstellung wird im folgenden anstelle des Begriffs funktionale Komponente lediglich der Begriff Komponente verwendet. Die Komponenten können im Laufe der Entwicklung verfeinert
(detailliert) werden, wobei die übergeordnete Funktion als Hülle erhalten bleibt. Die übergeordnete Funktion wird innerhalb der Verfeinerung (Detaillierung) wiederum aus Komponenten zusammengesetzt, die einzelne Teile der übergeordneten Funktion repräsentieren. Bei dem Strukturierungskonzept werden drei verschiedene Typen von Komponenten unterschieden:
□ Komponenten mit überwiegend koordinierenden und verteilenden
Aufgaben, Q Komponenten mit hauptsächlich operativen und ausführenden
Aufgaben und Q Komponenten, die ausschließlich Informationen generieren und bereitstellen.
Bei den Kommunikationsbeziehungen wird zwischen einem Auftrag (mit Rückmeldung) , einer Abfrage (mit Hinweis) und einer Anforderung unterschieden. Den Auftrag kennzeichnet die Pflicht zur Ausführung; für den Fall der Nichterfüllung muss der Auftragnehmer eine Rückmeldung an den Auftraggeber absetzen, die den Grund für die Nichtausführung beschreibt. Die Abfrage dient der Beschaffung von Informationen für eine Auftragsausführung. Für den Fall, dass eine Komponente die abgefragte Information nicht bereitstellen kann, gibt sie einen Hinweis an die fragende Komponente. Eine Anforderung beschreibt einen „Wunsch" , dass eine Funktion von einer anderen Komponente ausgeführt wird. An die Anforderung ist allerdings nicht die Pflicht zur Erfüllung gekoppelt, was beispielsweise bei konkurrierenden Anforderungen Berücksichtigung findet. Tabelle 1 stellt die Strukturelemente zusammenf ssend dar.
Tabelle 1
Figure imgf000006_0001
Figure imgf000007_0001
Die Strukturierungsregeln beschreiben erlaubte Kommunikationsbeziehungen innerhalb der Architektur des Gesamtfahrzeugs. Es werden Strukturierungsregeln unterschieden, welche die Kommunikationsbeziehungen auf der gleichen Abstraktionsebene und in höhere und tiefere Ebenen unter Berücksichtigung angegebener Randbedingungen festlegen. Ferner klären die Strukturierungsregeln die Weiterleitung von Kommunikationsbeziehungen hinein in die Detaillierung einer anderen Funktionalität.
Eine nach den Strukturierungs- und Modellierungsregeln entwickelte Struktur zeichnet sich durch folgende Merkmale aus:
□ vereinbarte, einheitliche Strukturierungs- und Modellierungsregeln auf allen Abstraktionsebenen,
□ hierarchische Auftragsflüsse,
Q hohe Eigenverantwortung der einzelnen Komponenten,
□ Bedienelemente, Sensoren und Schätzer sind gleichwertige Informationsgeber und eine
□ Kapselung, die jede Komponente für die übrigen Komponenten so sichtbar wie nötig und so unsichtbar wie möglich darstellt. Es stellt sich somit die Aufgabe ein Verfahren und eine Einrichtung sowie ein entsprechendes Computerprogramm und Computerprogrammprodukt zu generieren, welches eine verbesserte Sicherheitsanalyse und Erzeugung einer verbesserten Sicherheitsstruktur wenigstens eines Systems, insbesondere in einem Kraftfahrzeug ermöglicht.
Vorteile der Erfindung
Die Erfindung betrifft eine Einrichtung, insbesondere ein Computersystem, und ein Computerprogramm oder
Computerprogrammprodukt, sowie ein Verfahren zur Durchführung einer Sicherheitsanalyse bei Systemen, insbesondere in einem Kraftfahrzeug, wobei die Systeme oder das wenigstens eine System aus mehreren Komponenten bestehen, zwischen denen Kommunikationsbeziehungen bestehen, wobei die Komponenten und deren Kommunikationsbeziehungen eine FunktionsStruktur der Systeme oder des wenigstens einen Systems bilden, wobei vorteilhafter Weise Fehler in Abhängigkeit von ■ der FunktionsStruktur ermittelt werden und diese
Fehlerabhängigkeiten bezüglich der FunktionsStruktur ausgewertet werden .
In einer Ausführungsform zeigt die Erfindung eine Einrichtung, insbesondere ein Computersystem, und ein Computerprogramm oder Computerprogrammprodukt sowie ein Verfahren zur Erzielung einer vorgebbaren Sicherheitsstufe bei Systemen, insbesondere in einem Kraftfahrzeug, wobei die Systeme oder wenigstens ein System aus mehreren Komponenten bestehen, zwischen denen
Kommunikationsbeziehungen bestehen, wobei die Komponenten und deren Kommunikationsbeziehungen eine FunktionsStruktur der Systeme bilden, wobei Fehler in Abhängigkeit von der FunktionsStruktur ermittelt werden und diese Fehlerabhängigkeiten bezüglich der FunktionsStruktur ausgewertet werden mit folgenden Schritten:
a) Verfolgung der Fehlerabhängigkeiten in der FunktionsStruktur und Generierung von Fehlerpfaden sowie Ermittlung von globalen
Auswirkungen der Fehler, b) Bewertung der globalen Auswirkungen in Abhängigkeit vorgebbarer Sicherheitsstufen, c) Ermittlung von Fehlern, welche ein Fehlverhalten einer Komponente oder einer Kommunikationsbeziehung bewirken, d) Zuordnung des FehlVerhaltens einer Komponente oder einer Kommunikationsbeziehung zu den globalen Auswirkungen e) Ermittlung von Maßnahmen zur Fehlererkennung und/oder Fehlerbeherrschung, f) Ermittlung der erzielbaren Sicherheitsstufe und Vergleich der ermittelten Sicherheitsstufe mit der zu erzielenden Sicherheitsstufe und g) in Abhängigkeit von dem Vergleich erneuter Verfahrensstart bei a) , bis die zu erzielende Sicherheitsstufe erzielt ist.
Vorteilhafter Weise erfolgt damit die Durchführung einer Sicherheitsanalyse in einer frühen Phase der Produktentwicklung, um Problerobereiehe rechtzeitig zu erkennen und die frühzeitige Integration von Sicherheitsmaßnahmen in die FunktionsStruktur („safety through design" ) .
Die erfindungsgemäße Sicherheitsanalyse ist somit zweckmäßiger Weise auch als ein iterativer Analyse- und Verbesserungsprozess dargestellt.
Das Verfahren zur Beurteilung der Sicherheit von Systemen kann vorteilhafter Weise auf Basis von CARTRONIC®"FunktionsStrukturen bzw. von CARTRONIC^-UML-Modellen dargestellt werden, lässt sich aber auch auf andere Systemmodellierungen übertragen. Das Verfahren wird zweckmäßiger Weise mittels der CSA-Tabelle durchgeführt. Durch die CSA-Tabelle werden globale Fehlerauswirkungen identifiziert und bewertet. Sie dokumentiert Fehlerabhängigkeiten von Komponenten und
Kommunikationsbeziehungen. Ein Fehlverhalten wird dabei verursacht durch Funktionsstruktur-Fehler (FS-Fehler) in Komponenten oder Kommunikationen. Kommunikationsfehler (Aufträge, Anforderungen) werden bei der Zielkomponente der Kommunikation berücksichtigt. FS-Fehler bei Abfragen werden bei der Quellkomponente der Kommunikation berücksichtigt.
Ein Fehlverhalten der Komponenten wird den globalen Auswirkung zugeordnet. Dadurch erreicht man nicht nur eine Beurteilung globaler Zustände, sondern auch welche Komponenten der FunktionsStruktur dafür verantwortlich sind.
Das Verfahren ist in einer speziellen Ausführungsform in einen CARTRONIC® basierten Entwicklungsprozess integriert. Dadurch wird ein formales, systematisches Vorgehen gefördert.
Die Sicherheitsmaßnahmen werden insbesondere in ein CARTRONIC®- UML-Modell abgebildet. Dies ermöglicht eine formale Verifikation gegenüber festgelegten Produktanforderungen oder der Produktspezifiktion. Eine Validierung der Produktspezifikation ist bei dieser Vorgehensweise auch möglich.
Somit kann vorteilhaft die Durchführung weiterführender quantitativer Sicherheitsbetrachtungen auf Grundlage der CSA- Tabelle, der CARTRONIC®-Funktionsstruktur oder des CARTRONICΦ- UML-Modells inklusive Sicherheitsmaßnahmen erzielt werden. Weitere Vorteile und vorteilhafte Ausgestaltungen ergeben sich aus der Beschreibung und/oder den Merkmalen der Ansprüche.
Zeichnung
Die Erfindung wird nachfolgend anhand der durch die Figuren dargestellten Zeichnungen und Tabellen näher erläutert.
Dabei zeigt Figur 1 das Verfahren bzw. die Vorgehensweise bei der Sicherheitsanlayse.
Figur 2 zeigt die CARTRONIC®-FunktionsStruktur eines beispielhaft betrachteten Bremssystems .
Figur 3 stellt ein Beispiel für eine UML-Modellierung der CARTRONlC-Funktionsstruktur nach Figur 2 dar.
Figur 4 zeigt den Tabellenkopf der CSA-Tabelle mit den globalen Auswirkungen dar .
Figur 5 zeigt die Zuordnung der Fehlerauswirkungen zu den Sicherheitsstufen in einem Flußgraphen.
Figur 6 zeigt beispielhaft eine Bewertung der globalen Auswirkungen .
Figur 7 zeigt die Fehlerfortpflanzung in der FunktionsStruktur bzw. die Zuordnung von FS-Fehlern zu den globalen Auswirkungen. Figur 8 bestehend aus den Einzelfiguren 8a, 8b, 8c und 8d zeigt die CSA-Tabelle, also die Sicherheitstabelle, gemäß dem Beispiel nach Figur 2 mit den entsprechenden Kennzeichen.
Figur 9 zeigt die Einordnung der CSA in einen Entwicklungsprozess , insbesondere nach V-Modell
Beschreibung der Ausführungsbeispiele
Die im folgenden beschriebene Sicherheitsanalyse beruht auf der CARTRONIC®-FunktionsStruktur bzw. dem CARTRONIC®-UML-Modell des betrachteten Systems. Das CARTRONIC®-UML-Modell ist die Abbildung einer CARTRONIC®-FunktionsStruktur in die UML (Unified modeling language) . Durch die Abbildung in die UML erhält man eine formalisierte und genauer spezifizierte Darstellung, welche eine automatisierte Realisierung der Erfindung erleichtert. Die Abbildung einer CARTRONIC®-Funktionsstruktur in ein UML-Modell ist beschrieben in (Torre Flores, P. ; L pp, A. ; Hermsen, W. ; Schirmer, J.; Walther, M. ; Bertram, T.; Petersen, J.; 2001, Integration of a structuring concept for vehicle control Systems into the Software development process using UML modeling methods, Detroit/Michigan USA, SAE 2001-01-0066) .
Die CARTRONIC® basierte Sicherheitsanalyse ist ein Verfahren zur systematischen Sicherheitsanalyse auf abstrakter Systemebene und unterstützt somit das Entwicklungskredo „safety through design" . Die in einer früheren Veröffentlichung beschriebene Vorgehensweise zur CARTRONIC® basierten Sicherheitsanalyse (Bertram, T.; Dominke, P . ; Müller, B., 1999, The Safety-Related Aspect of CARTRONIC, Detroit/Michigan USA, SAE' 99, Session Code PC 26) wird grundlegend überarbeitet und erweitert um die Analyse struktureller Fehlerabhängigkeiten. Durch die Verwendung des Verfahrens in einer frühen Entwicklungsphase können Fehler und deren Ursachen abstrakt beschrieben werden, z.B. „Fehler vorhanden" oder „Fehler nicht vorhanden" . Das Verfahren stellt somit eine Abstraktion der FMEA (Failure Mode and Effects Analysis oder Fehler-Möglichkeits- und Einfluß-Analyse) dar, welches erweitert ist um die Analyse struktureller
Fehlerabhängigkeiten. Die FMEA ist dabei ein anerkanntes methodisches Verfahren zur Analyse, Bewertung und Dokumentation von Systemen, Bauteilen und Herstellungsprozessen und dient vornehmlich der Fehlervermeidung. Die Intention der CSA ist nicht eine FMEA zu ersetzen, sondern lediglich in einer frühen Entwicklungsphase die Systementwickler bei der Identifikation von potentiellen Gefahrenstellen zu unterstützen.
Zunächst werden wichtige Begriffe definiert, bevor die Erfindung dann anhand eines Beispiels erläutert wird.
Definition 1 (globale Auswirkungen)
Globale Auswirkungen sind physikalische Effekte, die sich durch Aktuatoren auf das Gesamtsystem Kraftfahrzeug auswirken. Sie werden von Sensorik (oder auch einem Fahrzeugführer) bemerkt durch FunktionsVerlust (z.B.
Versagen des Bremssystems) oder Komforteinbuße (z.B. durch Abschaltung von AssistenzSystemen wie beispielsweise Adaptive Cruise Control) .
Definition 2 (Funktionsstruktur-Fehler) Funktionsstruktur-Fehler (FS-Fehler) sind Fehler, die ein
Fehlverhalten einer Komponente oder einer Kommunikation bewirken.
Definition 3 (Funktionsstruktur-Fehler-Ursachen)
Funktionsstruktur-Fehler-Ursachen (FS-Fehler-Ursachen) sind Gründe für ein Fehlverhalten einer Komponente. Der Grund für ein Fehlverhalten einer Komponente liegt im Vorhandensein von FS-Fehlern. FS-Fehler können weiter unterteilt werden in verfeinerte Fehlerarten. Die verfeinerten Fehlerarten sind dann wiederum die Ursache für die FS-Fehler. Die verfeinerten Fehlerarten können sein:
Komponentenfehler :
Komponente tot
Komponente berechnet falsche Werte
Komponente ist unkontrolliert aktiv
Komponente generiert Ergebnis zur falschen Zeit
Kommunikationsfehler :
Kommunikation unterbrochen
Kommunikation liefert falsche Information
Kommunikation ist unkontrolliert aktiv
Kommunikation liefert Information zur falschen Zeit
Kommunikation ist fehlgeleitet
Figur 1 zeigt die Vorgehensweise der CARTRONIC® basierten Sicherheitsanalyse. Das Verfahren kann folgendermaßen gegliedert werden:
Schritt 1: Globale Auswirkungen identifizieren auf Basis der CARTRONIC®-Funktionsstruktur bzw. des
CARTRONIC®-UML-Modells Schritt 2 : Globale Auswirkungen bewerten durch
Sicherheitsstufen (SL) Schritt 3: Analyse von FS-Fehler-Ursachen (vgl. Defini tion
3) , d.h. Fehler von Komponenten oder
Kommunikationsbeziehungen analysieren Schritt 4: Zuordnung eines Fehlverhaltens einer Komponente zu den globalen Auswirkungen Schritt 5: Maßnahmen zur Fehlererkennung und/oder
Beherrschung ermitteln Schritt 6: Erstellung bzw. Ergänzung einer CARTRONIC®-
Sicherheitsstruktur Schritt 7 : Verifikation der resultieren Funktions- und
Sicherheitsstruktur unter Sicherheitsaspekten Im folgenden wird die Vorgehensweise der CARTRONIC® basierten Sicherheitsanalyse anhand eines Beispiels beschriebenen. Als Beispiel wurde ein vereinfachtes Bremssystem gewählt. Die CARTRONIC®-Funktionsstruktur und das CARTRONIC®-UML Modell des vereinfachten Bremssystems ist in Figur 2 und Figur 3 dargestellt. Das Beispielsystem besteht aus den Komponenten Momentenverteiler , Vortrieb, Bremssystem,
Bremssystemkoordinator, Bremsaktuator und Bremslicht . In der logischen, hierarchischen Funktionsstruktur von CARTRONIC® befinden sich die Komponenten Bremssystemkoordinator und Bremsaktuator in der Detaillierung des Bremssystems. Die Komponenten N02r1e.n e.nverteiler, Vortrieb und Bremssystem sind Detaillierungen von Vortrieb und Bremse . In der Funktionsstruktur ist Vortrieb und Bremse eine Detaillierung der Fahrzeugbewegung. Die Komponente Bremslicht befindet sich in der Detaillierung von Licht und Lichtzeichen, das eine Detaillierung von Außenbeleuchtung ist. Diese ist wiederum eine Verfeinerung der Komponente Sichtbarkeit und Signalisierung in Karosserie und Innenraum. Die Detaillierungen von Fahrzeugbewegung und Karosserie und Innenraum sind in der Fahrzeugebene platziert. Die Fahrzeugebene ist die oberste Ebene der CARTRONIC®- FunktionsStruktur. Der Momentenverteiler ist dafür zuständig die Momentenwünsche des Fahrzeugführers zu verteilen. Die Komponenten Bremssystemkoordinator und Vortrieb fordern Momente beim Momentenverteiler über die Kommunikationen Rl und R2 an. Liegt nur eine Anforderung vom Vortrieb vor, so fragt der Momentenverteiler minimal und maximal zulässige Momentenwerte von der Komponente Vortrieb durch die Kommunikation II ab und sorgt dann für die Umsetzung durch den Auftrag 02. Liegt nur eine Anforderung vom Bremssystem vor, dann wird diese durch den Auftrag 01 realisiert. Liegen Anforderungen von Vortrieb und Bremssystem vor, so hat das Bremssystem Vorrang. Die Komponente Bremssystemkoordinator in der Detaillierung des Bremssystems sorgt durch den Auftrag 03 an den Bremsaktuator für die Umsetzung der Momente und mit der Anforderung R3 für die Ansteuerung des Bremslichts , damit wird der Fahrerwunsch nachfolgenden Fahrzeugen signalisiert.
Die Erkenntnisse der CARTRONIC® basierten Sicherheitsanalyse werden in Form einer Tabelle, der CSA-Tabelle, übersichtlicht zusammengefasst und gespeichert.
Durch die CSA-Tabelle erreicht man eine Zuordnung von einem Fehlverhalten einer einzelnen Komponente zu Fehlerabhängigkeiten innerhalb der Funktionsstruktur. Die in der CSA-Tabelle dokumentierten FS-Fehler können zu den oben angegebenen
Fehlerarten verfeinert werden. Die verfeinerten Fehlerarten sind auf abstrakter Systemebene interpretierbar als Ursache für die FS-Fehler. Des weiteren werden die „internen Auswirkungen" (Fehlverhalten einer Komponente) den globalen Auswirkungen zugeordnet. Hierdurch werden komplexe Abhängigkeiten zwischen
Strukturinternen Fehlerabhängigkeiten und globalen Auswirkungen erkennbar .
Das im folgenden beschriebene Verfahren stellt bzgl . der Ursachenanalyse einen „bottom-up" -Ansatz dar, da ausgehend von einem potentiellen Fehlverhalten die möglichen Ursachen dafür identifiziert werden. Die Vorgehensweise wird nun anhand des oben erläuterten Beispiels und der bereits dargestellten Schritte 1-7 erklärt:
Schritt 1 : Globale Auswirkungen identifizieren
Globale Auswirkungen ergeben sich bei Betrachtung der Systemschnittstelle zur Umgebung. Die Aktuatoren, welche von dem betrachteten Subsystem angesteuert werden, repräsentieren die Schnittstellen zur Umgebung. In dem hier betrachteten Kontext bedeutet Umgebung das Kraftfahrzeug als Ganzes. Die Aktuatoren für das in Figur 2 und Figur 3 dargestellte Beispielsystem sind das Bremssystem bzw. in der Detaillierung der Bremsaktuator, der Vortrieb und das Bremslicht . Es werden lediglich solche globalen Auswirkung betrachtet und z.B. in einem ComputerSystem erfaßt, die von dem zu untersuchenden Subsystem zu verantworten sind. So ist es z.B. nicht sinnvoll das Adaptive Cruise Control (ACC) Subsystem, welches das Bremssystem ansteuert, für einen
Totalverlust der Bremswirkung verantwortlich zu machen. Diese Zusammenhänge sind mittels Zuordnungstabellen oder Expertensystemen erfassbar und werden im Verfahrensverlauf durch das ComputerSystem zugreifbar zur Verfügung gestellt. Bei iterativem Vorgehen können dann je nach Iterationsvorgang unterschiedliche Zusammenhänge in oben dargestellter Form Anwendung finden. Dies gilt auch für das weitere Vorgehen wie nachfolgend beschrieben.
Für das in Figur 2 dargestellte Beispiel können beispielsweise die nachfolgenden globalen Auswirkungen identifiziert werden: Q Beschleunigungswirkung - Vortrieb
• Unkontrollierte Beschleunigung o Beschleunigung zu stark o Beschleunigung zu schwach
• Keine Beschleunigung
□ Bremswirkung -^ Bremsaktuator
• Keine Bremswirkung
• Zu geringe Bremswirkung
□ Signalisierung -> Bremslicht
• Keine Anzeige
• Kontinuierliche Anzeige (enthält Szenario Bremslicht leuchtet, obwohl nicht gebremst wird)
In Figur 4 ist der Tabellenkopf mit den globalen Auswirkungen der CSA-Tabelle dargestellt.
Schritt 2 : Globale Auswirkungen bewerten durch Sicherheitsstufen Die Bewertung der globalen Auswirkungen erfolgt in Anlehnung an die Anforderungsklassen, die in der DIN V 19250 definiert sind. Die Anforderungsklassen in der Norm sind allgemein für MSR- Schutzeinrichtungen (MSR - Messen, Steuern, Regeln) definiert. Die Voraussetzungen, die dort festgelegt sind, lassen sich nicht direkt auf Kraftfahrzeuge übertragen. In dieser Norm fließen die Punkte
□ Aufenthaltsdauer im Gefahrenbereich
□ eine oder mehrere Personen sind von den potentiellen Auswirkungen eines Fehlers betroffen in die Bewertung ein. Bei Kraftfahrzeugen ist die Berücksichtigung dieser Fälle hingegen nicht sinnvoll. Sie sind unter der Prämisse zu betrachten, dass beim Betrieb bestimmter Maschinen eine Person, welche die Maschine bedient, diese von einem Prüfstand aus betätigt und nur unter bestimmten Voraussetzungen für eine begrenzte Zeitdauer, z.B. bei Wartungsarbeiten, einer potentiellen Gefahr ausgesetzt ist. Im Kraftf hrzeug ist man hingegen ständig einer potentiellen Gefahr ausgesetzt. Außerdem können immer mehrere Personen von den Auswirkungen eines Fehlers betroffen sein. Bei Beachtung dieser
Einwendungen kommt man zu angepassten „Anforderungsklassen" für Automobile, die im Rahmen der CSA als Sicherheitsstufen (engl. safety level - SL) bezeichnet werden. Die Zuordnung der Sicherheitsstufen zu Fehlerauswirkungen ist in dem Risikograph von Figur 5 dargestellt.
Es wird unterschieden, ob eine Auswirkung im Einzelfall oder im Regelfall auftritt. Im Einzelfall bedeutet, dass in der überwiegenden Mehrheit der Fälle nicht mit der entsprechenden Auswirkung gerechnet werden muss. Den Sicherheitsstufen können Ereignishäufigkeiten zugeordnet werden. Eine solche
Ereignishäufigkeit ist als Sollgröße zu verstehen, die von der späteren Realisierung einer Komponente mindestens zu erfüllen ist. Eine a priori Verifikation der Ereignishäufigkeiten ist in der Regel nicht möglich, da verlässliche Daten oft erst nach einem Serieneinsatz zur Verfügung stehen. Es ist jedoch möglich den mit einer Sicherheitsstufe verbundenen Sollwert der Ereignishäufigkeit nachträglich mit einem erfassten Istwert zu vergleichen. Tritt hierbei eine Abweichung auf, d.h. ist die tatsächlich ermittelte Ereignishäufigkeit größer, als die zulässige Ereignishäufigkeit einer Sicherheitsstufe, so müssen
Maßnahmen zur Reduktion der Ereignishäufigkeit getroffen werden.
In Figur 6 ist die Bewertung der globalen Auswirkungen des Bremssystems durch Sicherheitsstufen abgebildet. Ein Bremssystem ist eine äußerst wichtige Funktionalität eines Kraftfahrzeugs, die unter allen Umständen gewährleistet sein muss. Die globale Auswirkung „keine Bremswirkung" stellt im Regelfall eine Bedrohung für Leib und Leben dar, die vom Fahrzeugführer nicht beherrschbar ist. Deshalb muss hier die Sicherheitsstufe SL4 vergeben werden. Für die Auswirkung „keine Beschleunigung" wird die Sicherheitsstufe SLl vergeben, weil hier im Regelfall davon ausgegangen werden kann, dass mit maximal leichten Verletzungen zu rechnen ist, z.B. durch Auffahrunfälle mit geringer Geschwindigkeitsdifferenz. In Einzelfällen kann eine Gefahr für Leib und Leben bestehen, die jedoch beherrschbar ist, z.B. einschalten der Warnblinkanlage.
Um im folgenden eine übersichtliche Darstellung zu erhalten wird auf die Verfeinerung der Tabellenspalte „Unkontrollierte Beschleunigung" verzichtet.
Schritt 3 : Funktionsstruktur-Fehler-Ursachenanalyse
Bei der Ursachenanalyse wird die Frage gestellt: Was verursacht ein Fehlverhalten einer Komponente {Momentenverteiler, Vortrieb, Bremssystem, Bremssystemkoordinator, Bremsaktuator, Bremslicht}?
Die Ursachenanalyse untersucht, wodurch ein Fehlverhalten der CARTRONIC®-Komponenten {Momentenverteiler, Vortrieb, Bremssystem, Bremssystemkoordinator, Bremsaktuator, Bremslicht} bedingt sein könnte. Untersucht wird ein Fehlverhalten von Komponenten und ihren Detaillierungen, soweit diese bekannt sind. Zur Ursachenanalyse wird die CARTRONIC®-Funktionsstruktur des betrachteten Systems in die Kopfzeile „FunktionsStruktur" der CSA-Tabelle übernommen. Außerdem wird die CARTRONIC®- Funktionsstruktur in die Spalte „Fehlverhalten Komponenten" übernommen, (siehe Figur 7).
Falls ein FS-Fehler in einer Komponente ein Fehlverhalten in der selben Komponente verursacht erfolgt die Zuordnung der Komponente aus der FunktionsStruktur zu einem Fehlverhalten der selben Komponente (Kennzeichnung mit „x" , vgl. Figur 7) .
Zusätzlich werden auch für die Komponente relevante FS-Fehler der Kommunikationsbeziehungen berücksichtigt. Verursacht ein FS- Fehler einer Kommunikationsbeziehung ein Fehlverhalten, so erfolgt ebenfalls eine Zuordnung zur FunktionsStruktur, welche die Art und den Namen der betrachteten Kommunikation wiedergibt. Die Art der Kommunikationsbeziehung wird mit dem großgeschriebenen Anfangsbuchstaben des englischen Ausdrucks der Kommunikation bezeichnet. Folglich wird für einen Auftrag (engl. Order) ein „0" , für eine Anforderung (engl. Request) ein „R" und für eine Abfrage (engl. Inquiry) ein „I" verwendet. Der Art der Kommunikation folgt ein Unterstrich „_" , dem sich der Name der Kommunikationsbeziehung anschließt (z.B. I_I1) .
Bei der Ursachenanalyse für ein Fehl^erhalten einer Komponente wird die Q Komponente selbst, sowie
□ ankommende Aufträge
□ ankommende Anforderungen Q abgehende Abfragen betrachtet . Im weiteren Verlauf werden die Fehlerabhängigkeiten untersucht. Es wird somit ermittelt, welche weiteren Komponenten und Kommunikationen für ein Fehlverhalten der betrachteten Komponente verantwortlich sein können. Hierfür werden die in der Spalte M einer Komponente stehende (n) Kommunikation (en) zurückverfolgt und die neu gefundene (n) Komponente (n) in der selben Zeile dem Komponentenfehlverhalten zugeordnet. Eine der neu gefundenen Komponenten dient als neuer Ausgangspunkt. Die dieser Komponente zugeordnete (n) Kommunikation (en) werden ermittelt und in der Spalte M der entsprechenden Komponente aufgenommen. Es werden wiederum die dieser Komponente zugeordneten Kommunikationen zurückverfolgt. Damit werden neue Ausgangskomponenten gefunden. Dieser Vorgang wird so lange iterativ fortgeführt, bis keine weiteren Kommunikationen vorhanden sind bzw. alle erreichbaren Komponenten durchlaufen wurden (vgl. nachfolgendes Beispiel und Figur 8).
Beispiel:
Ein Fehlverhalten der Komponente Momentenverteiler (fc.^ hat die Ursache darin, dass ein Komponentenfehler in der Komponente Momentenverteiler (fc1) selbst, ein
Kommunikationsfehler in der Abfrage II oder der Anforderung Rl oder der Anforderung R2 , ein Komponentenfehler in der Komponente Vortrieb (fc3) oder ein Kommunikationsfehler im Auftrag 02 bzw. ein Komponentenfehler in der Komponente
Bremssystemkoordinator (fc21) oder im Auftrag 01 aufgetreten ist.
Ein Fehlverhalten der Komponente Bremssystem (fc2) hat die
Ursache darin, dass entweder ein Komponentenfehler in dem Bremssystem (fc2) selbst vorliegt oder ein
Kommunikationsfehler im Auftrag 01 oder ein Komponentenfehler im Momentenverteiler (fc mit den hier zu berücksichtigenden potentiellen Kommunikationsfehlern Anforderung Rl , Anforderung R2 und Abfrage II oder ein Fehler in der Komponente Vortrieb (fc 3) oder ein Kommunikationsfehler im Auftrag 02 aufgetreten ist .
Die Einträge in der CSA-Tabelle für das in Figur 2 dargestellte Beispiel, sind aus Figur 8, insbesondere Figur 8a, ersichtlich.
Wird ein Fehlverhalten einer Komponente in der Verfeinerung betrachtet, so ist die Hülle für die Ursachenanalyse nicht von Interesse, da nur Kommunikationsbeziehungen von der höheren Ebene in die' Verfeinerung weitergeleitet werden. Die Spalte Bremssystem (Bremssystem (fc2) ist Hülle von Bremssystemkoordinator und Bremsaktuator) der „FunktionsStruktur" muss für die Ursachenanalyse eines
Fehlverhaltens der Komponente Bremssystemkoordinator (Zeile Bremssystemkoordinator (fc21) in der Spalte „Fehlverhalten Komponenten" ) nicht berücksichtigt werden. Bei der Ursachenanalyse eines FehlVerhaltens der Komponente Bremslicht ist es nicht notwendig die Analyse für die Komponente Bremssystem durchzuführen, falls die Analyse für die Verfeinerung der Komponente Bremssystem durchgeführt wurde. Mögliche Ursachen werden bei der Betrachtung der Verfeinerung (Bremssystemkoordinator und Bremsaktuator) bereits berücksichtigt.
Die CSA Tabelle erlaubt somit eine Verfolgung von logischen Fehlerabhängigkeiten. Die Spalten der FunktionsStruktur mit vielen Einträgen z.B. Spalte Momentenverteiler (fcx) und Spalte Vortrieb (fc3) sind wichtige Komponenten, da sich dort ein Fehler auf große Teile des Systems auswirkt.
Schritt 4: Zuordnung eines FehlVerhaltens einer Komponente zu den globalen Auswirkungen
Zunächst werden also die in Schritt 1 identifizierten globalen Auswirken den Komponenten zugeordnet, deren Fehlverhalten eine globale Auswirkung verursacht. Diese Komponenten sind die System-Schnittstellen (siehe Schritt 1) .
Unter Schritt 1 ist diese Zuordnung bereits dargestellt.
□ Beschleunigungswirkung -> Fehlverhalten Vortrieb Q Bremswirkung -> Fehlverhalten Bremsaktuator
Q Signalisierung -> Fehlverhalten Bremslicht
Diese Zuordnung in der CSA-Tabelle ist aus Figur 8b ersichtlich. Durch die Fehlerabhängigkeiten, die in Schritt 3 ermittelt wurden, erhält man eine Zuordnung der übrigen Komponenten zu den globalen Auswirkungen. Dies erreicht man durch Betrachtung der Spalten der FunktionsStruktur für die Zeilen der Syste - Schnittstellen (Fehlverhalten der Komponenten Bremsaktuator (fc22) , Vortrieb (fc3) und Bremslicht (fc4) ) . Jede Spalte der FunktionsStruktur, die einem Fehlverhalten der System- Schnittstellen zugeordnet ist, d.h. mit einem „x" gekennzeichnet ist, kann die selben globalen Auswirkungen verursachen. Der Hülle einer Detaillierung werden alle globalen Auswirkungen zugeteilt, die den Komponenten der Detaillierung zugeordnet sind. Das Resultat dieses Schrittes ist in Figur 8c dargestellt .
Beispiel: Im folgenden wird die Komponente Momentenverteiler (fcα) in der FunktionsStruktur betrachtet. Die Komponente Nomentenverteiler (fCj) in der Funktionsstruktur ist der Zeile Fehlverhalten Bremsaktuator (fc22) zugeordnet, d.h. ein FS- Fehler in der Komponente Momentenverteiler kann ein Fehlverhalten des Brems aktuators verursachen. Daraus kann gefolgert werden, dass ein Fehlverhalten der Komponente Momentenverteiler auch die globalen Auswirkungen des Brems aktuators verursachen kann. Die globalen Auswirkungen eines Fehlverhaltens des Bremsaktuators („keine Bremswirkung" und „zu geringe Bremswirkung" ) werden somit auch dem
Fehlverhalten des Momentenverteilers zugeordnet. Außerdem kann ein FS-Fehler in der Komponente Momentenverteiler (fcx) ein Fehlverhalten des Vortriebs (fc3) verursachen. Ein Fehlverhalten der Komponente Momentenverteiler kann somit auch die globalen Auswirkungen „unkontrollierte Beschleunigung" und „keine Beschleunigung" bewirken. Ein FS-Fehler in der Komponente Momentenverteiler (fcχ) kann ein Fehlverhalten des Bremslichts (fc4) verursachen. Somit kann ein Fehlverhalten der Komponente Momentenverteiler die globalen Auswirkungen „keine Anzeige" und „kontinuierliche Anzeige" verursachen. Ein Fehlverhalten des Bremssystems (fc2) als Hülle der Komponenten Bremssystemkoordinator (fc2X) und Bremsaktuator (fc22) kann die globalen Auswirkungen aller seiner Komponenten in der Detaillierung verursachen.
Schritt 4.1: Sicherheitsstufen einem Fehlverhalten von Komponenten zuordnen
Der Maximalwert der Sicherheitsstufe der globalen Auswirkungen, der in einer Zeile einem Fehlverhalten zugeordnet ist wird in das entsprechende Element der Spalte SL eingetragen. Die Vorgehensweise ist in Figur 8d verdeutlicht.
Schritt 5 : Maßnahmen zur Fehlererkennung und/oder Beherrschung
Die folgenden beiden Tabellen enthalten Maßnahmen zur Fehlererkennung und Beherrschung für Komponenten (Tabelle 2) und Kommunikationsbeziehungen (Tabelle 3).
Tabelle 2 : Zusammenstellung von Maßnahmen zur Fehlererkennung und Beherrschung für funktionale Komponenten.
Figure imgf000025_0001
Tabelle 3 : Zusammenstellung von Maßnahmen zur Fehlererkennung und Beherrschung für Kommunikationsbeziehungen
Figure imgf000026_0001
Figure imgf000027_0001
Maßnahmen zur Fehlererkennung und/oder Fehlerbeherrschung auf einer hohen Abstraktionsebene anzugeben gestaltet sich schwierig, falls noch keine konkrete Systemrealisierung vorhanden ist. Für viele abstrakte Fehler in der CSA-Tabelle lassen sich nur dann wirksame und wirtschaftlich sinnvolle
Maßnahmen zur Fehlererkennung und -beherrschung angeben, wenn diese realisierungsabhängig angegeben werden, d.h. für eine konkrete Systemtopologie. Bei realisierungsunabhängiger Betrachtung gibt es ansonsten zu viele Möglichkeiten, die auf abstrakter Ebene zur Lösung angegeben werden können (vgl.
Tabelle 2 und Tabelle 3) . Die Maßnahmen geben Möglichkeiten zur Erkennung und Beherrschung der abstrakten Ursachen an. Diese abstrakten Ursachen können als Fehler-Modi (Fehlerarten) der allgemeineren FS-Fehler verstanden werden (vgl. Definition 3). Auf hoher Abstraktionsebene lassen sich Maßnahmen angeben, die schon in einer frühen Entwicklungsphase offensichtlich sind.
Dazu zählen Maßnahmen, welche die Fehlerausbreitung verhindern oder auf Plausibilität basieren. So kann offensichtlich sein, dass ein Signal nur innerhalb bestimmter Grenzwerte liegen darf. Fehlerausbreitung kann durch Redundanz eingegrenzt werden.
Redundante Strukturen können in späteren Entwicklungsphasen, d.h. bei detaillierter Kenntnis der realisierten Topologie in kostengünstige Maßnahmen umgewandelt werden. Ein Beispiel hierfür sind Codes zur Fehlererkennung und -korrektur. Die klartextlichen Angaben der Tabellen sind im Programm bzw.
Computersystem durch Kodierungen verkürzbar und zuordenbar.
Eine optimale Lösung technischer und wirtschaftlicher Art kann erst dann gefunden werden, wenn man einen Fehler innerhalb einer bekannten Topologie betrachtet . Wird für eine Abfrage die Ursache „ liefert falsche Information" als kritisch identifiziert, so hängt die zu treffende Maßnahme sehr stark davon ab, wie die Abfrage realisiert ist. Wird der Wert innerhalb eines Prozessorsystems abgefragt (z.B. interner Speicher), so ist evtl. keine Maßnahme zu treffen (eigensicher) bzw. man kann das Prozessorsystem als gesamte Einheit betrachten und somit eine Vielzahl von Operationen mit einer einzigen Maßnahme überwachen, z.B. Watchdog-Timer . Läuft die Kommunikation über eine externe Verbindung (Kabel, Bussystem) , so muss die Verbindung/Nachrichtenübertragung eventuell redundant ausgelegt werden. Bei EMV Problemen genügt es ggf. schon, wenn man eine Verbindung über ein geschirmtes Kabel ohne jeglichen zusätzlichen elektronischen Aufwand gewährleisten kann.
Schritt 6: CARTRONIC® - Sicherheitsstruktur
Die CARTRONIC®-Darstellung eines Systems (dargestellt für ein Beispiel in Figur 2) kann abgebildet werden in ein CARTRONIC81- UML Modell (Figur 3) . Dies erlaubt eine formalere Systemspezifikation als CARTRONIC®. Außerdem ist UML eine international genormte Sprache. Für die Beschreibung einer Systemtopologie ist es jedoch erforderlich das bestehende CARTRONIC®-UML Modell zu erweitern. Die Erweiterung muss die Abbildung der Maßnahmen zur Fehlererkennung und -beherrschung, die Partitionierung der Funktionen auf Steuergeräte und die Darstellung von zeitlichen und logischen Abläufen umfassen. Die erweiterte Struktur kann zur Dokumentation der verwendeten Sicherheitsmaßnahmen verwendet werden. Eine Darstellung, in welcher Struktur, Funktionalität und Topologie enthalten sind, ist auch geeignet für zukünftige quantitative Systemanalysen, insbesondere zur automatisierten Durchführung.
Schritt 7: Verifikation
Bei der Verifikation wird überprüft, ob die Resultate der CARTRONIC® basierten Sicherheitsanalyse dazu führen, dass eine Produktspezifikation erfüllt wird. Es wird untersucht, ob die vergebenen Sicherheitsstufen den Anforderungen der Spezifikation entsprechen, ob also die zu erzielenden Sicherheitsstufen mit vorgebbaren und somit zu erzielenden übereinstimmen. Ist dies nicht der Fall, so kann eine weitere Iteration der CARTRONIC® basierten Sicherheitsanalyse durchlaufen werden. Dieser iterative Verbesserungsprozess wird so lange fortgeführt, bis alle Anforderung der Spezifikation bzw. der vorgegeben Sicherheitsstufen erfüllt sind.
In Figur 12 ist die Einordnung der CSA in einen Entwicklungsprozess dargestellt. Der verwendete Entwicklungsprozess orientiert sich am V-Modell. Das V-Modell ist ein Entwicklungsstandard des Bundes für IT-Systeme. Es ist möglich das V-Modell projektspezifisch an gegebene Randbedingungen anzupassen. Dieser Vorgang wird als Tailoring bezeichnet. Im V-Modell werden Tätigkeiten (Aktivitäten) und ihre Produkte festgelegt. Das für den CARTRONIC® basierten Entwicklungsprozess angepasste inkrementelle, iterative V-Modell (UV-Modell) wird auf den drei Ebenen Systemebene, Subsystemebene und Teilrealisierungsebene angewendet. Die Navigation im IIV-Modell erfolgt entlang der eingezeichneten Pfeile. Es ist möglich von der linken auf die rechte Seite einer Ebene des V-Modells (Testfälle) und zurück (Iterationen) zu gelangen. Zwischen den Ebenen sind auch mehrere Inkremente möglich. Auf der Teilrealisierungsebene kann beispielsweise erkannt werden, dass zusätzliche Funktionen für eine Realisierung benötigt werden. Es kann dann ein zusätzliches Inkrement durchlaufen werden indem auf der Subsystemebene die Funktionen und ihre Interaktionen eingeführt werden und diese dann ihrerseits auf der Teilrealisierungsebene realisiert werden. Auf der Systemebene wird das Kraftfahrzeug als Ganzes betrachtet. Die Subsystemebene detailliert das Gesamtsystem Kraftfahrzeug in Teilsysteme. Diese Teilsysteme können beispielsweise die Motorsteuerung, das Bremssystem, das Getriebe oder ein Adaptive Cruise Control sein. Die Subsystemebene stellt die Teilsysteme des Kraftf hrzeugs noch realisierungsunabhängig dar, d.h. es wird lediglich die Funktionalität nicht jedoch die technische Realisierung betrachtet. Auf der
Teilrealisierungsebene wird jedes Subsystem weiter detailliert. Es wird eine Entscheidung über eine Topologie getroffen und ob eine Funktion als Software, Computer Hardware, Hydraulik, Elektronik, Elektrik, Mechanik etc. realisiert wird. Anschließend wird ein entsprechendes Subsystem erstellt und gegebenenfalls die Software implementiert. Auf jeder Ebene des IIV-Modells wird auf der linken Seite des V-Modells eine Anforderungsanalyse durchgeführt und ein Entwurf angefertigt . Die rechte Seite des IIV-Modells dient der Integration und der Verifikation des auf der entsprechenden Ebene erstellten Entwurfs. Auf der Systemebene kann zusätzlich zu den beschriebenen Vorgängen eine Validation durchgeführt werden. Eine Validation prüft, ob die Systemspezifikation die an sie gestellten Anforderungen erfüllt. Die Verifikation hingegen überprüft ein Produkt gegenüber der Spezifikation. Die Vorgehensschritte Schritt 1 bis Schritt 5 werden in der
Analysephase der Subsystemebene durchgeführt. Schritt 6 wird in der Entwurfsphase der Subsystemebene umgesetzt. Aufgrund der Überlegungen in Schritt 5, nämlich dass eine Konkretisierung von Maßnahmen zur Fehlererkennung und Beherrschung häufig erst bei bekannter Systemtopologie sinnvoll ist, empfiehlt sich eine
Detaillierung der Sicherheitsmaßnahmen in Schritt 5 und Schritt 6 auf der Teilrealisierungsebene durchzuführen. In dieser Phase wird die Systemtopologie, d.h. die Partitionierung der Funktionalitäten auf Steuergeräte vorgenommen und die Funktionsrealisierungen festgelegt. Die CSA, wie sie hier beschrieben ist, wird also hauptsächlich auf der Subsystemebene angewendet. Es ist jedoch vorteilhaft die CSA auch auf der Teilrealisierungsebene fortzuführen. Hier wird eine Anforderungsanalyse durchgeführt, wie Sicherheitsmaßnahmen in Abhängigkeit der Topologie und der Realisierung des Teilsystems zu gestalten sind und ein entsprechender Entwurf angefertigt. Dieser Entwurf und seine Integration können auf der rechten Seite des IIV-Modells verifiziert werden. Die gezeigte Erfindung kann automatisiert auf einem ComputerSystem ablaufen. Dazu sind die einzelnen Schritte oder Teile dieser Schritte ebenso wie die Tabellen als Computerprogramm mit Daten und Befehlen darstellbar, so dass die Schritte 1 bis 7 als Programmcode abgespeichert werden können und in einer Einrichtung insbesondere einem Computersystem zur Ausführung gelangen um ein erfindungsgemäßes Verfahren auszuführen. Als Speicher bzw. Datenträger kann hierbei jede denkbare Form gelten wie z.B. CD-ROM, DVD, Diskette, EPROM, FlashEPROM, ROM, RAM, usw. wodurch ein Computerprogrammprodukt in Verbindung mit dem Computerprogramm vorliegt. Insbesondere eine Übertragung des Programms via Netzwerken wie Internet von einem Speicher zu einem anderen Speicher bzw. Netzwerkteilnehmer fällt ebenfalls darunter.

Claims

Ansprüche
1. Verfahren zur Durchführung einer Sicherheitsanalyse bei Systemen, insbesondere in einem Kraftfahrzeug, wobei die Systeme oder das wenigstens eine System aus mehreren Komponenten bestehen, zwischen denen Kommunikationsbeziehungen bestehen, wobei die Komponenten und deren Kommunikationsbeziehungen eine Funktionsstruktur der Systeme oder des wenigstens einen Systems bilden, dadurch gekennzeichnet, dass Fehler in Abhängigkeit von der FunktionsStruktur ermittelt werden und diese Fehlerabhängigkeiten bezüglich der FunktionsStruktur ausgewertet werden .
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Fehlerabhängigkeiten in der Funktionsstruktur nachverfolgt werden, wodurch Fehlerpfade generiert werden, wobei globale
Auswirkungen der Fehler als Abschluß der Fehlerpfade ermittelt werden .
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Fehlerabhängigkeiten in der FunktionsStruktur nachverfolgt werden, wodurch Fehlerpfade generiert werden, wobei globale Auswirkungen der Fehler als Abschluß der Fehlerpfade ermittelt und bewertet werden.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die globalen Auswirkungen durch Ermittlung wenigstens einer Sicherheitsstufe bewertet werden.
5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zusätzlich zu den Fehlerabhängigkeiten bezüglich der Funktionsstruktur Fehler ermittelt werden, welche ein Fehlverhalten einer Komponente oder einer Kommunikationsbeziehung bewirken.
6. Verfahren nach Anspruch 2 oder 3 und 5 , dadurch gekennzeichnet, dass Fehlverhalten einer Komponente oder einer Kommunikationsbeziehung zu den globalen Auswirkungen zugeordnet werden.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Maßnahmen zur Fehlererkennung und/oder Fehlerbeherrschung ermittelt werden.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die FunktionsStruktur dahingehend erweitert wird, dass die globalen Auswirkungen und/oder dass Fehlverhalten einer Komponente oder einer Kommunikationsbeziehung berücksichtigt wird.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die FunktionsStruktur dahingehend erweitert wird, dass Maßnahmen zur Fehlererkennung und/oder Fehlerbeherrschung einbezogen werden.
10. Verfahren zur Erzielung einer vorgebbaren Sicherheitsstufe bei Systemen, insbesondere in einem Kraftfahrzeug, wobei die Systeme oder wenigstens ein System aus mehreren Komponenten bestehen, zwischen denen Kommunikationsbeziehungen bestehen, wobei die Komponenten und deren Kommunikationsbeziehungen eine FunktionsStruktur der Systeme bilden, wobei Fehler in Abhängigkeit von der FunktionsStruktur ermittelt werden und diese Fehlerabhängigkeiten bezüglich der Funktionsstruktur ausgewertet werden mit folgenden Schritten:
a) Verfolgung der Fehlerabhängigkeiten in der FunktionsStruktur und Generation von Fehlerpfaden sowie Ermittlung von globalen Auswirkungen der Fehler, b) Bewertung der globalen Auswirkungen in Abhängigkeit vorgebbarer Sicherheitsstufen, c) Ermittlung von Fehlern, welche ein Fehlverhalten einer Komponente oder einer Kommunikationsbeziehung bewirken, d) Zuordnung des FehlVerhaltens einer Komponente oder einer Kommunikationsbeziehung zu den globalen Auswirkungen e) Ermittlung von Maßnahmen zur Fehlererkennung und/oder Fehlerbeherrschung, f) Ermittlung der erzielbaren Sicherheitsstufe und Vergleich der ermittelten Sicherheitsstufe mit der zu erzielenden Sicherheitsstufe und g) in Abhängigkeit von dem Vergleich erneuter Verfahrensstart bei a) , bis die zu erzielende Sicherheitsstufe erzielt ist.
11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass zwischen den Schritten e) und f) eine Dokumentation der Funktionsstruktur erfolgt.
12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Funktionsstruktur als CARTRONIC®- FunktionsStruktur unter Verwendung der UML dargestellt wird.
13. Einrichtung, insbesondere Computersystem, zur Durchführung eines Verfahrens gemäß wenigstens einem der Ansprüche 1 bis 12.
14. Computerprogramm, welches bei Ablauf in einer Einrichtung nach Anspruch 13 ein Verfahren gemäß wenigstens einem der Ansprüche 1 bis 12 ausführt.
15. Computerprogrammprodukt, insbesondere ein Datenträger mit einem Computerprogramm nach Anspruch 14, welches bei Einbringung in eine Einrichtung nach Anspruch 13 ein Verfahren nach wenigstens einem der Ansprüche 1 bis 12 ausführt.
PCT/DE2003/000329 2002-03-01 2003-02-06 Einrichtung und verfahren zur beurteilung und erzielung von sicherheit bei systemen sowie entsprechendes computerprogramm WO2003075104A2 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP03706283A EP1483745A2 (de) 2002-03-01 2003-02-06 Einrichtung und verfahren zur beurteilung und erzielung von sicherheit bei systemen sowie entsprechendes computerprogramm
US10/506,372 US7469170B2 (en) 2002-03-01 2003-02-06 Device and method for assessing the safety of systems and for obtaining safety in system, and corresponding computer program
JP2003573502A JP4382494B2 (ja) 2002-03-01 2003-02-06 システムにおける安全性を判定し，かつその安全性を得るための装置，方法および対応するコンピュータプログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10208866.7 2002-03-01
DE10208866A DE10208866A1 (de) 2002-03-01 2002-03-01 Einrichtung und Verfahren zur Beurteilung und Erzielung von Sicherheit bei Systemen sowie entsprechendes Computerprogramm

Publications (2)

Publication Number Publication Date
WO2003075104A2 true WO2003075104A2 (de) 2003-09-12
WO2003075104A3 WO2003075104A3 (de) 2004-04-01

Family

ID=27675137

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2003/000329 WO2003075104A2 (de) 2002-03-01 2003-02-06 Einrichtung und verfahren zur beurteilung und erzielung von sicherheit bei systemen sowie entsprechendes computerprogramm

Country Status (5)

Country Link
US (1) US7469170B2 (de)
EP (1) EP1483745A2 (de)
JP (1) JP4382494B2 (de)
DE (1) DE10208866A1 (de)
WO (1) WO2003075104A2 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2448351B8 (en) * 2007-04-12 2017-03-01 It Acs Ltd Method and apparatus for active system safety
US7920988B2 (en) * 2008-11-13 2011-04-05 Caterpillar Inc. Capturing system interactions
EP2221679B1 (de) * 2009-02-11 2012-06-06 Siemens Aktiengesellschaft Verfahren zur logischen Verschaltung von Sicherheitskreisen in einer industriellen Automatisierungsordnung und Projektierungseinrichtung zur Durchführung des Verfahrens
JP5549665B2 (ja) 2011-12-28 2014-07-16 株式会社デンソー 車両制御装置及びソフトウェア部品
US20130282190A1 (en) * 2012-04-24 2013-10-24 General Electric Company System and method for configuration and management of power plant assets
US20150032643A1 (en) * 2013-07-23 2015-01-29 Micropilot Inc. Product configuration method and system using failure mode design
US9639450B2 (en) 2015-06-17 2017-05-02 General Electric Company Scalable methods for analyzing formalized requirements and localizing errors
DE102016206586A1 (de) * 2016-04-19 2017-10-19 Zf Friedrichshafen Ag Verfahren zum Generieren von Fehlerspeichereinträgen in einem Fehlerspeicher einer Getriebesteuerung
WO2023145491A1 (ja) * 2022-01-25 2023-08-03 株式会社デンソー 運転システムの評価方法及び記憶媒体
WO2023145490A1 (ja) * 2022-01-25 2023-08-03 株式会社デンソー 運転システムの設計方法及び運転システム
WO2023223431A1 (ja) * 2022-05-17 2023-11-23 三菱電機株式会社 車両走行データ記録装置および車両走行データ可視化装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19639424A1 (de) * 1995-09-25 1997-03-27 Siemens Ag Entwurfsverfahren für die Anlagentechnik und rechnergestütztes Projektierungssystem zur Verwendung bei diesem Verfahren
DE10015114A1 (de) * 2000-03-28 2001-10-04 Bosch Gmbh Robert Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS62291537A (ja) 1986-06-11 1987-12-18 Nippon Denso Co Ltd 車両用総合診断装置
JPH0827650B2 (ja) 1988-04-18 1996-03-21 株式会社日立製作所 異常予知支援装置
JP2890815B2 (ja) 1990-11-08 1999-05-17 三菱電機株式会社 プラントの異常診断装置
JP2658600B2 (ja) 1991-01-30 1997-09-30 日産自動車株式会社 車両の制御装置
JPH06123642A (ja) 1992-10-13 1994-05-06 Toshiba Corp プラント異常診断方法及びプラント異常診断装置
JPH09146630A (ja) 1995-11-24 1997-06-06 Jatco Corp 故障診断装置
DE19611944C2 (de) * 1996-03-26 2003-03-27 Daimler Chrysler Ag Integrierter Schaltkreis zur Kopplung eines mikrokontrollierten Steuergerätes an einen Zweidraht-Bus
JP2001100835A (ja) 1999-09-29 2001-04-13 Toshiba Corp プラント状態監視システム
US6684349B2 (en) * 2000-01-18 2004-01-27 Honeywell International Inc. Reliability assessment and prediction system and method for implementing the same
JP3770053B2 (ja) * 2000-05-26 2006-04-26 三菱ふそうトラック・バス株式会社 車両用ネットワークの通信復帰判定方法
US6816798B2 (en) * 2000-12-22 2004-11-09 General Electric Company Network-based method and system for analyzing and displaying reliability data
US6577971B2 (en) * 2001-08-06 2003-06-10 Johnson Controls Technology Company System and method for evaluating craftsmanship

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19639424A1 (de) * 1995-09-25 1997-03-27 Siemens Ag Entwurfsverfahren für die Anlagentechnik und rechnergestütztes Projektierungssystem zur Verwendung bei diesem Verfahren
DE10015114A1 (de) * 2000-03-28 2001-10-04 Bosch Gmbh Robert Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TORSTEN BERTRAM, PETER DOMINKE, BERND MÜLLER: "The Safety-Related Aspect of CARTRONIC" SAE TECHNICAL PAPER SERIES, INTERNATIONAL CONGRESS AND EXPOSITION, DOC. NO. 1999-01-0488, 4. März 1999 (1999-03-04), XP002251848 Detroit, Michigan, USA in der Anmeldung erwähnt *

Also Published As

Publication number Publication date
EP1483745A2 (de) 2004-12-08
DE10208866A1 (de) 2003-09-04
US20050223263A1 (en) 2005-10-06
WO2003075104A3 (de) 2004-04-01
JP2005518992A (ja) 2005-06-30
JP4382494B2 (ja) 2009-12-16
US7469170B2 (en) 2008-12-23

Similar Documents

Publication Publication Date Title
DE102006017824B4 (de) Methode zum Konstruieren einer Diagnosefunktion
DE10223880B4 (de) Verfahren zur gegenseitigen Überwachung von Komponenten eines dezentral verteilten Rechnersystems
EP3709166B1 (de) Verfahren und system zur sicheren signalmanipulation für den test integrierter sicherheitsfunktionalitäten
EP3644148B1 (de) Testterminal für tests an einer fahrzeug-infrastruktur
WO2003075104A2 (de) Einrichtung und verfahren zur beurteilung und erzielung von sicherheit bei systemen sowie entsprechendes computerprogramm
DE10331873A1 (de) Verfahren zur Überwachung verteilter Software
DE19927657A1 (de) Partitionierung und Überwachung von softwaregesteuerten Systemen
DE102017211433A1 (de) Verfahren zum Durchführen eines Funktionstests eines Steuergeräts in einem Hardware-in-the-Loop-Test, HIL-Test, sowie HIL-Prüfstand und Steuergerät
DE102019134053A1 (de) Verfahren zur kontinuierlichen Absicherung im Fahrversuch applizierter automatisierter Fahrfunktionen
EP3306295A1 (de) Verfahren und vorrichtung zum testen elektronischer steuerungen, insbesondere zum testen von automobilsteuerungen
WO2008095518A1 (de) Anwendung einer verteilten diagnosearchitektur in autosar
EP3935463B1 (de) Verfahren und vorrichtung zum betreiben eines automatisierten fahrzeugs
WO2005003972A2 (de) Verfahren zu überprüfung der sicherheit und zuverlässigkeit softwarebasierter elektronischer systeme
DE10331872A1 (de) Verfahren zur Überwachung eines technischen Systems
EP1894101A1 (de) Verfahren und vorrichtung zum überwachen eines unerlaubten speicherzugriffs einer rechenvorrichtung, insbesondere in einem kraftfahrzeug
WO2005001692A2 (de) Verfahren und vorrichtung zur überwachung eines verteilten systems
EP3933593A1 (de) Verfahren und computerprogramm zum testen eines technischen systems
DE102018217728A1 (de) Verfahren und Vorrichtung zum Schätzen von mindestens einer Leistungskennzahl eines Systems
DE102013200932A1 (de) Verfahren und Vorrichtung zur Überwachung einer Funktion eines Motorsteuergeräts zum Einsatz in einem Motorsystem mit einem Verbrennungsmotor
DE102018209835B3 (de) Verfahren zum Betreiben einer Steuervorrichtung eines Geräts sowie Konfigurationssystem für eine Steuervorrichtung eines Geräts
DE102022211737A1 (de) Verfahren zum Ermitteln von Regeln für eine Überwachungsvorrichtung
DE102022207612A1 (de) Computer-implementiertes Verfahren zur Verifikation einer Softwarekomponente einer automatisierten Fahrfunktion
DE102021211620A1 (de) Verfahren und System zur automatischen Erzeugung eines eingebetteten Quellcodes für die elektronische Steuereinheit eines AD/ADAS-Strassenfahrzeugs
DE102022211725A1 (de) Verfahren zur Überwachung von Schnittstellen zwischen einer Software-Applikation und einem Steuergerät
EP4086773A1 (de) Computerimplementiertes verfahren zum automatischen bereitstellen eines hinweises für testprozesse

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): JP US

AL Designated countries for regional patents

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 LU MC NL PT SE SI SK TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
REEP Request for entry into the european phase

Ref document number: 2003706283

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2003706283

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2003573502

Country of ref document: JP

WWP Wipo information: published in national office

Ref document number: 2003706283

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10506372

Country of ref document: US