EP2168070A2 - Verfahren zur transparenten replikation einer softwarekomponente eines softwaresystems - Google Patents

Verfahren zur transparenten replikation einer softwarekomponente eines softwaresystems

Info

Publication number
EP2168070A2
EP2168070A2 EP08760539A EP08760539A EP2168070A2 EP 2168070 A2 EP2168070 A2 EP 2168070A2 EP 08760539 A EP08760539 A EP 08760539A EP 08760539 A EP08760539 A EP 08760539A EP 2168070 A2 EP2168070 A2 EP 2168070A2
Authority
EP
European Patent Office
Prior art keywords
components
processing units
vea
veb
rte
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
EP08760539A
Other languages
English (en)
French (fr)
Inventor
Michael Golm
Klaus Jürgen Schmitt
Konrad Schwarz
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.)
Siemens AG
Original Assignee
Siemens AG
Siemens Corp
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 Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of EP2168070A2 publication Critical patent/EP2168070A2/de
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/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operations
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking using middleware or operating system [OS] functionalities
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1675—Temporal synchronisation or re-synchronisation of redundant processing components
    • G06F11/1687—Temporal synchronisation or re-synchronisation of redundant processing components at event level, e.g. by interrupt or result of polling
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/187—Voting techniques
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2002—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant
    • G06F11/2007—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication media

Definitions

  • the invention relates to a method for the transparent replication of a software component of a software system, in particular according to the AUTOSAR standard, in a computer system comprising two or more processing units, wherein the processing units are interconnected via one or more communication channels for exchanging data.
  • AUTOSAR is a standard developed in the automotive industry, in which interfaces and interactions of
  • XML Extendable Markup Language
  • Components for modeling functionalities are so-called components and compositions. Compositions include a plurality of components interconnected via communication links. Components and compositions are connected via so-called ports. Ports form communication interfaces to transfer data between individuals
  • the processing units are interconnected via one or more communication channels for exchanging data.
  • Each of the processing units includes a runtime environment. Respective runtime environments of the processing units to be replicated are provided with a synchronization and selection functionality.
  • the inventive method enables accurate synchronization of applications between parallel runtime environments.
  • the method does not require time synchronization.
  • the inventive method makes use of an extension of the runtime environments, so-called Runtime Environment RTE.
  • the AUTOSAR runtime environment is a tool-generated middleware that, among other things, allows a location-transparent communication between software components.
  • the runtime environment is extended by one sync and one sync
  • Selection functionality extended. Between the replicated runtime environments a virtual communication channel is formed.
  • the communication between different software components can be done in different ways: In the case of a transceiver system this can be done “queued” or “unqueued”. In the case of a client-server system, this can be synchronous or asynchronous.
  • the communication within a software component can take place using so-called “interactive variables” or "exclusive areas”.
  • the internal behavior of the software components includes the following: Invocation of runable entities, blocking and deblocking of runables to wait points, reception of RTE events, and per-instance memory "Intitialization / Finalization"
  • Invocation of runable entities includes the following: Invocation of runable entities, blocking and deblocking of runables to wait points, reception of RTE events, and per-instance memory "Intitialization / Finalization”
  • Intitialization / Finalization A detailed description of the communication over the virtual communication channel can be found in the document "Specification of the AUTOSAR Runtime Environment, Version 2.0.0" of Autosar GbR.
  • Data exchange via communication interfaces including transmitting and receiving ports, connected to each other, wherein the reception ports data are supplied event driven or by cyclic queries.
  • the reception of data triggers on one of the receiving ports the starting of code sequences which run on the redundant processing units.
  • the code sequences can Use a runtime environment code to communicate with other components or to invoke services. This means that software functionality can be represented by a sequence of code sequence calls. Code sequences are also referred to as runable entities. Code sequences use the runtime environment as middleware to exchange data from other components or to perform so-called remode procedure calls.
  • the components are duplicated on redundant processing units.
  • the synchronization of the signal processing steps is performed by the runtime environments of the redundant processing units.
  • the idea of the transparent runtime environment is thus to ensure redundancy by the runtime environment itself.
  • the synchronization takes place via the communication channel between the runtime environments to be replicated. Synchronization can be via a bus or a so-called “dual-port RAM", which is also called a synchronization channel.
  • all signals applied to input ports of compositions are simultaneously applied to the input ports of the redundant compositions.
  • Each of the components comprises a plurality of communicatively connected components.
  • all the output ports are compared with the result of the redundant component before the output of a signal and led to a common result.
  • a physical synchronization path is the connection between a processing unit and its redundant partner processing unit. This may be a point-to-point connection or bus, such as a bus. a CAN bus, flexray bus, etc.
  • Fig. 1 is a schematic representation of a plurality
  • Processing units comprising a transparent replication of a software component of a software system
  • FIG. 2 shows a schematic representation of a virtual interconnection of components of a software component
  • FIG. 3 shows a schematic representation of a software functionality in the form of a sequence of code sequence calls
  • Fig. 4 is a schematic representation of duplicated code sequences
  • Fig. 5 is a schematic representation of a mapping of software components to different
  • Processing units is illustrated.
  • Fig. 1 shows a schematic representation of a computing system with processing units VEA, VEB and VEC.
  • the processing units VEA, VEB, VEC are over two
  • the processing units VEA, VEB, VEC can represent, for example, control devices and are generally referred to as ECUs (Electronic Control Units).
  • Each of the processing units comprises in a known manner a basic software functionality BSW. This includes, for example, an operating system, means for communication via the communication channels, drivers for communication or access to memory.
  • each of the processing units comprises a runtime environment RTE, which is also referred to as a runtime environment.
  • the processing units VEA, VEB is a
  • the software component SWCl comprises two instances SWC1 A and SWC1 B , the former being assigned to the processing unit VEA and the latter to the processing unit VEB.
  • the instances SWCIa, SWCIb of the software component SWC form redundant
  • the processing unit VEC is assigned a software component SWC2.
  • the software component SWC2 is via a
  • the software component SWC2 has a port PR called Required Port becomes.
  • the software component SWCl has a port PP, which is referred to as Provided Port.
  • the communication link KV is in the schematic representation of no physical connection, but only a virtual connection to represent the functionalities. An actual data exchange via one of the communication channels KKL or KK2.
  • the runtime environments RTE of the processing units VEA and VEB are extended compared to a standard AUTOSAR runtime environment.
  • the AUTOSAR runtime environment is a tool-generated middleware, which, among other things, allows a location-transparent communication between software components.
  • the RTE runtimes are the
  • Processing units VEA and VEB to a synchronization and voting functionality (SyncF, VoteF) extended.
  • a virtual communication channel SYNC is also shown, which is also referred to as a synchronization path.
  • the communication channel is a prerequisite for realizing replication transparency. To realize the replication transparency, the following properties of the runtime environment must be extended accordingly: The communication between different
  • Software components The communication within a software component. The communication with services of the processing unit and the internal behavior of the software component.
  • the communication links can be pulled regardless of how the components are distributed to the flow platform.
  • the in Fig. 2 shown functionality consists of the five components A to E, which are interconnected via ports PE, PA. These ports PE, PA form the interfaces for data exchange. There are transmit ports PA and receive ports PE.
  • data can be fed to the components via event-driven or by cyclic querying the further processing.
  • the reception of data results in the start of a so-called runable entity rel, re2, re3, re4, re5, re ⁇ , in whose context the processing of the data occurs.
  • Runable entities are code sequences that can run on one or more processing units. These use the runtime environment as middleware to get data from others
  • SEN denotes a sensor which is connected via a communication link to a receiving port PE of the component A.
  • An actuator AKT is via a communication link with a
  • the respective communication links KV which connect a transmission port PA to an output port PE are formed according to a desired functionality.
  • RTE calls RTEC provide the only way to exchange data with other components or services.
  • the implementation of code sequences over runable entities consists of manually implemented code that generates the generated runtime environment code for communication with others
  • FIG. 4 shows a schematic view from the perspective of a runable entity with duplicated runable entities rel to re ⁇ .
  • a system X (instance of a software component) has been duplicated by system X '.
  • the system X ' carries all
  • Each RTE call RTEC synchronizes systems X and X '. This is represented by the arrows running between the RTE calls.
  • Ports that are interconnected internally are referred to in AUTOSAR as "assembly ports.”
  • Delegation ports represent the external behavior and must be given special consideration in the case of redundancy considerations. All signals and input ports, the so-called “Required Ports”, must be used at the same time as the input ports the redundant components are supplied. All output ports, the “Provided Ports”, must be compared with the result of the partner component before outputting a signal and combined into a common result
  • the AUTOSAR method allows a static mapping, which means a mapping to the configuration time of software components on the processing units. Since the mapping is static, at the time of
  • Runtime environment generation knows which components were mapped to which processing units. This allows the runtime environment generator to find physical synchronization paths for all synchronization points and to generate the corresponding code.
  • a physical synchronization path is the connection between an ECU instance and its redundant partner processing unit. This can be a point-to-point connection as well as a bus.
  • Figure 5 shows the physical view after the execution of the mapping for the virtual view shown initially ( Figure 2).
  • the instances of the software component are labeled ECUl and ECU2. Redundant instances of the software component are labeled ECUl 'and ECU2'.
  • the components A and B have been mapped to the ECU instance ECU1, while the components C, D and E have been mapped to the ECU instance ECU2.
  • Each of the ECU instances ECU1, ECU2 has a redundant double ECU1 ', ECU2' on which the components are equally mapped.
  • the ECU instances each have a synchronization channel SYNC to their redundant partners.
  • the runtime environment may synchronize in the transparent replication of AUTOSAR software components. This means that the functionality for synchronizing the replicated AUTOSAR software components can be generated transparently for the application without explicit modeling.
  • a selection switch SEL is further shown, which is connected to the output of the ECU instance ECU2.
  • the switch position is determined by the output signal of the redundant ECU instance 2 ECU2 '. In the event that the partial results determined by the ECU instances ECU2 and ECU2 'are identical, the switch is closed, so that the output signal can be forwarded to the actuator AKT.
  • replication can be symmetric
  • Microcontrollers interconnected by a direct communication channel with low latency e.g., dual-ported RAM
  • Replication can also be done on diverse microcontrollers interconnected by a direct communication channel with direct latency (e.g., dual-ported RAM).
  • Replication is possible in a network of control units connected by CAN bus or Flexray bus. Replication is also possible on a microcontroller. In this case, replicated code is executed with a time delay.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Multi Processors (AREA)
  • Stored Programmes (AREA)
  • Hardware Redundancy (AREA)

Abstract

Es wird ein Verfahren zur transparenten Replikation einer Softwarekomponente (SWC1) eines Softwaresystems (SWC1, SWC2), insbesondere gemäß dem AUTOSAR-Standard, in einem zwei oder mehrere Verarbeitungseinheiten (VEA, VEB) umfassenden Rechensystem beschrieben. Die Verarbeitungseinheiten (VEA, VEB) sind über einen oder mehrere Kommunikationskanäle (KK1, KK2 ) zum Austausch von Daten miteinander verbunden. Jede der Verarbeitungseinheiten (VEA, VEB) umfasst eine Laufzeitumgebung (RTE), bei dem jeweilige zu replizierende Laufzeitumgebungen (RTE) der Verarbeitungseinheiten (VEA, VEB) mit einer Synchronisations- und Auswahlfunktionalität (Sync, Voting) versehen werden.

Description

Beschreibung
Verfahren zur transparenten Replikation einer Softwarekomponente eines Softwaresystems
Die Erfindung betrifft ein Verfahren zur transparenten Replikation einer Softwarekomponente eines Softwaresystems, insbesondere gemäß dem AUTOSAR-Standard, in einem zwei oder mehrere Verarbeitungseinheiten umfassenden Rechensystem, wobei die Verarbeitungseinheiten über einen oder mehrere Kommunikationskanäle zum Austausch von Daten miteinander verbunden sind.
AUTOSAR ist ein in der Automobilindustrie entwickelter Standard, in dem Schnittstellen und Interaktionen von
Softwarekomponenten in Form von XML-Beschreibungen (XML = Extendable Markup Language) spezifiziert sind. AUTOSAR ermöglicht eine architekturzentrische Modellierung von komplexen Softwaresystemen. Dies bedeutet, dass Code zum Senden von Daten generiert wird, während eine Funktionalität (Algorithmen) manuell implementiert oder durch rechnergestützte Werkzeuge generiert wird. Für alle Ein- und Ausgaben stehen generierte IO-Funktionen (IO = Input Output) zur Verfügung, die als RTE Calls bezeichnet werden. Bausteine zum Modellieren von Funktionalitäten sind sog. Komponenten und Kompositionen. Kompositionen umfassen eine Mehrzahl an Komponenten, die über Kommunikationsverbindungen miteinander verbunden sind. Komponenten und Kompositionen sind über sog. Ports miteinander verbunden. Ports bilden Kommunikationsschnittstellen, um Daten zwischen einzelnen
Komponenten auszutauschen sowie um Funktionsaufrufe zwischen den Komponenten zu ermöglichen. Je nach Ausgestaltung des Rechnersystems müssen die Softwarekomponenten in sicherheitskritischen Applikationen an die jeweilige Hardwarearchitektur angepasst werden. Alternativ kann spezielle Hardware zur transparenten Replikation verwendet werden . Es ist Aufgabe der vorliegenden Erfindung, ein Verfahren zur transparenten Replikation einer Softwarekomponenten eines Softwaresystems, insbesondere gemäß dem AUTOSAR-Standard, anzugeben, welches die unmodifizierte Verwendung von AUTOSAR- Softwarekomponenten in sicherheitskritischen Applikationen ermöglicht, welche insbesondere ein mehrkanaliges Rechensystem vorschreiben.
Diese Aufgabe wird mit den Merkmalen des Patentanspruchs 1 gelöst. Vorteilhafte Ausführungsformen sind in den abhängigen Ansprüchen wiedergegeben.
In dem erfindungsgemäßen Verfahren zur transparenten Replikation einer Softwarekomponente eines Softwaresystems in einem zwei oder mehrere Verarbeitungseinheiten umfassenden
Rechensystem, sind die Verarbeitungseinheiten über einen oder mehrere Kommunikationskanäle zum Austausch von Daten miteinander verbunden. Jede der Verarbeitungseinheiten umfasst eine Laufzeitumgebung. Es werden jeweilige zu replizierende Laufzeitumgebungen der Verarbeitungseinheiten mit einer Synchronisations- und Auswahlfunktionalität versehen .
Das erfindungsgemäße Verfahren ermöglicht eine genaue Synchronisierung von Applikationen zwischen parallel laufenden Laufzeitumgebungen. Hierbei benötigt das Verfahren keine Zeitsynchronisierung.
Das erfindungsgemäße Verfahren bedient sich dabei einer Erweiterung der Laufzeitumgebungen, sog. Runtime-Environment RTE. Die AUTOSAR-Laufzeitumgebung ist eine werkzeuggenerierte Middleware, welche unter anderem eine ortstransparente Kommunikation zwischen Softwarekomponenten erlaubt. Um die Replikations-Transparenz bereitzustellen, wird die Laufzeitumgebung um eine Synchronisations- und um eine
Auswahlfunktionalität (Voting-Funktionalität) erweitert. Zwischen den replizierten Laufzeitumgebungen wird hierbei ein virtueller Kommunikationskanal gebildet. Die Kommunikation zwischen verschiedenen Softwarekomponenten kann auf unterschiedliche Weise erfolgen: Im Falle eines Sender- Empfänger-Systems kann diese „queued" oder „unqueued" erfolgen. Im Falle eines Client-Server-Systems kann diese synchron oder asynchron erfolgen. Die Kommunikation innerhalb einer Softwarekomponente kann unter Verwendung sog. „inter- runable variables" oder „exclusive areas" erfolgen. Die Kommunikation mit Diensten der Verarbeitungseinheit (sog. ECU = Electronic Control Unit, Steuergerät) kann als Kommunikation mit Diensten („Communication with Services") oder als Kommunikation mit Ein-/Ausgabe-Abstraktion („Communication with IO Abstraction") ausgebildet sein. Das interne Verhalten der Softwarekomponenten umfasst folgende Möglichkeiten: „Invocation of Runable Entities", blockieren und deblockieren von Runables an „Wait Points", Empfang von Laufzeitumgebungsereignissen („Reception of RTE Events", Speicher pro Instanz („per-instants memory") und „Intitialization/Finalization" . Eine genaue Beschreibung der Kommunikation über den virtuellen Kommunikationskanal kann dem Dokument „Specification of the AUTOSAR Runtime Environment, Version 2.0.0" der Autosar GbR entnommen werden.
Zur Ausbildung einer Funktionalität der Softwarekomponente erfolgt eine virtuelle Verschaltung einer Anzahl an Komponenten, unabhängig von der Verteilung der Komponenten auf den zu replizierenden Laufzeitumgebungen.
Die Komponenten einer Funktionalität werden zum
Datenaustausch über Kommunikationsschnittstellen, umfassend Sende- und Empfangsports, miteinander verbunden, wobei den Empfangs-ports Daten Ereignis-getrieben oder durch zyklisches Abfragen zugeführt werden.
Der Empfang von Daten löst an einem der Empfangsports das Starten von Codesequenzen aus, die auf den redundanten Verarbeitungseinheiten ablaufen. Die Codesequenzen können einen Laufzeitumgebungscode zur Kommunikation mit weiteren Komponenten oder zum Aufruf von Diensten nutzen. Dies bedeutet, dass eine Software-Funktionalität durch eine Sequenz von Codesequenz-Aufrufen dargestellt werden kann. Codesequenzen werden auch als Runable Entities bezeichnet. Codesequenzen nutzen die Laufzeitumgebung als Middleware, um Daten von anderen Komponenten auszutauschen oder um sog. Remode Procedure-Aufrufe durchzuführen.
Gemäß einer weiteren Ausgestaltung werden die Komponenten auf redundanten Verarbeitungseinheiten dupliziert. Die Synchronisierung der Signalverarbeitungsschritte erfolgt durch die Laufzeitumgebungen der redundanten Verarbeitungseinheiten. Die Idee der transparenten Laufzeitumgebung besteht somit darin, Redundanz durch die Laufzeitumgebung selbst sicherzustellen.
Die Synchronisation erfolgt über den Kommunikationskanal zwischen den zu replizierenden Laufzeitumgebungen. Die Synchronisation kann über einen Bus oder einen sog. „Dual- Port-RAM" erfolgen. Dies wird auch als Synchronisierungskanal bezeichnet .
Gemäß einer weiteren Ausführungsform werden alle Signale, die an Eingangsports von Kompositionen anliegen, zeitgleich den Eingangsports der redundanten Kompositionen zugeführt. Jede der Komponenten umfasst dabei eine Mehrzahl an miteinander kommunikativ verbundenen Komponenten.
In einer weiteren Ausführungsform werden alle Ausgangsports vor der Ausgabe eines Signals mit dem Ergebnis der redundanten Komponente verglichen und zu einem gemeinsamen Ergebnis geführt. Dies beschreibt die Ausgangsfunktionalität in der Laufzeitumgebung, die auch als Voting bezeichnet wird. Für jeden Ausgangsport, der einem Voting unterzogen wird, muss eindeutig festgelegt sein, welche Aktion oder Aktionen in einem Erfolgsfall und in einem Fehlerfall ausgeführt werden müssen. In einem Erfolgsfall stimmen beide Teilergebnisse der redundanten Komponente, z.B. innerhalb festgelegter Toleranzen, überein. Im Fehlerfall sind die von den redundanten Komponenten ermittelten Teilergebnisse unterschiedlich. Portzugriffe oder andere IO-Funktionen, die nicht nach außen geführt sind, müssen zeitlich synchronisiert werden, ohne ein Voting auszuführen.
Zum Zeitpunkt einer Laufzeitumgebungsgenerierung wird ermittelt, welcher der Verarbeitungseinheiten welche Komponenten zugeordnet wurden und welcher der
Verarbeitungseinheiten die zugehörigen redundanten Komponenten zugeordnet wurden, aus welchen Informationen die Laufzeitumgebungen physikalische Synchronisierungspfade für alle Synchronisierungspunkte ermitteln und entsprechenden Laufzeitumgebungscode generieren. Unter einem physikalischen Synchronisierungspfad wird die Verbindung zwischen einer Verarbeitungseinheit und ihrer redundanten Partner- Verarbeitungseinheit bezeichnet. Dies kann eine Punkt-zuPunkt-Verbindung oder Bus, wie z.B. ein CAN-Bus, Flexray-Bus etc. sein.
Die Erfindung wird nachfolgend weiter anhand der Figuren erläutert. Es zeigen:
Fig. 1 eine schematische Darstellung eines mehrere
Verarbeitungseinheiten umfassenden Rechensystems, in welchem eine transparente Replikation einer Softwarekomponente eines Softwaresystems veranschaulicht ist,
Fig. 2 eine schematische Darstellung einer virtuellen Verschaltung von Komponenten einer Softwarekomponente,
Fig. 3 eine schematische Darstellung einer Software- Funktionalität in Form einer Sequenz von Codesequenz-Aufrufen, Fig. 4 eine schematische Darstellung von duplizierten Codesequenzen, und
Fig. 5 eine schematische Darstellung, aus der ein Mapping von Softwarekomponenten auf verschiedene
Verarbeitungseinheiten illustriert ist.
Fig. 1 zeigt in einer schematischen Darstellung ein Rechensystem mit Verarbeitungseinheiten VEA, VEB und VEC. Die Verarbeitungseinheiten VEA, VEB, VEC sind über zwei
Kommunikationskanäle KKl, KK2 zum Datenaustausch miteinander verbunden. Die Kommunikationskanäle KKl, KK2 können beispielsweise durch einen Bus (z.B. CAN-Bus oder Flexray- Bus) gebildet sein. Die Verarbeitungseinheiten VEA, VEB, VEC können beispielsweise Steuergeräte darstellen und sind allgemein sog. ECUs (Electronic Control Units) . Jede der Verarbeitungseinheiten umfasst in bekannter Weise eine Basissoftwarefunktionalität BSW. Diese umfasst beispielsweise ein Betriebssystem, Mittel zur Kommunikation über die Kommunikationskanäle, Treiber zur Kommunikation oder zum Zugriff auf Speicher. Ferner umfasst jede der Verarbeitungseinheiten eine Laufzeitumgebung RTE, die auch als Runtime-Environment bezeichnet wird.
Den Verarbeitungseinheiten VEA, VEB ist eine
Softwarekomponente SWCl zugeordnet. Die Softwarekomponente SWCl umfasst zwei Instanzen SWC1A und SWC1B, wobei erstere der Verarbeitungseinheit VEA und letztere der Verarbeitungseinheit VEB zugeordnet ist. Die Instanzen SWCIa, SWCIb der Softwarekomponente SWC bilden redundante
Funktionalitäten aus, die auf den Laufzeitumgebungen RTE der Verarbeitungseinheiten VEA und VEB durchgeführt werden.
Der Verarbeitungseinheit VEC ist eine Softwarekomponente SWC2 zugeordnet. Die Softwarekomponente SWC2 ist über eine
Kommunikationsverbindung KV mit der Softwarekomponente SWCl verbunden. Zu diesem Zweck verfügt die Softwarekomponente SWC2 über einen Port PR, der als Required Port bezeichnet wird. In entsprechender Weise verfügt die Softwarekomponente SWCl über einen Port PP, der als Provided Port bezeichnet wird. Die Kommunikationsverbindung KV stellt in der schematischen Darstellung keine physikalische Verbindung, sondern lediglich eine virtuelle Verbindung zur Darstellung der Funktionalitäten dar. Ein tatsächlicher Datenaustausch erfolgt über einen der Kommunikationskanäle KKl oder KK2.
Die Laufzeitumgebungen RTE der Verarbeitungseinheiten VEA und VEB sind gegenüber einer Standard-AUTOSAR-Laufzeitumgebung erweitert. Allgemein ist die AUTOSAR-Laufzeitumgebung eine werkzeuggenerierte Middleware, welche unter anderem eine ortstransparente Kommunikation zwischen Softwarekomponenten erlaubt. Zur Realisierung einer zusätzlichen Replikations- Transparenz sind die Laufzeitumgebungen RTE der
Verarbeitungseinheiten VEA und VEB um eine Synchronisationsund Voting-Funktionalität (SyncF, VoteF) erweitert. Zwischen den Laufzeitumgebungen RTE der Verarbeitungseinheiten VEA und VEB ist ferner ein virtueller Kommunikationskanal SYNC eingezeichnet, welcher auch als Synchronisierungspfad bezeichnet wird. Der Kommunikationskanal ist Voraussetzung zur Realisierung einer Replikations-Transparenz . Zur Realisierung der Replikations-Transparenz müssen folgende Eigenschaften der Laufzeitumgebung entsprechend erweitert werden: Die Kommunikation zwischen verschiedenen
Softwarekomponenten. Die Kommunikation innerhalb einer Softwarekomponente. Die Kommunikation mit Diensten der Verarbeitungseinheit und das interne Verhalten der Softwarekomponente .
Unter Bezugnahme auf die Figuren 2 bis 5 wird nachfolgend die Modellierung der Replikationstransparenz beschrieben. Die Modellierung beginnt mit einer virtuellen Verschaltung von Komponenten. Dies ist beispielhaft in Fig. 2 dargestellt. Bei dieser virtuellen Sicht können Verbindungen KV zwischen
Komponenten gezogen werden. Die Kommunikationsverbindungen können unabhängig davon, wie die Komponenten auf die Ablauf- Plattform verteilt werden, gezogen werden. Die in Fig. 2 dargestellte Funktionalität besteht aus den fünf Komponenten A bis E, die über Ports PE, PA miteinander verbunden sind. Diese Ports PE, PA bilden die Schnittstellen zum Datenaustausch. Es existieren Sendeports PA und Empfangsports PE.
An Empfangsports PE können Daten Ereignis-getrieben bzw. durch zyklisches Abfragen der Weiterverarbeitung den Komponenten zugeführt werden. In jedem Fall führt der Empfang von Daten dazu, dass ein sog. Runable Entity rel, re2, re3, re4, re5, reβ gestartet wird, in dessen Kontext die Verarbeitung der Daten geschieht. Runable Entities sind Codesequenzen, die auf einer oder verschiedenen Verarbeitungseinheiten ablaufen können. Diese nutzen die Laufzeitumgebung als Middleware, um Daten von anderen
Komponenten auszutauschen bzw. um sog. RPC (Remote Procedure Calls) auszuführen. In Fig. 2 ist mit SEN ein Sensor bezeichnet, der über eine Kommunikationsverbindung mit einem Empfangsport PE der Komponente A verbunden ist. Ein Aktuator AKT ist über eine Kommunikationsverbindung mit einem
Sendeport PA der Komponente E verbunden. Die jeweiligen Kommunikationsverbindungen KV, die einen Sendeport PA mit einem Ausgangsport PE verbinden, sind entsprechend einer gewünschten Funktionalität gebildet.
RTE-Calls RTEC bieten die einzige Möglichkeit, Daten mit anderen Komponenten oder Diensten auszutauschen. Die Implementierung der Codesequenzen über Runable Entities besteht aus manuell implementiertem Code, der den generierten Laufzeitumgebungscode zur Kommunikation mit weiteren
Komponenten oder zum Aufruf von Diensten nutzen kann. Dies bedeutet, dass eine Softwarefunktionalität, durch eine Sequenz von Runable Entitiy-Aufrufen (rel-re2-re3-re4-re5- reβ) dargestellt werden kann. Dies ist in Fig. 3 dargestellt. Die Idee der transparenten Laufzeitumgebung besteht darin, Redundanz durch die Laufzeitumgebung RTE sicherzustellen. Dies geschieht durch Duplikation der Komponenten auf redundanten Verarbeitungseinheiten und die Synchronisierung der Signal-Verarbeitungsschritte durch die Laufzeitumgebung. Hierdurch wird erreicht, dass alle RTE-Calls synchron durchgeführt werden. Ferner können zeitsynchrone Eingabe- Ausgabe-Operationen (I/O-Operationen) durchgeführt werden. Die Synchronisation geschieht durch einen hoch-performanten Bus oder „Shared- bzw. Dual-Port-Memory", was im Folgenden auch als Synchronisierungskanal bezeichnet wird. Eine Duplikation der Komponenten auf redundanten Verarbeitungseinheiten ist in Fig. 1 durch die Instanzen SWC1A und SWC1B dargestellt.
Fig. 4 zeigt eine schematische Darstellung aus Sicht einer Runable Entity mit duplizierten Runable Entities rel bis reβ. Ein System X (Instanz einer Softwarekomponente) wurde durch das System X' dupliziert. Das System X' führt alle
Verarbeitungsschritte wie das System X durch. Bei jedem RTE- CaIl RTEC synchronisieren sich die Systeme X und X' . Dies ist durch die zwischen den RTE-Calls verlaufenden Pfeile dargestellt .
Die transparente Replikation von AUTOSAR-Softwarekomponenten erlaubt eine beliebige Zahl von Softwarekomponenten (Komposition) redundant auszuführen. Eine Komposition hat Ein- und Ausgangsports, die nach außen geführt werden. Im AUTOSAR werden diese als „Delegation Ports" bezeichnet.
Ports, die intern verschaltet sind, werden in AUTOSAR als „Assembly Ports" bezeichnet. Delegation Ports repräsentieren das Verhalten nach außen und müssen bei Redundanz- Überlegungen besonders beachtet werden. Alle Signale und Eingangsports, die sog. „Required Ports" müssen zeitgleich den Eingangsports der redundanten Komponenten zugeführt werden. Alle Ausgangsports, die „Provided Ports", müssen vor der Ausgabe eines Signals mit dem Ergebnis der Partnerkomponente verglichen und zu einem gemeinsamen Ergebnis kombiniert werden. Dieser Vorgang wird als
Auswahlfunktionalität oder Voting bezeichnet. Für jeden Ausgangsport, der einem Voting unterzogen wird, muss eindeutig festgelegt sein, welche Aktion oder Aktionen im Erfolgsfall und im Fehlerfall ausgeführt werden müssen. Im Erfolgsfall stimmen beide Teilergebnisse, d.h. Ergebnisse, die von den Systemen X und X' ermittelt wurden, innerhalb festgelegter Toleranzen überein. Im Fehlerfall sind die Teilergebnisse, die von den Systemen X und X' ermittelt wurden, unterschiedlich. Port-Zugriffe und andere RTE-Calls, die nicht nach außen geführt sind, müssen zeitlich synchronisiert werden, ohne ein Voting oder eine Auswahlfunktionalitat auszuführen .
Anhand von Fig. 5 wird die Synchronisierung im Detail erläutert. Die AUTOSAR-Methode erlaubt ein statisches Mapping, dies bedeutet ein Mapping zur Konfigurationszeit von Softwarekomponenten auf den Verarbeitungseinheiten. Da das Mapping statisch ist, ist zum Zeitpunkt der
Laufzeitumgebungs-Generierung bekannt, welche Komponenten auf welche Verarbeitungseinheiten gemapped wurden. Dies erlaubt dem Generator der Laufzeitumgebung physikalische Synchronisierungspfade für alle Synchronisierungspunkte zu finden und den entsprechenden Code zu generieren. Unter einem physikalischen Synchronisierungspfad wird die Verbindung zwischen einer ECU-Instanz und ihrer redundanten Partner- Verarbeitungseinheit bezeichnet. Dies kann eine Punkt-zuPunkt-Verbindung als auch ein Bus sein.
Fig. 5 zeigt die physikalische Sicht nach der Ausführung des Mappings für die am Anfang gezeigte virtuelle Sicht (Fig. 2) . In Fig. 5 sind die Instanzen der Softwarekomponente mit ECUl und ECU2 bezeichnet. Redundante Instanzen der Softwarekomponente sind mit ECUl' und ECU2' gekennzeichnet.
Im Beispiel der Fig. 5 wurden die Komponenten A und B auf die ECU-Instanz ECUl gemapped, während die Komponenten C, D und E auf die ECU-Instanz ECU2 gemapped wurden. Jede der ECU- Instanzen ECUl, ECU2 hat ein redundantes Doppel ECUl', ECU2', auf dem die Komponenten gleichermaßen gemapped sind. Die ECU- Instanzen verfügen zu ihren redundanten Partnern jeweils über einen Synchronisationskanal SYNC. In der dargestellten Konfiguration kann die Laufzeitumgebung die Synchronisierung bei der transparenten Replikation von AUTOSAR- Softwarekomponenten übernehmen. Dies bedeutet, die Funktionalität zur Synchronisierung der replizierten AUTOSAR- Softwarekomponenten kann ohne explizite Modellierung für die Applikation transparent, generiert werden. In Fig. 5 ist ferner ein Auswahlschalter SEL dargestellt, der mit dem Ausgang der ECU-Instanz ECU2 verbunden ist. Weiterhin ist er mit dem Aktuator AKT verbunden. Die Schalterstellung wird durch das Ausgangssignal der redundanten ECU-Instanz 2 ECU2' festgelegt. Im Fall, dass die von den ECU-Instanzen ECU2 und ECU2' bestimmten Teilergebnisse identisch sind, wird der Schalter geschlossen, so dass das Ausgangssignal an den Aktuator AKT weitergeleitet werden kann.
Replikation kann beispielsweise auf symmetrischen
MikroControllern erfolgen, die durch einen direkten Kommunikationskanal mit niedrigen Latenzzeiten (z.B. dual- ported RAM) miteinander verbunden sind. Replikation kann auch auf diversitären MikroControllern erfolgen, die durch einen direkten Kommunikationskanal mit direkten Latenzzeiten (z.B. dual-ported RAM) miteinander verbunden sind. Replikation ist in einem durch CAN-Bus oder Flexray-Bus verbundenen Netzwerk von Steuergeräten möglich. Replikation ist ferner auf einem MikroController möglich. Dabei wird replizierter Code zeitversetzt ausgeführt.

Claims

Patentansprüche
1. Verfahren zur transparenten Replikation einer Softwarekomponente (SWCl) eines Softwaresystems (SWCl, SWC2), insbesondere gemäß dem AUTOSAR-Standard, in einem zwei oder mehrere Verarbeitungseinheiten (VEA, VEB) umfassenden Rechensystem, wobei die Verarbeitungseinheiten (VEA, VEB) über einen oder mehrere Kommunikationskanäle (KKl, KK2) zum Austausch von Daten miteinander verbunden sind, und jede der Verarbeitungseinheiten (VEA, VEB) eine Laufzeitumgebung (RTE) umfasst, bei dem jeweilige zu replizierende Laufzeitumgebungen (RTE) der Verarbeitungseinheiten (VEA, VEB) mit einer Synchronisations- und Auswahlfunktionalität (Sync, Voting) versehen werden.
2. Verfahren nach Anspruch 1, bei dem zwischen den replizierten Laufzeitumgebungen (RTE) ein virtueller Kommunikationskanal (SYNC) gebildet wird.
3. Verfahren nach Anspruch 1 oder 2, bei dem zur Ausbildung einer Funktionalität der Softwarekomponente (SWCl) eine virtuelle Verschaltung einer Anzahl an Komponenten (A, B, C, D, E) erfolgt, unabhängig von der Verteilung der Komponenten (A, B, C, D, E) auf den zu replizierenden Laufzeitumgebungen (RTE) .
4. Verfahren nach Anspruch 3, bei dem die Komponenten (A, B, C, D, E) einer Funktionalität zum Datenaustausch über Kommunikationsschnittstellen (KV) , umfassend Sende- und Empfangsports (PA, PE), miteinander verbunden werden, wobei den Empfangsports (PE) Daten Ereignis getrieben oder durch zyklisches Abfragen zugeführt werden.
5. Verfahren nach Anspruch 4, bei dem der Empfang von Daten an einem der Empfangsports (PE) das Starten von Codesequenzen
(rel,.., reβ) auslöst, die auf den redundanten Verarbeitungseinheiten (VEA, VEB) ablaufen.
6. Verfahren nach Anspruch 5, bei dem die Codesequenzen (rel,.., reβ) einen Laufzeitumgebungscode zur Kommunikation mit weiteren Komponenten (A, B, C, D, E) oder zum Aufruf von Diensten nutzen können.
7. Verfahren nach Anspruch 5 oder 6, bei dem die Codesequenzen (rel,.., reβ) die Laufzeitumgebung (RTE) oder - Umgebungen als Middleware verwenden, um Daten mit anderen Komponenten (A, B, C, D, E) auszutauschen oder um Remote Procedure-Aufrufe durchzuführen.
8. Verfahren nach einem der vorherigen Ansprüche, bei dem die Komponenten (A, B, C, D, E) auf redundanten Verarbeitungseinheiten (VEA, VEB) dupliziert werden und die Synchronisierung der Signalverarbeitungsschritte durch die Laufzeitumgebungen (RTE) der redundanten Verarbeitungseinheiten (VEA, VEB) erfolgt.
9. Verfahren nach Anspruch 8, bei dem Laufzeitumgebungsaufrufe (RTEC) synchron durchgeführt werden.
10. Verfahren nach Anspruch 9, bei dem die Synchronisation über den Kommunikationskanal (SYNC) zwischen den zu replizierenden Laufzeitumgebungen (RTE) erfolgt.
11. Verfahren nach einem der vorherigen Ansprüche, bei dem alle Signale an Eingangsports von Kompositionen, umfassend eine Mehrzahl an miteinander kommunikativ verbundenen Komponenten (A, B, C, D, E) , zeitgleich den Eingangsports der redundanten Kompositionen zugeführt werden.
12. Verfahren nach einem der vorherigen Ansprüche, bei dem alle Ausgangsports vor der Ausgabe eines Signals mit dem Ergebnis der redundanten Komponente verglichen und zu einem gemeinsamen Ergebnis geführt werden.
13. Verfahren nach einem der vorherigen Ansprüche, bei dem zum Zeitpunkt einer Laufzeitumgebungsgenerierung ermittelt wird, welcher der Verarbeitungseinheiten (VEA, VEB) welche Komponenten (A, B, C, D, E) zugeordnet wurden und welcher der Verarbeitungseinheiten (VEA, VEB) die zugehörigen redundanten Komponenten (A, B, C, D, E) zugeordnet wurden, aus welchen Informationen die Laufzeitumgebungen (RTE) physikalische Synchronisierungspfade für alle Synchronisierungspunkte ermitteln und entsprechenden Laufzeitumgebungscode generieren .
EP08760539A 2007-07-20 2008-06-05 Verfahren zur transparenten replikation einer softwarekomponente eines softwaresystems Withdrawn EP2168070A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102007033885A DE102007033885A1 (de) 2007-07-20 2007-07-20 Verfahren zur transparenten Replikation einer Softwarekomponente eines Softwaresystems
PCT/EP2008/056960 WO2009013055A2 (de) 2007-07-20 2008-06-05 Verfahren zur transparenten replikation einer softwarekomponente eines softwaresystems

Publications (1)

Publication Number Publication Date
EP2168070A2 true EP2168070A2 (de) 2010-03-31

Family

ID=40149028

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08760539A Withdrawn EP2168070A2 (de) 2007-07-20 2008-06-05 Verfahren zur transparenten replikation einer softwarekomponente eines softwaresystems

Country Status (5)

Country Link
US (1) US20100192164A1 (de)
EP (1) EP2168070A2 (de)
CN (1) CN101755256A (de)
DE (1) DE102007033885A1 (de)
WO (1) WO2009013055A2 (de)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101872375A (zh) * 2010-05-28 2010-10-27 浙江大学 基于索引的汽车电子软件组件模型仓库的实现方法
EP2469407A1 (de) * 2010-12-21 2012-06-27 Robert Bosch GmbH Verfahren zur Umgehung einer AUTOSAR-Softwarekomponente eines AUTOSAR-Softwaresystems
CN102073549B (zh) * 2011-01-18 2013-06-19 浙江大学 一种基于资源共享的组件间通信方法
CN102611741B (zh) * 2012-02-17 2015-03-18 浙江大学 从autosar系统配置模型中提取通信矩阵的方法
EP2662773B1 (de) * 2012-05-10 2016-07-20 Airbus Defence and Space GmbH Redundantes Mehrprozessorsystem und zugehöriges Verfahren
WO2016186531A1 (en) * 2015-05-19 2016-11-24 Huawei Technologies Co., Ltd. System and method for synchronizing distributed computing runtimes
US10417077B2 (en) 2016-09-29 2019-09-17 2236008 Ontario Inc. Software handling of hardware errors
US10509692B2 (en) * 2017-05-31 2019-12-17 2236008 Ontario Inc. Loosely-coupled lock-step chaining
US20200133267A1 (en) * 2018-10-25 2020-04-30 GM Global Technology Operations LLC Middleware support for fault-tolerant execution in an adaptive platform for a vehicle
EP4060487A1 (de) * 2021-03-17 2022-09-21 Aptiv Technologies Limited Elektronische steuereinheit, fahrzeug mit der elektronischen steuereinheit und computerimplementiertes verfahren
CN113687814A (zh) * 2021-08-05 2021-11-23 东风汽车集团股份有限公司 基于autosar架构的模型框架和接口文件的自动化实现方法
EP4530858B1 (de) * 2023-09-28 2026-04-15 Siemens Mobility GmbH Verfahren zum rechnergestützten durchführen eines technischen prozesses in verarbeitungseinheiten

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5021947A (en) * 1986-03-31 1991-06-04 Hughes Aircraft Company Data-flow multiprocessor architecture with three dimensional multistage interconnection network for efficient signal and data processing
CA2068048A1 (en) * 1991-05-06 1992-11-07 Douglas D. Cheung Fault tolerant processing section with dynamically reconfigurable voting
JP2500038B2 (ja) * 1992-03-04 1996-05-29 インターナショナル・ビジネス・マシーンズ・コーポレイション マルチプロセッサ・コンピュ―タ・システム、フォ―ルト・トレラント処理方法及びデ―タ処理システム
US5802265A (en) * 1995-12-01 1998-09-01 Stratus Computer, Inc. Transparent fault tolerant computer system
US6374364B1 (en) * 1998-01-20 2002-04-16 Honeywell International, Inc. Fault tolerant computing system using instruction counting
US6161196A (en) * 1998-06-19 2000-12-12 Lucent Technologies Inc. Fault tolerance via N-modular software redundancy using indirect instrumentation
US7359775B2 (en) * 2001-06-13 2008-04-15 Hunter Engineering Company Method and apparatus for information transfer in vehicle service systems
DE10142511B4 (de) * 2001-08-30 2004-04-29 Daimlerchrysler Ag Fehlerbehandlung von Softwaremodulen
US20030043824A1 (en) * 2001-08-31 2003-03-06 Remboski Donald J. Vehicle active network and device
US7415508B2 (en) * 2001-08-31 2008-08-19 Temic Automotive Of North America, Inc. Linked vehicle active networks
DE10243713B4 (de) * 2002-09-20 2006-10-05 Daimlerchrysler Ag Redundante Steuergeräteanordnung
US7093204B2 (en) * 2003-04-04 2006-08-15 Synplicity, Inc. Method and apparatus for automated synthesis of multi-channel circuits
DE10357118A1 (de) * 2003-12-06 2005-07-07 Daimlerchrysler Ag Laden von Software-Modulen
US7289889B2 (en) * 2004-04-13 2007-10-30 General Motors Corporation Vehicle control system and method
US9753754B2 (en) * 2004-12-22 2017-09-05 Microsoft Technology Licensing, Llc Enforcing deterministic execution of threads of guest operating systems running in a virtual machine hosted on a multiprocessor machine
US7554560B2 (en) * 2004-12-24 2009-06-30 Donald Pieronek System for defining network behaviors within application programs
US20060184296A1 (en) * 2005-02-17 2006-08-17 Hunter Engineering Company Machine vision vehicle wheel alignment systems
US7933966B2 (en) * 2005-04-26 2011-04-26 Hewlett-Packard Development Company, L.P. Method and system of copying a memory area between processor elements for lock-step execution
US7802232B2 (en) * 2006-03-31 2010-09-21 Microsoft Corporation Software robustness through search for robust runtime implementations
US20070288885A1 (en) * 2006-05-17 2007-12-13 The Mathworks, Inc. Action languages for unified modeling language model
US7837278B2 (en) * 2007-05-30 2010-11-23 Haldex Brake Products Ab Redundant brake actuators for fail safe brake system
WO2009090502A1 (en) * 2008-01-16 2009-07-23 Freescale Semiconductor, Inc. Processor based system having ecc based check and access validation information means

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
DE102007033885A1 (de) 2009-01-22
CN101755256A (zh) 2010-06-23
WO2009013055A2 (de) 2009-01-29
US20100192164A1 (en) 2010-07-29
WO2009013055A3 (de) 2009-12-23

Similar Documents

Publication Publication Date Title
WO2009013055A2 (de) Verfahren zur transparenten replikation einer softwarekomponente eines softwaresystems
EP2235628B1 (de) Kraftfahrzeug-steuervorrichtung
DE10211281B4 (de) Verfahren und Vorrichtung zur Synchronisation der Zykluszeit von mehreren Bussen sowie entsprechendes Bussystem
EP2030118B1 (de) Mehrprozessor-gateway
DE10243713B4 (de) Redundante Steuergeräteanordnung
WO2007134955A1 (de) Kommunikationsbaustein
WO2007134920A1 (de) Gateway zum datentransfer zwischen seriellen bussen
DE102012205163A1 (de) Kommunikationsanordnung und Verfahren zum Debugging bzw. zur Programmierung eines oder mehrerer Teilnehmer der Kommunikationsanordnung
EP1787204B1 (de) Botschaftsverwalter und verfahren zur steuerung des zugriffs auf daten eines botschaftsspeichers eines kommunikationsbausteins
DE102018001574A1 (de) Master-Slave Bussystem und Verfahren zum Betrieb eines Bussystems
EP2895925A1 (de) Kaskadiertes feldbussystem
DE102012205160A1 (de) Kommunikationsanordnung und Verfahren zur Konfiguration programmierbarer Hardware
EP3401742B1 (de) Automatisierungssystem und verfahren zum betrieb
DE102011004358B3 (de) Verfahren zum Übertragen von Daten über einen synchronen seriellen Datenbus
WO2025103867A1 (de) Verfahren zum bestimmen einer busteilnehmeranordnung in einem automatisierungsnetzwerk und automatisierungsnetzwerk
EP1881413B1 (de) Kommunikationssystem für den flexiblen Einsatz in unterschiedlichen Einsatzfällen der Automatisierungstechnik
EP3267271B1 (de) Automatisierungssystem und verfahren zum betrieb
DE102009000581A1 (de) Synchronisierung zweier Kommunikationsnetzwerke eines elektronischen Datenverarbeitungssystems
DE102021127310A1 (de) System und Verfahren zur Datenübertragung
EP4530858B1 (de) Verfahren zum rechnergestützten durchführen eines technischen prozesses in verarbeitungseinheiten
EP1430690A2 (de) Verfahren zum zugriff auf eine befehlseinheit für ein datennetz
AT412592B (de) Virtuelle netzwerke in einem zeitgesteuerten multicluster echtzeitsystem
DE102017200458A1 (de) Recheneinheit und Betriebsverfahren hierfür
DE102024133639A1 (de) Fahrzeug-netzwerksicherheitssystem mit zeitsynchronisationsbasiertem zählermodus
DE102022208383A1 (de) Verfahren zum Durchführen einer Datenübertragung

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20091221

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 HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA MK RS

17Q First examination report despatched

Effective date: 20100506

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

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