EP3308276A1 - Verfahren zur realistischen abschätzung von funktionslaufzeiten in pil simulation - Google Patents

Verfahren zur realistischen abschätzung von funktionslaufzeiten in pil simulation

Info

Publication number
EP3308276A1
EP3308276A1 EP16732488.8A EP16732488A EP3308276A1 EP 3308276 A1 EP3308276 A1 EP 3308276A1 EP 16732488 A EP16732488 A EP 16732488A EP 3308276 A1 EP3308276 A1 EP 3308276A1
Authority
EP
European Patent Office
Prior art keywords
function
control program
cache
development model
target processor
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
EP16732488.8A
Other languages
English (en)
French (fr)
Inventor
Frank Lünstroth
Sebastian Hillebrand
Karsten Fischer
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.)
Dspace GmbH
Dspace Digital Signal Processing and Control Engineering GmbH
Original Assignee
Dspace GmbH
Dspace Digital Signal Processing and Control Engineering 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 Dspace GmbH, Dspace Digital Signal Processing and Control Engineering GmbH filed Critical Dspace GmbH
Publication of EP3308276A1 publication Critical patent/EP3308276A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3457—Performance evaluation by simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/805—Real-time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/885—Monitoring specific for caches
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation

Definitions

  • the invention relates to the measurement and determination of runtimes of functions in a processor-in-the-loop (PIL) simulation.
  • PIL processor-in-the-loop
  • Control programs and the hardware, in particular of the processor used has become an integral part of development processes. It involves testing the combination of control program and hardware at various stages of development
  • control programs For the development of the control programs, z.
  • software code for control devices in the automotive industry model-based development tools are increasingly being used, such as for functional development or the construction or (simulative) testing (of parts) of a software architecture or an overall control program from software components for one or more control devices.
  • model-based development tools are increasingly being used, such as for functional development or the construction or (simulative) testing (of parts) of a software architecture or an overall control program from software components for one or more control devices. Examples of development environments for the
  • Abstraction layer as a specification at the level of textual software code such as C code.
  • this allows a better overview of the functionality of the control program, on the other hand, such models can be recycled better because they have a more general character due to the higher level of abstraction and are not yet defined in a concrete way of implementation and / or programming. Further advantages of using model-based development tools result from the fact that the functionality of the models is already at a high level
  • Abstraction level can be tested, i. the model can be run in so-called "model-in-the-loop" (MIL) tests and checked for errors in its functionality.
  • MIL model-in-the-loop
  • code for a control program can be automatically generated on the basis of a model by a code generator. For example, this is C code on one
  • ECU processor may expire or about VHDL code for an FPGA or ASIC.
  • the generated code can then be tested in a next test stage.
  • Software code testing is also referred to as software-in-the-loop (SIL).
  • SIL software-in-the-loop
  • the code can also be executed on an external target processor. In this case one speaks of one
  • processor-in-the-loop simulation which now also considers processor-specific properties and / or limitations, such as target compiler and processor clock rate.
  • instrumented program code As
  • the instrumented code is not fully optimized, but contains z.
  • Such information that the software developer obtains by recording data during test runs is referred to as "profiling or tracing information.” This profiling information can be transferred to a connected PC where it is available for analysis and evaluation purposes.
  • Processor needed time to execute a control program Specifically, an estimate for the 'worst case' scenario, ie the longest runtime, can be essential, in particular, for control units which control safety-relevant routines in real time, such as antilock braking system or airbag in a car, in order to obtain a guaranteed response or reaction time.
  • the execution times of control programs depend significantly on memory access times. Modern processors that require fast data processing are therefore equipped with so-called caches. Caches are latches in or near the processor core which allow the most recently processed data and instructions to be buffered from main memory (RAM / Flash / ROM), thus allowing for rapid reuse, eg, repeated execution of identical pieces of code in a loop.
  • a timer is started for each task and it is stopped each time the priority level is changed, and it is not run until the task resumes in the original priority level.
  • Simulations as they are the subject of the present application, run i.d.R. not in real time.
  • Task change does not occur. Furthermore, the simulated functionality of a model is often much smaller than the application on a later used control unit (since it is here i.d.R components / unit tests) and the entire program code thus u.U. fits in the cache.
  • "worst case” runtimes are determined by static analysis (without simulation), but these usually deliver excessive runtimes because they can not detect dependencies between different (external) input variables.
  • the object of the present invention is an improved method for estimating run times of individual functions of a control program executed on one
  • the object is achieved by a method for determining a transit time, which is required by a function of a control program for a control unit in a real-time system, executed on a target processor in a processor-in-the-loop (PIL).
  • PIL processor-in-the-loop
  • Simulation the method comprising:
  • Target processor according to the graphic development model, wherein the
  • Control program includes the function that the functionality of the selected
  • the method is characterized in that a first transit time measurement point associated with the beginning and a second transit time measurement point associated with the end of the function in the control program is inserted into the control program and immediately before the first runtime measurement point of the cache used for execution of the function of the target processor is set in a predetermined state. It further comprises the steps of: executing the control program on the target processor; wherein at the first and second transit time measurement points, runtime values are measured from which the transit time is determined.
  • control unit is a functional unit of a control unit, so that both an entire control unit or a single component of a control unit are included.
  • Control unit are represented in the graphic development model by means of function blocks in a block diagram and / or by function symbols (graphically or textually) in a list or tree view.
  • the graphical development model may be a development model for functional development. Or about one
  • a development model for building and / or testing a software architecture wherein software components, i. Software code for certain functionalities or
  • function blocks or symbols can represent complex functionality of an imaged control routine or be assigned in the form of program routines or software components.
  • the function blocks or function icons represent a subsystem of the mapped control unit. Such subsystems become
  • Control program realized. Function blocks or function symbols can also be represented or assigned subordinate functions within a functionality of the control unit, which are implemented as subfunctions in the executable control program.
  • the automatically generated (total) control program is created taking into account the properties of the respective target processor.
  • the invention is based on the finding that during the travel time determination of a function in the context of PIL simulations in the model-based development, cache effects occur, as occur in real-time systems, ie also in the later ECU application.
  • the invention is applicable to any forms of model-based ECU development models, whether configured as block diagrams, list or tree structures.
  • An advantage of the present invention is that the runtime of any function within a controller program can be determined for different, arbitrary cache states in the PIL simulation and thus at an early stage of the development effects that are to be expected in the later real-time system, can be considered. Thus, the simulation of cache effects already in the development stage of
  • Modeling can be integrated to simulate and measure their impact on the execution time on any functions within a ECU program code in a PIL simulation.
  • the user of the present invention thus does not have to manipulate executable program code by himself, but can already create the runtime measurement at the model level.
  • neither additional trace / debug hardware needs to be purchased and tethered, nor is the processor cache loaded by the necessary metering program code, which would otherwise corrupt the measurements or runtimes of the ECU program code to be measured, as compared to the run without measuring program code.
  • the function is one
  • Subfunction which is executed within a main function. While known systems can measure only the entire duration of a complete program run, it is possible with the present invention to determine a realistic runtime even for individual sub-functions. Especially for low-priority sub-functions, in later real-time systems reloading the cache after interruption can cause significant runtime changes. A specific analysis down to
  • the predetermined state maps a partially loaded cache.
  • a partially loaded cache is called if one function, ie all to execute the Function relevant instructions / data, some of which must be reloaded into the cache, which leads to a delay of the runtime.
  • the predetermined state maps an empty cache. This situation corresponds to the worst case scenario, which occurs when a function has to be completely loaded into the used cache.
  • memory space outside the cache is assigned to the values to be measured at the transit time measurement points. This ensures that the transit time measurement is not falsified by saving the values.
  • the partially loaded cache is statistically averaged over multiple
  • Simulation runs are mapped, whereby the cache is completely emptied only in a subset of the simulation runs before calling the function.
  • the partially loaded cache is mapped by inserting additional measurement code within the function to be measured.
  • additional cache load is obtained, which can lead to propagation delays depending on the capacity of the cache used.
  • a further aspect of the present invention is an apparatus for creating and executing a processor-in-the-loop (PIL) simulation for determining a propagation time, which is a function of a control program for a control unit in a
  • Real-time system is needed while running on a target processor in the PIL simulation, the device being means of creating or loading a graphical user interface
  • development model of the control unit in a development environment wherein the graphical development model depicts functionality of the control unit by means of function blocks and / or function symbols includes. Furthermore, the device has means for selecting at least one function block or symbol within the graphic development model, in particular means for selecting via a graphical
  • control program for executing on the target processor according to the graphical development model, the control program comprising the function that the
  • the device comprises transmission means for transmitting the generated
  • Control programs to the target processor means for executing the control program on the target processor, and is characterized in that the code generator is formed, a first transit time measurement point associated with the beginning and a second
  • Runtime measurement points in the execution of the control program measured values.
  • the user of the device can thus already pretend at the model level cache states for the execution of the control program and perform analyzes on realistic maturity or configure without having to manually manipulate generated control program code, which not only requires sufficient programming skills, but also the risk of incorrect interventions, as well a lack of reproducibility holds.
  • the device has means for evaluating the transit time measurements, in particular for graphical evaluation, wherein the means for evaluating the transit time measurement points are designed to annotate the function blocks or symbols in the original graphical development model with the evaluated transit time values of the corresponding functions.
  • the means for evaluating the transit time measurement points are designed to annotate the function blocks or symbols in the original graphical development model with the evaluated transit time values of the corresponding functions.
  • Control program code and the function block or icon in the graphical model can be formed, the representation of
  • FIG. 1 shows a model component of a control unit in a graphical manner
  • Figure 2 shows pseudocode as it could be generated by the code generator based on the graphical model, including inserted run time measurement function calls. Detailed description
  • FIG. 1 shows, by way of example, a graphic model of a control unit subsystem, which controls a specific functionality of a control unit, in a graphical model environment.
  • the input signals 1, which may originate from different sensors, are fed into the function block 2, a control logic, and the function block 3, a signal correction unit.
  • the control logic 2 processes the input signals 1 and forwards the processed signals as input signals to the function block 3, a signal correction unit. This process all input signals and gives them to the function block 4, one
  • Calculation unit continue.
  • the calculation unit 4 also receives input signals from the control logic 2. As the last unit in the illustrated subsystem of the
  • ECU model receives the function block 5, a calculation unit, the
  • the individual units can be selected via a graphical user interface and connected to one another with the aid of input means such as a mouse / touchpad or a keyboard.
  • the model developer can use a large number of predefined function blocks or define their own function blocks by defining input and output data as well as the functionality of a function block or an entire subsystem.
  • automatically executable program code which is optimized for the processors used in the later application, can then be generated from the defined graphical models.
  • Generated program code according to the exemplary model described above would consist of a main function for the control logic in which the subfunctions for the signal correction unit 3 as well as the calculation units 4 and 5 would be called.
  • model developer wishes to analyze the runtimes of individual model units, he can select them, for example, via a graphical user interface or a command line API.
  • code generation for the corresponding model, for later application of the generated and compiled program code on one
  • the program code is instrumentalized with transit time measurement points. These runtime measurement points are associated with the beginning and end of the corresponding call of the function associated with the selected one
  • FIG. 2 shows exemplary program code which maps the structure of the example model with transit time measurement points immediately before and after the function calls.
  • the measurement results are not stored in the cache used to execute the program code. This can be done either by freezing and thawing the cache by special processor instruction, or the measurement time calls are linked as a function to non-cached memory if the processor does not provide the freeze / thaw functionality.
  • a cache-neutral runtime of any model unit can be determined.
  • This "naked" runtime thus depicts a 'best case' scenario in which the function has already been completely loaded into the cache and the runtime only maps the computation time
  • a possible implementation could be via logging macros, which advantageously use preprocessor substitutions (preprocessor-defines) are implemented, which are automatically deleted when exporting the final program code to the controller, in particular by redefining as an empty instruction or by textual removal from the source code.
  • the user can set the function block or function icon in the model that before calling the corresponding
  • Subprograms of the cache should be emptied. This can e.g. by generating another macro in the code immediately before the function call which clears or invalidates the cache.
  • the runtime determined in this way reflects the worst case scenario in which the instructions and data belonging to a function must be completely reloaded for each (simulation) step.
  • the user can also specify a percentage cache load on the function block or function icon in the model. It can also be randomly applied during the simulation and thus clear / invalidate the cache before some (sub) function calls (e.g., cache is invalidated only every other pass). By averaging over several PIL simulation runs, the user receives such a
  • Such a gradual cache load could also be simulated by additional measurement code within a (sub) function, eg inserted at the beginning of a long loop. Furthermore, it is possible to differentiate between instruction and data cache in the above applications, ie to invalidate / load both or only one or none in order to obtain the most realistic estimate possible for the later runtime performance.
  • the present invention with its associated with the function to be measured transit time points makes it possible to illustrate not only the execution times as such but also the respective time at which a subfunction was calculated within the main function and which other subfunctions in a

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Bestimmung einer Laufzeit, welche von einer Funktion eines Steuerungsprogramms für eine Steuergeräteeinheit in einem Echtzeitsystem benötigt wird, ausgeführt auf einem Zielprozessor in einer Processor-in-the-loop (PIL) Simulation, wobei das Verfahren Erstellen oder Laden eines graphischen Entwicklungsmodells der Steuergeräteeinheit in eine Entwicklungsumgebung, wobei das graphische Entwicklungsmodell Funktionalität der Steuergeräteeinheit mittels Funktionsblöcken oder Funktionssymbolen im graphischen Entwicklungsmodell abbildet; Auswählen mindestens eines Funktionsblocks oder Funktionssymbols innerhalb des graphischen Entwicklungsmodells, insbesondere Auswählen eines Funktionsblocks oder Funktionssymbols über eine graphische Benutzeroberfläche; und automatisches Generieren des Steuerungsprogramms zur Ausführung auf dem Zielprozessor entsprechend dem graphischen Entwicklungsmodell, wobei das Steuerungsprogramm die Funktion umfasst, welche die Funktionalität des ausgewählten Funktionsblocks oder Funktionssymbols abbildet, umfasst. Ferner wird ein erster Laufzeitmesspunkt assoziiert mit dem Anfang und ein zweiter Laufzeitmesspunkt assoziiert mit dem Ende der Funktion im Steuerungsprogramm, in das Steuerungsprogramm und unmittelbar vor dem ersten Laufzeitmesspunkt der für eine Ausführung der Funktion wird der verwendete Cache des Zielprozessors in einen vorbestimmten Zustand versetzt und beim Ausführen des Steuerungsprograms auf dem Zielprozessor an dem ersten und zweiten Laufzeitmesspunkten Laufzeitwerte gemessen werden, aus denen die Laufzeit bestimmt wird.

Description

Verfahren zur realistischen Abschätzung von Funktionslaufzeiten in PIL Simulation
Gebiet der Erfindung
Die Erfindung betrifft die Messung und Bestimmung von Laufzeiten von Funktionen in einer Processor-in-the-loop (PIL) Simulation.
Hintergrund
Mit der Zunahme der Benutzung eingebetteter Systeme in zahlreichen Gebieten der Technik zur Ausführung von Überwachungs-, Steuerungs- oder Regelfunktionen und/oder zur Datenbzw. Signalverarbeitung, ist eine entsprechende Abstimmung zwischen verwendeten
Steuerungsprogrammen und der Hardware, insbesondere des verwendeten Prozessors zum festen Bestandteil von Entwicklungsprozessen geworden. Dabei ist ein Testen der Kombination aus Steuerungsprogramm und Hardware in verschiedenen Entwicklungsstadien
wünschenswert, um etwaige Probleme bei der Ausführung von Überwachungs-, Steuerungsoder Regelfunktionen frühzeitig zu erkennen und eine Anpassung entweder der verwendeten Hardware oder eine Anpassung der Funktionen vornehmen zu können.
Zur Entwicklung der Steuerungsprogramme, z. B. Software-Code für Steuergeräte in der Automobilindustrie, werden zunehmend modellbasierte Entwicklungswerkzeuge verwendet, etwa für die Funktionsentwicklung oder das Erstellen oder (simulative) Testen (von Teilen) einer Software-Architektur bzw. eines Gesamtsteuerungsprogramms aus Softwarekomponenten für eines oder mehrere Steuergeräte. Beispiele für Entwicklungsumgebungen für die
Funktionsentwicklung sind unter anderem Ascet von Etas, Labview von National Instruments, Simulink von The Mathworks oder Targetlink von dSPACE. Beispiele für
Entwicklungsumgebungen zum Erstellen und/oder Testen einer Steuergeräte-Software- Architektur aus Softwarekomponenten, d.h. Code-Komponenten, zur Erzeugung eines ausführbaren Gesamtsteuerungsprogramms sind Autosar Builder von Dassault Systemes, DaVinci Developer von Vector, Isolar von Etas, Rational Rhapsody von IBM, SystemDesk oder VEOS von dSPACE, o.ä.. Modellbasierte Entwicklungswerkzeuge ermöglichen es, die
Funktionalität des Steuerungsprogramms zunächst graphisch, in Form von Modellen, in der Regel mit Blockschaltbildern oder auch mit Hilfe von Listen- oder Baumstrukturen, zu spezifizieren. Die Spezifikation der Funktionalität erfolgt hierbei auf einer höheren
Abstraktionsebene als eine Spezifikation auf der Ebene von textuellem Software-Code wie etwa C-Code. Dies ermöglicht einerseits eine bessere Übersichtlichkeit über die Funktionalität des Steuerungsprogramms, andererseits lassen sich solche Modelle besser wiederverwerten, da sie aufgrund des höheren Abstraktionsniveaus allgemeineren Charakter haben und noch nicht auf eine konkrete Weise der Implementierung und/oder der Programmierung festgelegt sind. Weitere Vorteile bei der Verwendung modellbasierter Entwicklungswerkzeuge ergeben sich zum einen dadurch, dass die Funktionalität der Modelle schon auf einer hohen
Abstraktionsebene getestet werden kann, d.h. das Modell kann in sogenannten "Model-in-the- loop" (MIL)-Tests ausgeführt und auf Fehler seiner Funktionalität überprüft werden. Zum anderen kann auf Basis eines Modells von einem Codegenerator automatisch Code für ein Steuerungsprogramm erzeugt werden. Dies ist beispielsweise C-Code, der auf einem
Steuergeräte-Prozessor ablaufen kann oder etwa VHDL-Code für einen FPGA oder ASIC. Der erzeugte Code kann dann in einer nächsten Teststufe getestet werden. Das Testen des Software-Codes wird auch als "software-in-the-loop" (SIL) bezeichnet. Der Code wird dabei auf Fehler bezüglich seiner Funktionalität geprüft, indem nun auch Codierungs-spezifische
Eigenschaften und/oder Limitierungen Berücksichtigung finden, so zum Beispiel Verwendung von Festkomma statt Gleitkommazahlen. In einem weiteren Schritt kann der Code auch auf einem externen Zielprozessor ausgeführt werden. In diesem Fall spricht man von einer
"Processor-in-the-Loop"-Simulation, bei der nun auch Prozessor-spezifische Eigenschaften und/oder Limitierungen Berücksichtigung finden, so zum Beispiel Ziel-Compiler und Prozessor- Taktrate.
Zum Überprüfen der Funktionalität des Software-Codes ausgeführt auf dem Zielprozessor wird oft in einem ersten Schritt sogenannter "instrumentierter Programmcode" als
Steuerungsprogramm mittels des Codegenerators erzeugt und ausgeführt. Der instrumentierte Code ist nicht vollständig optimiert, sondern enthält z. B. zusätzliche Logging-Makros mittels derer während der Testphase nachgehalten wird, welche Programmteile oder Funktionen wie häufig durchlaufen oder aufgerufen werden und welche Werte für z.B. Ausgangsvariablen berechnet wurden. Solche Informationen, die der Software-Entwickler durch das Aufzeichnen von Daten bei Testdurchläufen erhält, werden als "Profiling- oder Tracing-Informationen" bezeichnet. Diese Profiling-Informationen können auf einen angeschlossenen PC übertragen werden, wo sie für Analyse- und Auswertungszwecke bereitstehen.
Von besonderem Interesse ist die Abschätzung von Laufzeitinformationen, d.h. der vom
Prozessor benötigten Zeit ein Steuerungsprogramm auszuführen. Speziell eine Abschätzung für das ,worst case' Szenario, also die längste Laufzeit kann insbesondere für Steuergeräte, welche sicherheitsrelevante Routinen in Echtzeit steuern, wie z.B. Antiblockiersystem oder Airbag in einem Auto, essentiell sein, um eine garantierte Antwort- bzw. Reaktionszeit zu erhalten. Die Ausführungszeiten von Steuerungsprogrammen hängen dabei maßgeblich von Speicherzugriffszeiten ab. Moderne Prozessoren, die eine schnelle Datenverarbeitung benötigen, sind daher mit sogenannten Caches ausgestattet. Caches sind Zwischenspeicher im oder nahe dem Prozessor-Kern, die die zuletzt verarbeiteten Daten und Befehle aus dem Hauptspeicher (RAM/Flash/ROM) Zwischenspeichern und so die rasche Wiederverwendung ermöglichen, z.B. bei wiederholter Ausführung von identischen Codeteilen in einer Schleife. Da aufgrund von Chip-Herstellungskosten die Größe des Cache begrenzt ist, ist es die Regel, dass der Speicherplatz nicht ausreicht die Instruktionen aller Tasks, Funktionen und/oder alle Daten .nebeneinander' und somit permanent in den Cache zu laden. Um eine garantierte oder zumindest optimierte Antwortzeit der (zeit)kritischen Funktionen zu ermöglichen, werden Funktionen in Echtzeitsystemen weiterhin oftmals priorisiert und Funktionen mit niedriger Priorität können unterbrochen werden, wenn eine Funktion mit höherer Priorität vorranging berechnet werden soll. Dies wird auch als Taskwechsel bezeichnet.
In der DE 10034459 A1 wird ein Verfahren zur Laufzeitmessung einer Task unter
Berücksichtigung auftretender Taskwechsel beschrieben. Dabei wird ein Zeitmesser für jede Task gestartet und dieser bei jedem Wechsel der Prioritätsebene angehalten und erst bei Wiederaufnahme der Task in der ursprünglichen Prioritätsebene weiterlaufen gelassen.
Bei Taskwechseln und auch bei Funktionen/Daten oberhalb der Cache-Größe kann es nun sein, dass ggf. früher mal bereits in den Cache geladene Instruktionen und/oder Daten, welche zur Ausführung einer Funktion benötigt werden, nun nicht mehr verfügbar sind und erneut aus dem Speicher in den Cache geladen werden müssen. Ein erneutes Laden der benötigten Instruktionen und/oder Daten geht somit z.B. zu Lasten der Laufzeit einer unterbrochenen Task. Ein erneutes Laden kann ferner nötig werden, wenn das Speicherabbild im Cache nicht mehr aktuell ist, d.h. Inkonsistenzen mit dem Hauptspeicher aufweist. In solchen Fällen bezeichnet man den Cache als invalide.
Simulationen, wie sie Gegenstand der vorliegenden Anmeldung sind, laufen i.d.R. nicht in Echtzeit. Insbesondere bei Entwicklungsumgebungen für die Funktionsentwicklung gibt es sowohl in SIL als auch in PIL Simulationen gewöhnlich nicht mehrere Tasks, so dass
Taskwechsel nicht auftreten. Ferner ist die simulierte Funktionalität eines Modells oftmals viel kleiner als die Applikation auf einem später eingesetzten Steuergerät (da es sich hier i.d.R. um Komponenten/Unit-Tests handelt) und der gesamte Programmcode somit u.U. in den Cache passt.
Um eine realistische Abschätzung der späteren Laufzeit im Echtzeitsystem zu erhalten, ist es daher wünschenswert zum einen den„best case" zu ermitteln, also die Zeit die der Prozessor benötigt eine einzelne Funktionalität exklusiv auszuführen, die den Cache komplett für sich nutzen kann. Zum anderen möchte man die Ausführungszeit im„worst case" messen, die für die Ausführung einer Funktion benötigt wird, wenn der Cache belastet oder invalide ist und die die Funktionalität abbildenden Instruktionen und Daten zunächst in den Cache geladen und anschließend ausgeführt werden muss.
Ein Einfügen von Mess-Code innerhalb der Funktion würde den Cache der CPU verändern und so die Messung verfälschen. Zum genauen Messen von Funktionen wird deshalb bisher z.B. externe Trace/Debug-Hardware an ein PIL-Evaluationsboard angeschlossen, welche
Messungen per Hardware-Schnittstelle während der PIL-Simulation durchführt.
Alternativ werden„worst case" Laufzeiten durch statische Analyse (ohne Simulation) ermittelt. Diese liefern aber meist zu hohe Laufzeiten, weil sie Abhängigkeiten zwischen verschiedenen (externen) Eingangsgrößen nicht erkennen können.
Die Erfindung im Überblick
Aufgabe der vorliegenden Erfindung ist ein verbessertes Verfahren zur Abschätzung von Laufzeiten einzelner Funktionen eines Steuerungsprogramms ausgeführt auf einem
Zielprozessor bereitzustellen.
Die Aufgabe wird gelöst durch ein Verfahren zur Bestimmung einer Laufzeit, welche von einer Funktion eines Steuerungsprogramms für eine Steuergeräteeinheit in einem Echtzeitsystem benötigt wird, ausgeführt auf einem Zielprozessor in einer Processor-in-the-loop (PIL)
Simulation, wobei das Verfahren umfasst:
• Erstellen oder Laden eines graphischen Entwicklungsmodells der Steuergeräteeinheit in eine Entwicklungsumgebung, wobei das graphische Entwicklungsmodell Funktionalität der Steuergeräteeinheit mittels Funktionsblöcken oder Funktionssymbolen im
graphischen Entwicklungsmodell abbildet;
· Auswählen mindestens eines Funktionsblocks oder Funktionssymbols innerhalb des graphischen Entwicklungsmodells, insbesondere Auswählen eines Funktionsblocks oder Funktionssymbols über eine graphische Benutzeroberfläche;
• automatisches Generieren des Steuerungsprogramms zur Ausführung auf dem
Zielprozessor entsprechend dem graphischen Entwicklungsmodell, wobei das
Steuerungsprogramm die Funktion umfasst, welche die Funktionalität des ausgewählten
Funktionsblocks oder Funktionssymbols abbildet.
Das Verfahren ist dadurch gekennzeichnet, dass ein erster Laufzeitmesspunkt assoziiert mit dem Anfang und ein zweiter Laufzeitmesspunkt assoziiert mit dem Ende der Funktion im Steuerungsprogramm, in das Steuerungsprogramm eingefügt wird und wobei unmittelbar vor dem ersten Laufzeitmesspunkt der für eine Ausführung der Funktion verwendete Cache des Zielprozessors in einen vorbestimmten Zustand versetzt wird. Ferner umfasst es die Schritte: • Ausführen des Steuerungsprogramms auf dem Zielprozessor; wobei an dem ersten und zweiten Laufzeitmesspunkten Laufzeitwerte gemessen werden, aus denen die Laufzeit bestimmt wird.
Im Rahmen der vorliegenden Erfindung wird mit Steuergeräteeinheit eine funktionale Einheit eines Steuergeräts bezeichnet, so dass sowohl ein gesamtes Steuergerät oder auch eine einzelne Komponente eines Steuergeräts umfasst sind. Funktionalitäten der
Steuergeräteeinheit werden im graphischen Entwicklungsmodell mittels Funktionsblöcken in einem Blockdiagramm und/oder durch Funktionssymbole (graphisch oder textuell) in einer Listen- oder Baumstrukturansicht dargestellt. Das graphische Entwicklungsmodell kann beispielsweise ein Entwicklungsmodell zur Funktionsentwicklung sein. Oder etwa ein
Entwicklungsmodell zum Erstellen und/oder zum Testen einer Software-Architektur, wobei im Modell Softwarekomponenten, d.h. Softwarecode für bestimmte Funktionalitäten bzw.
Funktionen, zu einem (Gesamt-)Steuerungsprogramm zusammengesetzt werden, für das ein Codegenerator den Rahmen- und Kommunikationscode bzw. die Laufzeitumgebung generiert. Dabei können Funktionsblöcke oder -symbole komplexe Funktionalität einer abgebildeten Steuerungsroutine darstellen bzw. in Form von Programmroutinen bzw. Softwarekomponenten zugewiesen bekommen. Im Allgemeinen stellen die Funktionsblöcke oder Funktionssymbole ein Subsystem der abgebildeten Steuergeräteeinheit dar. Solche Subsysteme werden
beispielsweise als übergeordnete Funktionen im ausführbaren Programmcode des
Steuerungsprogramms realisiert. Funktionsblöcke oder Funktionssymbole können auch untergeordnete Funktionen innerhalb einer Funktionalität der Steuergeräteeinheit darstellen bzw. zugewiesen bekommen, welche als Unterfunktionen im ausführbaren Steuerungsprogram realisiert werden. Das automatisch generierte (Gesamt-)Steuerungsprogramm wird unter Berücksichtigung der Eigenschaften des jeweiligen Zielprozessors erstellt.
Der Erfindung liegt die Erkenntnis zugrunde, dass bei der Laufzeitbestimmung einer Funktion im Rahmen von PIL-Simulationen in der modellbasierten Entwicklung Cache-Effekte, wie sie in Echtzeitsystemen, also auch in der späteren Steuergeräte-Applikation, auftreten,
Berücksichtigung finden müssen, um eine realistische Abschätzung der benötigten Laufzeiten zu erhalten und gegebenenfalls den Prozessor für das Echtzeit-Steuerungssystem
entsprechend dimensionieren zu können oder frühzeitig Anpassung an den Regelungsroutinen vornehmen zu können. Die Erfindung ist auf jegliche Formen von Modellen zur modellbasierten Steuergeräteentwicklung anwendbar, egal ob diese in Form von Blockdiagrammen, Listen- oder Baumstrukturen ausgestaltet sind. Ein Vorteil der vorliegenden Erfindung besteht darin, dass die Laufzeit einer beliebigen Funktion innerhalb eines Steuergeräteprogramms für verschiedene, beliebige Cache-Zustände in der PIL Simulation ermittelt werden kann und damit bereits in einem frühen Stadium der Entwicklung Effekte, welche im späteren Echtzeitsystem zu erwarten sind, berücksichtigt werden können. Damit kann die Nachbildung von Cache-Effekten bereits in das Entwicklungsstadium der
Modellierung integriert werden, um deren Auswirkungen auf die Ausführungszeit auf beliebige Funktionen innerhalb eines Steuergeräteprogrammcodes im Rahmen einer PIL-Simulation simulieren und messen zu können. Der Anwender der vorliegenden Erfindung muss damit nicht eigenhändig lauffähigen Programmcode manipulieren, sondern kann die Laufzeitmessung bereits auf Modellebene anlegen. Es muss ferner weder zusätzliche Trace/Debug-Hardware gekauft und angebunden werden, noch wird der Prozessor-Cache durch den notwendigen Mess-Programmcode belastet, was sonst zur Verfälschung der Messungen bzw. der Laufzeiten des zu vermessenden Steuergeräteprogrammcodes führen würde, im Vergleich zum Lauf ohne Mess-Programmcode.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung ist die Funktion eine
Unterfunktion, welche innerhalb einer Hauptfunktion ausgeführt wird. Während bekannte Systeme lediglich die gesamte Laufzeit eines kompletten Programmdurchlaufes messen können, ist es mit der vorliegenden Erfindung möglich, auch für einzelne Unterfunktionen eine realistische Laufzeit zu ermitteln. Speziell für Unterfunktionen niedriger Priorität kann in späteren Echtzeitsystemen ein erneutes Laden in den Cache nach Unterbrechung signifikante Laufzeitveränderungen hervorrufen. Eine spezifische Analyse bis hinunter auf
Unterfunktionsebenen ist damit wünschenswert, um eine detaillierte Darstellung der
Laufzeitabläufe und eventueller Laufzeitengpässe zu erhalten.
Ein weiterer Vorteil ergibt sich daraus, dass die Messwerte immer zu Beginn und Ende eines Funktions- bzw. Unterfunktionsaufrufes aufgezeichnet werden. So lässt sich neben den Ausführungszeiten als solche auch der jeweilige Zeitpunkt veranschaulichen, zu welchem eine Unterfunktion innerhalb der Hauptfunktion gerechnet wurde und auch welche Unterfunktionen in einer Unterfunktion aufgerufen wurden. Da es ferner zu jedem Rechenschritt eine
Ausführungszeit gibt, können daraus sowohl eine mittlere Ausführungszeit, als auch die minimale und maximale Laufzeit berechnet werden.
In einer ersten Fortbildung einer der vorangegangenen Ausführungsformen der vorliegenden Erfindung bildet der vorbestimmte Zustand einen teilweise belasteten Cache ab. Von einem teilweise belasteten Cache spricht man, wenn eine Funktion, d.h. sämtliche zum Ausführen der Funktion relevanten Instruktionen/Daten, teilweise erneut in den Cache geladen werden müssen, was zu einer Verzögerung der Laufzeit führt.
In einer alternativen, zweiten Fortbildung einer der vorangegangenen Ausführungsformen der vorliegenden Erfindung bildet der vorbestimmte Zustand einen leeren Cache ab. Diese Situation entspricht dem ,worst case'- Szenario, welches dann auftritt, wenn eine Funktion komplett in den verwendeten Cache geladen werden muss.
In einer weiteren Fortbildung einer der vorangegangenen Ausführungsformen der vorliegenden Erfindung wird an den Laufzeitmesspunkten zu messenden Werten Speicherplatz außerhalb des Caches zugeordnet. Damit wird sichergestellt, dass die Laufzeitmessung durch das Abspeichern der Werte nicht verfälscht wird.
In einer weiteren Fortbildung der bevorzugten Ausführungsform der vorliegenden Erfindung, wird der teilweise belastete Cache durch eine statistische Mittelung über mehrere
Simulationsläufe abgebildet, wobei der Cache nur in einer Teilmenge der Simulationsläufe vor Aufruf der Funktion vollständig geleert wird.
In einer alternativen Fortbildung der bevorzugten Ausführungsform der vorliegenden Erfindung wird der teilweise belastete Cache durch Einfügen zusätzlichen Messcodes innerhalb der zu messenden Funktion abgebildet. Je nach Umfang des verwendeten Messcodes in Bezug auf Cache Zugriffe wird damit eine zusätzliche Cachebelastung erwirkt, die abhängig von der Kapazität des verwendeten Caches zu Laufzeitverzögerungen führen kann.
Einen weiteren Aspekt der vorliegenden Erfindung bildet eine Vorrichtung zum Erstellen und Ausführen einer Processor-in-the-loop (PIL) Simulation zur Bestimmung einer Laufzeit, welche von einer Funktion eines Steuerungsprogramms für eine Steuergeräteeinheit in einem
Echtzeitsystem benötigt wird, während der Ausführung auf einem Zielprozessor in der PIL Simulation, wobei die Vorrichtung Mittel zum Erstellen oder Laden eines graphischen
Entwicklungsmodells der Steuergeräteeinheit in eine Entwicklungsumgebung, wobei das graphische Entwicklungsmodell Funktionalität der Steuergeräteeinheit mittels Funktionsblöcken und/oder Funktionssymbolen abbildet, umfasst. Ferner weist die Vorrichtung Mittel auf zum Auswählen mindestens eines Funktionsblocks oder -symbols innerhalb des graphischen Entwicklungsmodells, insbesondere Mittel zum Auswählen über eine graphische
Benutzeroberfläche, sowie einen Codegenerator zur automatischen Generierung des
Steuerungsprogramms zur Ausführung auf dem Zielprozessor entsprechend dem graphischen Entwicklungsmodell, wobei das Steuerungsprogramm die Funktion umfasst, welche die
Funktionalität des ausgewählten Funktionsblocks oder -symbols abbildet. Darüber hinaus umfasst die Vorrichtung Übertragungsmittel zum Übertragen des generierten
Steuerungsprograms auf den Zielprozessor, Mittel zum Ausführen des Steuerungsprogramms auf dem Zielprozessor, und ist dadurch gekennzeichnet, dass der Codegenerator ausgebildet ist, einen erster Laufzeitmesspunkt assoziiert mit dem Anfang und einen zweiten
Laufzeitmesspunkt assoziiert mit dem Ende der Funktion in das Steuerungsprogramm einzufügen und den für eine Ausführung der Funktion verwendeten Cache des Zielprozessors unmittelbar vor dem ersten Laufzeitmesspunkt in einen vorbestimmten Zustand zu versetzten, wobei die Vorrichtung ferner Mittel zum Empfangen und Auswerten der an den
Laufzeitmesspunkten bei der Ausführung des Steuerungsprogramms gemessenen Werte aufweist.
Der Benutzer der Vorrichtung kann somit bereits auf Modellebene Cachezustände für die Ausführung des Steuerungsprogramms vorgeben und Analysen bezüglich realistischer Laufzeiten durchführen bzw. konfigurieren ohne dabei generierten Steuerprogrammcode händisch manipulieren zu müssen, was nicht nur ausreichende Programmierkenntnisse erfordert, sondern auch das Risiko von fehlerhaften Eingriffen, sowie einer mangelnden Reproduzierbarkeit birgt.
In einer bevorzugten Ausführungsform weist die Vorrichtung Mittel zur Auswertung der Laufzeitmessungen auf, insbesondere zur graphischen Auswertung, wobei die Mittel zur Auswertung der Laufzeitmesspunkte ausgebildet sind, die Funktionsblöcke oder -symbole im ursprünglichen graphischen Entwicklungsmodell mit den ausgewerteten Laufzeitwerten der entsprechenden Funktionen zu annotieren. Hierzu wird während der PIL Simulation eine Datei erzeugt, welche die Laufzeitwerte der entsprechenden Funktion im ausgeführten
Programmcode zuordnet. Über ein weiteres Mapping zwischen Funktion im
Steuerungsprogramm-Code und dem Funktionsblock oder -symbol im graphischen Modell, kann die graphische Benutzeroberfläche ausgebildet werden, die Darstellung der
Funktionsblöcke oder Funktionssymbole mit den Laufzeiten zu annotieren bzw. entsprechende Informationen im graphischen Modell zu hinterlegen.
Beschreibung der Figuren
Bevorzugte Ausführungsformen der vorliegenden Erfindung werden beispielhaft anhand der beiliegenden Figuren beschrieben.
Figur 1 zeigt eine Modellkomponente einer Steuergeräteeinheit in einer graphischen
Modellumgebung mit verschiedenen Funktionsblöcken
Figur 2 zeigt Pseudocode wie er vom Codegenerator auf Basis des graphischen Modells generiert werden könnte, inklusive eingefügter Laufzeitmessfunktions-Aufrufe. Detaillierte Beschreibung
Die folgende Beschreibung dient der Veranschaulichung einer beispielhaften Ausgestaltung der vorliegenden Erfindung, hat darüber hinaus jedoch keinen einschränkenden Charakter.
Figur 1 zeigt beispielhaft ein graphisches Modell eines Steuergeräte-Subsystems, welche eine bestimmte Funktionalität eines Steuergeräts steuert, in einer graphischen Modellumgebung. Die Eingangssignale 1 , welche von verschiedenen Sensoren stammen können, werden in den Funktionsblock 2, eine Steuerungslogik, und den Funktionsblock 3, eine Signalkorrektureinheit, eingespeist. Die Steuerungslogik 2 verarbeitet die Eingangssignale 1 und gibt die verarbeiteten Signale als Eingangssignale an den Funktionsblock 3, eine Signalkorrektureinheit, weiter. Diese verarbeitet alle Eingangssignale und gibt diese an den Funktionsblock 4, eine
Berechnungseinheit, weiter. Die Berechnungseinheit 4 erhält ebenfalls noch Eingangssignale von der Steuerungslogik 2. Als letzte Einheit in dem dargestellten Subsystem des
Steuergerätemodells, erhält der Funktionsblock 5, eine Berechnungseinheit, die
Ausgangssignale der Berechnungseinheit 4 sowie zwei Ausgangssignale der Steuerungslogik 2 und berechnet darauf den Ausgabewert des Subsystems 6.
Zur Generierung eines solchen Modells können die einzelnen Einheiten über eine graphische Benutzeroberfläche ausgewählt und mit Hilfe von Eingabemitteln wie einer Mouse/Touchpad oder einem Keyboard miteinander verbunden werden. Der Modellentwickler kann sich dabei einer Vielzahl vordefinierter Funktionsblöcke bedienen oder eigene Funktionsblöcke definieren, indem er Eingangs- und Ausgangsdaten, sowie die Funktionalität eines Funktionsblockes oder eines ganzen Subsystems definiert. In modernen Modellentwicklungsumgebungen kann dann aus den definierten graphischen Modellen automatisch lauffähiger Programmcode, welcher für die bei der späteren Anwendung verwendeten Prozessoren optimiert ist, generiert werden. Generierter Programmcode gemäß dem oben beschriebenen beispielhaften Modell würde aus einer Hauptfunktion für die Steuerungslogik bestehen, in der die Unterfunktionen für die Signalkorrektureinheit 3 sowie die Berechnungseinheiten 4 und 5 aufgerufen würden.
Wünscht der Modellentwickler eine Analyse der Laufzeiten einzelner Modelleinheiten, kann er diese zum Beispiel über eine graphische Benutzeroberfläche oder eine Kommandozeilen-API auswählen. Bei einer anschließenden Codegenerierung für das entsprechende Modell, zur späteren Anwendung des generierten und kompilierten Programmcodes auf einem
vorgesehenen spezifischen Prozessor vorgegebener Kapazität, wird der Programmcode mit Laufzeitmesspunkten instrumentalisiert. Diese Laufzeitmesspunkte sind mit dem Anfang und Ende des entsprechenden Aufrufes der Funktion assoziiert, die mit dem ausgewählten
Funktionsblock dargestellt ist. Figur 2 zeigt beispielhaften Programmcode, welcher die Struktur des Beispielmodells mit Laufzeitmesspunkten unmittelbar vor und nach den Funktionsaufrufen abbildet.
Um die Messung der Laufzeit nicht zu verfälschen, werden die Messergebnisse nicht im für die Ausführung des Programmcodes verwendeten Cache gespeichert. Dies kann entweder durch das Einfrieren und Auftauen des Cache per spezieller Prozessor-Instruktion erfolgen, oder die Messzeitaufrufe werden als Funktion in einen nicht im Cache liegenden Speicher gelinkt, wenn der Prozessor die Einfrier-/Auftauen Funktionalität nicht bietet.
Somit lässt sich eine Cache-neutrale Laufzeit einer beliebigen Modelleinheit ermitteln. Diese „nackte" Laufzeit bildet somit ein 'best case' Szenario ab, in welchem die Funktion bereits vollständig in den Cache geladen wurde und die Laufzeit lediglich die Rechenzeit abbildet. Eine mögliche Implementierung könnte über logging-Makros erfolgen, die vorteilhafterweise über Präprozessor-Ersetzungen (preprocessor-defines) implementiert werden, welche beim Export des finalen Programmcodes auf das Steuergerät automatisch gelöscht werden, insbesondere durch ein Umdefinieren als leere Anweisung oder durch textuelles Entfernen aus dem Quellcode.
Für die Messung der Laufzeit unter Cache-Belastung kann der Nutzer an dem Funktionsblock oder Funktionssymbol im Modell einstellen, dass vor dem Aufruf des entsprechenden
Unterprograms der Cache geleert werden soll. Dies kann z.B. durch Generierung eines weiteren Makros in den Code unmittelbar vor dem Funktionsaufruf erfolgen, welches den Cache leert bzw. invalidiert.
Die so ermittelte Laufzeit spiegelt das ,worst case'-Szenario wieder, in welchem die zu einer Funktion gehörenden Instruktionen und Daten jeweils pro (Simulations-) Schritt komplett neu geladen werden muss.
Um eine graduelle Cache-Belastung von z.B. anderen höher-priorisierten Tasks mit zu simulieren, kann der Nutzer auch eine prozentuale Cache-Belastung an dem Funktionsblock oder Funktionssymbol im Modell vorgeben. Diese kann ferner randomisiert während der Simulation angewendet werden und den Cache somit vor einigen (Unter-)Funktionsaufrufen löschen/invalidieren (z.B. Cache wird nur bei jedem zweiten Durchlauf invalidiert). Durch Mittelung über mehrere PIL Simulationsdurchläufe erhält der Anwender so eine
durchschnittliche Laufzeit für die Ausführung einer bestimmten Funktion.
Eine solche graduelle Cache-Belastung könnte auch durch zusätzlichen Mess-Code innerhalb einer (Unter-)Funktion simuliert werden, z.B. eingefügt am Anfang einer langen Schleife. Ferner ist es möglich bei den voranstehenden Anwendungen zwischen Instruktions- und Datencache zu unterscheiden, d.h. beide zu invalidieren/belasten oder je nur einen oder keinen, um eine möglichst realistische Abschätzung für die spätere Laufzeitperformance zu erhalten. Die vorliegende Erfindung mit ihren mit der zu messenden Funktion assoziierten Laufzeitmesspunkten ermöglicht es, neben den Ausführungszeiten als solchen auch den jeweiligen Zeitpunkt zu veranschaulichen, zu welchem eine Unterfunktion innerhalb der Hauptfunktion gerechnet wurde und auch welche weiteren Unterfunktionen in einer
Unterfunktion aufgerufen wurden. Da es ferner zu jedem Rechenschritt eine Ausführungszeit gibt, können daraus sowohl eine mittlere Ausführungszeit, als auch die minimale und maximale Laufzeit berechnet werden.

Claims

Ansprüche
1. Verfahren zur Bestimmung einer Laufzeit, welche von einer Funktion eines Steuerungsprogramms für eine Steuergeräteeinheit in einem Echtzeitsystem benötigt wird, ausgeführt auf einem Zielprozessor in einer Processor-in-the-loop (PIL) Simulation, wobei das Verfahren umfasst:
Erstellen oder Laden eines graphischen Entwicklungsmodells der Steuergeräteeinheit in eine Entwicklungsumgebung, wobei das graphische Entwicklungsmodell Funktionalität der Steuergeräteeinheit mittels Funktionsblöcken oder Funktionssymbolen im graphischen Entwicklungsmodell abbildet;
Auswählen mindestens eines Funktionsblocks oder Funktionssymbols innerhalb des graphischen Entwicklungsmodells, insbesondere Auswählen eines Funktionsblocks oder Funktionssymbols über eine graphische Benutzeroberfläche;
automatisches Generieren des Steuerungsprogramms zur Ausführung auf dem Zielprozessor entsprechend dem graphischen Entwicklungsmodell, wobei das Steuerungsprogramm die Funktion umfasst, welche die Funktionalität des ausgewählten Funktionsblocks oder Funktionssymbols abbildet,
dadurch gekennzeichnet, dass ein erster Laufzeitmesspunkt assoziiert mit dem Anfang und ein zweiter Laufzeitmesspunkt assoziiert mit dem Ende der Funktion im Steuerungsprogramm, in das Steuerungsprogramm eingefügt wird und wobei unmittelbar vor dem ersten Laufzeitmesspunkt der für eine Ausführung der Funktion verwendete Cache des Zielprozessors in einen vorbestimmten Zustand versetzt wird;
Ausführen des Steuerungsprograms auf dem Zielprozessor; wobei an dem ersten und zweiten Laufzeitmesspunkten Laufzeitwerte gemessen werden, aus denen die Laufzeit bestimmt wird.
2. Verfahren nach Anspruch 1 , wobei die Funktion eine Unterfunktion ist, welche innerhalb einer übergeordneten Funktion ausgeführt wird.
3. Verfahren nach Anspruch 1 oder 2, wobei der vorbestimmte Zustand einen teilweise belasteten Cache abbildet.
4. Verfahren nach Anspruch 3, wobei der teilweise belastete Cache durch eine statistische Mittelung über mehrere Läufe abgebildet wird, und der Cache nur in einer Teilmenge der Läufe vor Aufruf der Funktion geleert wird.
5. Verfahren nach Anspruch 3, wobei der teilweise belastete Cache durch Einfügen zusätzlichen Messcodes innerhalb der zu messenden Funktion abgebildet wird.
6. Verfahren nach Anspruch 1 oder 2, wobei der vorbestimmte Zustand einen leeren Cache abbildet.
7. Verfahren nach einem der vorangegangenen Ansprüche, wobei an den Laufzeitmesspunkten zu messenden Werten Speicherplatz außerhalb des Caches zugewiesen ist.
8. Vorrichtung zum Erstellen und Ausführen einer Processor-in-the-loop (PIL) Simulation zur Bestimmung einer Laufzeit, welche von einer Funktion eines Steuerungsprogramms für eine Steuergeräteeinheit in einem Echtzeitsystem benötigt wird, während der Ausführung auf einem Zielprozessor in der PIL Simulation, wobei die Vorrichtung umfasst:
Mittel zum Erstellen oder Laden eines graphischen Entwicklungsmodells der Steuergeräteeinheit in eine Entwicklungsumgebung, wobei das graphische Entwicklungsmodell Funktionalität der Steuergeräteeinheit mittels Funktionsblöcken oder Funktionssymbolen abbildet;
Mittel zum Auswählen mindestens eines Funktionsblocks oder Funktionssymbols innerhalb des graphischen Entwicklungsmodells, insbesondere Mittel zum Auswählen über eine graphische Benutzeroberfläche;
Codegenerator zur automatischen Generierung des Steuerungsprogramms zur Ausführung auf dem Zielprozessor entsprechend dem graphischen Entwicklungsmodell, wobei das Steuerungsprogramm die Funktion umfasst, welche die Funktionalität des ausgewählten Funktionsblocks oder Funktionssymbols abbildet,
Übertragungsmittel zum Übertragen des generierten Steuerungsprograms auf den Zielprozessor;
Mittel zum Ausführen des Steuerungsprogramms auf dem Zielprozessor;
dadurch gekennzeichnet, dass der Codegenerator ausgebildet ist, einen ersten Laufzeitmesspunkt assoziiert mit dem Anfang und einen zweiten Laufzeitmesspunkt assoziiert mit dem Ende der Funktion in das Steuerungsprogramm einzufügen und den für eine Ausführung der Funktion verwendeten Cache des Zielprozessors unmittelbar vor dem ersten Laufzeitmesspunkt in einen vorbestimmten Zustand zu versetzten, wobei die Vorrichtung ferner Mittel zum Empfangen und Auswerten der an den Laufzeitmesspunkten bei der Ausführung des Steuerungsprogramms gemessenen Werte aufweist.
9. Vorrichtung nach Anspruch 8 wobei die Mittel zum Auswerten der an den Laufzeitmesspunkten gemessenen Werte ausgebildet sind, die Funktionsblöcke oder Funktionssymbole im graphischen Entwicklungsmodell mit den ausgewerteten Laufzeitwerten der entsprechenden Funktionen zu annotieren.
10. Vorrichtung nach Anspruch 9 wobei sich der Zielprozessor auf einem Evaluationsboard befindet.
EP16732488.8A 2015-06-12 2016-06-09 Verfahren zur realistischen abschätzung von funktionslaufzeiten in pil simulation Withdrawn EP3308276A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP15171801.2A EP3104278A1 (de) 2015-06-12 2015-06-12 Verfahren zur realistischen abschätzung von funktionslaufzeiten in pil simulation
PCT/EP2016/063114 WO2016198503A1 (de) 2015-06-12 2016-06-09 Verfahren zur realistischen abschätzung von funktionslaufzeiten in pil simulation

Publications (1)

Publication Number Publication Date
EP3308276A1 true EP3308276A1 (de) 2018-04-18

Family

ID=53483689

Family Applications (2)

Application Number Title Priority Date Filing Date
EP15171801.2A Withdrawn EP3104278A1 (de) 2015-06-12 2015-06-12 Verfahren zur realistischen abschätzung von funktionslaufzeiten in pil simulation
EP16732488.8A Withdrawn EP3308276A1 (de) 2015-06-12 2016-06-09 Verfahren zur realistischen abschätzung von funktionslaufzeiten in pil simulation

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP15171801.2A Withdrawn EP3104278A1 (de) 2015-06-12 2015-06-12 Verfahren zur realistischen abschätzung von funktionslaufzeiten in pil simulation

Country Status (3)

Country Link
US (1) US20180157571A1 (de)
EP (2) EP3104278A1 (de)
WO (1) WO2016198503A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016211386A1 (de) * 2016-06-14 2017-12-14 Robert Bosch Gmbh Verfahren zum Betreiben einer Recheneinheit
CN107678955B (zh) * 2017-09-22 2021-02-23 苏州浪潮智能科技有限公司 一种功能接口时延的计算方法、装置、设备及存储介质
CN110457196B (zh) * 2019-08-16 2023-10-24 腾讯科技（深圳）有限公司 函数执行时间的获取方法及装置
AU2021434319A1 (en) * 2021-03-19 2023-09-28 Lexmark International, Inc. Security device computation matching

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6088525A (en) * 1997-06-19 2000-07-11 Hewlett-Packard Company Loop profiling by instrumentation
EP0992905A3 (de) * 1998-10-06 2002-11-27 Texas Instruments Inc. Cachespeicher-Fehlgriffbenchmarkierung
GB2366643B (en) * 2000-05-25 2002-05-01 Siroyan Ltd Methods of compressing instructions for processors
DE10034459A1 (de) 2000-07-15 2002-01-24 Bosch Gmbh Robert Verfahren und Vorrichtung zur Messung der Laufzeit einer Task in einem Echtzeitsystem
DE102010009994A1 (de) * 2010-03-02 2011-09-08 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren zur Optimierung eines Steuerungsprogramms für Aktuatoren
US8856767B2 (en) * 2011-04-29 2014-10-07 Yahoo! Inc. System and method for analyzing dynamic performance of complex applications
US9182958B2 (en) * 2013-09-03 2015-11-10 Atmel Corporation Software code profiling
US9652213B2 (en) * 2014-10-23 2017-05-16 National Instruments Corporation Global optimization and verification of cyber-physical systems using floating point math functionality on a system with heterogeneous hardware components

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Simulink - Dynamic System Simulation for MATLAB", 1 January 1997 (1997-01-01), XP055507400, Retrieved from the Internet <URL:http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.195.6342&rep=rep1&type=pdf> [retrieved on 20180917] *

Also Published As

Publication number Publication date
WO2016198503A1 (de) 2016-12-15
EP3104278A1 (de) 2016-12-14
US20180157571A1 (en) 2018-06-07

Similar Documents

Publication Publication Date Title
EP3308276A1 (de) Verfahren zur realistischen abschätzung von funktionslaufzeiten in pil simulation
EP2442248B1 (de) Kopplungsmethodik für nicht-iterative Co-Simulation
EP2706421B1 (de) Verfahren zur rechnergestützten Erzeugung mindestens eines Teils eines ausführbaren Steuerungsprogramms
EP2897011B1 (de) Verfahren und Simulationsanordnung zur Simulation einer automatisierten Industrieanlage
EP3001313A1 (de) Verfahren zur Simulation eines Anwendungsprogramms eines elektronischen Steuergeräts auf einem Computer
DE102014102551A1 (de) Maschine und Verfahren zum Evaluieren von fehlschlagenden Softwareprogrammen
DE102006041444B4 (de) Schaltungsanordnung und Verfahren zum Erfassen einer Ausführungszeit eines Befehls in einem Rechnersystem
DE112015007179T5 (de) Informationsverarbeitungsvorrichtung, Informationsverarbeitungsverfahren und Informationsverarbeitungsprogramm
EP3306295B1 (de) Verfahren und vorrichtung zum testen elektronischer steuerungen, insbesondere zum testen von automobilsteuerungen
DE102017213510A1 (de) Verfahren und Vorrichtung zum Erzeugen eines maschinellen Lernsystems, und virtuelle Sensorvorrichtung
DE112013006981T5 (de) Steuersystem Prüfmittel
DE202016008563U1 (de) Konfigurationssystem zum Konfigurieren eines für das Testen eines Steuergeräts eingerichteten Testgeräts
EP2592504B1 (de) Verfahren zur Abschätzung eines Ressourcenverbrauchs bei der Erzeugung eines Steuergeräteprogrammcodes
DE102020102996A1 (de) Verfahren für einen integrierten Entwurf zur Modellierung, Simulation und Test einer Echtzeit-Architektur innerhalb einer modellbasierten System- und Softwareentwicklung
EP2759939A1 (de) Verfahren zum Manipulieren einer Speicheroperation eines Steuergeräteprogramms auf einen virtuellen oder realen Speicher
DE102010014720A1 (de) Verfahren zum Verifizieren eines aus einem Quellmodell generierten Zielprogramms
EP3001318A1 (de) Bestimmung von Signalen für Readback aus FPGA
DE102019219730A1 (de) Verfahren und Vorrichtung zur modellbasierten Analyse
DE102021133786A1 (de) Konfiguration einer auf einem Computer laufenden SIL-Simulation eines Steuergeräts
DE102019216684B4 (de) Verfahren zur Timinganalyse von Anwendungssoftware für ein eingebettetes System, Vorrichtung zur Datenverarbeitung, Computerprogramm und computerlesbarer Datenträger
EP2634700A1 (de) Verfahren und Entwicklungsumgebung zur Überwachung eines ablaufenden Programms
EP4198722A1 (de) Konfiguration einer auf einem computer laufenden sil-simulation eines steuergeräts
EP3388944A1 (de) Verfahren zur fehlererkennung in einem betriebssystem
EP2386952A1 (de) Verfahren und Entwicklungsumgebung zur Überwachung eines ablaufenden Programms
DE102023202024A1 (de) Verfahren zum Prüfen der Integrität eines Rechenknotens

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20180112

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20180927

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 11/30 20060101AFI20200602BHEP

Ipc: G06F 30/20 20200101ALI20200602BHEP

Ipc: G06F 11/34 20060101ALI20200602BHEP

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20200728

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