EP4666172A1 - Vorrichtung und verfahren für einen fernzugriff auf zumindest eine testumgebung durch wenigstens eine benutzeranwendung - Google Patents

Vorrichtung und verfahren für einen fernzugriff auf zumindest eine testumgebung durch wenigstens eine benutzeranwendung

Info

Publication number
EP4666172A1
EP4666172A1 EP23836346.9A EP23836346A EP4666172A1 EP 4666172 A1 EP4666172 A1 EP 4666172A1 EP 23836346 A EP23836346 A EP 23836346A EP 4666172 A1 EP4666172 A1 EP 4666172A1
Authority
EP
European Patent Office
Prior art keywords
test environment
data
user application
measurement
instance
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.)
Pending
Application number
EP23836346.9A
Other languages
English (en)
French (fr)
Inventor
Hendirk AMSBECK
Thomas KOLLMEIER
Dirk Stichling
Alexander GÖTZ
Franklin Lee HUBBELL
Niklas JUNGE
Thomas TRILLING
Rafael SPYRA
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 Se & Co Kg
Original Assignee
Dspace 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 filed Critical Dspace GmbH
Publication of EP4666172A1 publication Critical patent/EP4666172A1/de
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Prevention of errors by analysis, debugging or testing of software
    • G06F11/3698Environments for analysis, debugging or testing of software
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668Testing of software
    • G06F11/3672Test management
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2294Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing by remote test

Definitions

  • Apparatus and method for remote access to at least one test environment by at least one user application
  • the application relates to a device and a method for remote access to at least one test environment by at least one user application.
  • Test environments are used, for example, in the development of control units, such as those used in the automotive or aviation industries to control technical systems such as engines or brakes.
  • the development of control units has become a highly complex process. New control and regulation functions for control units should be tested as early as possible in the development process in order to check functionality and determine the further direction of development. In the more advanced development process, it is important to test the already well-developed control unit as comprehensively as possible.
  • Test environments can offer the possibility of testing such a system to be tested using an environment model.
  • a system to be tested can have both functions, e.g. software, and devices, e.g. hardware, which can be tested in the test environment.
  • the environment model simulates the respective environment through suitable data exchange for the software or hardware.
  • the test environments can have an interface to a user who can use the test environments to carry out experiments with the system to be tested. Experiments can be used to set parameters for the simulations with the system to be tested and the environment model, and values that occur in the simulation can be displayed and recorded.
  • a device for remote access to at least one test environment by at least one user application is provided as a device via a communication network available computer resource.
  • the computer resource has an experiment manager and at least one measurement instance.
  • the experiment manager provides the at least one user application with a first login interface for logging in via the communication network.
  • the experiment manager provides the at least one test environment with a second login interface for logging in, in particular via the communication network.
  • the second login interface provides for logging in the at least one test environment via a software agent.
  • the at least one measuring instance has a control interface for the at least one user application and a measurement interface for the at least one test environment. It is intended to transmit display data to the at least one user application via the control interface and to receive control data for the test environment from the at least one user application, e.g. for a measurement and/or simulation running in the test environment. It is intended to transmit the control data to the at least one test environment via the measurement interface and to receive measurement data for generating the display data from the at least one test environment, so that remote access to the at least one test environment is possible for the at least one user application.
  • the device enables at least one user at any location to gain remote access to at least one test environment via a communications network and a computer resource available therewith.
  • Several users can also work on the same test environment simultaneously via remote access via the communications network. The device makes this remote access technically reliable and easy to implement.
  • test environment Since the test environment registers itself with the computer resource and in particular with the experiment manager through a software agent, its At least no human intervention is required in the test environment to enable remote access.
  • computer resource for remote access to the test environment or to multiple test environments enables different users to access the same test environment or different test environments simultaneously.
  • Using the computer resource also makes it possible for the respective test environment to be available globally for remote access.
  • remote access means that a user application that is present at a first location can access a test environment that is present at a second location. This makes it possible to overcome large distances, such as several hundred kilometers or several thousand kilometers, between the first and second locations, thus enabling global access distributed across the globe.
  • the at least one test environment provides a technical device, either in terms of software or hardware, that tests a system under test with regard to its functionality and thus carries out measurements.
  • a technical device either in terms of software or hardware
  • HIL hardware-in-the-loop simulators
  • SIL software-in-the-loop simulators
  • a hardware-in-the-loop simulator for example, devices to be tested, such as control units that are used in a vehicle to control a system, for example an engine, can be tested with regard to many possible situations.
  • software-in-the-loop simulator software, e.g. functions that are available as software code, can be tested, e.g. in interaction with a simulated environment.
  • test drives for example.
  • a test environment enables the testing of a large number of situations that may later arise during use. Since companies using such test environments have users in different countries, such remote access is particularly advantageous according to this application in order to be able to access the test environment regardless of the location where the users are located, whereby the test environment can be set up and operated at a different location.
  • the user application is intended to provide the user, who uses the test environment, with access to the test environment.
  • the user application can, for example, have a graphical user interface to enable the user to interact.
  • the user application can, for example, be browser-based software with which measurement data from the test environment can be graphically displayed and further analyzed, and the user application generates control data based on the user's input that influences the simulation and/or measurement in the test environment.
  • browser-based software other implementations of the user application are also possible, e.g. through an app.
  • the communication network can be, for example, the Internet, but also, alternatively or additionally, a company's global communication network.
  • the computer resource can be understood as a so-called cloud solution, which is maintained, for example, by the company itself that uses the test environment and the user application or by a service provider that then offers so-called hosting of the computer resource.
  • the computer resource has an experiment manager, which is designed as a software module, for example, and provides a first login interface for the user application to log in via the communication network.
  • the experiment manager also has a second login interface for the test environment so that the test environment can log in via a software agent as described.
  • Software and communication technologies that are common on the Internet, for example, are used for the login interfaces.
  • a software agent is a computer program that behaves independently and dynamically within a given framework. This means that a certain processing procedure runs depending on various conditions without an additional start signal being given from outside or without external control intervention during the process. In this case, this enables the test environment to log in to the Experiment Manager via the second login interface. If the test environment is therefore put into operation, this test environment can then log in directly to the Experiment Manager via the software agent. it is available for remote access to the user applications. It is possible for different test environments to log in to the Experiment Manager in order to be available for remote access. Accordingly, many users can log in to the Experiment Manager via their user application, but this is initiated by the user himself, while the respective software agent ensures automatic login to the Experiment Manager for the respective test environment.
  • the first login interface is therefore a software module of the Experiment Manager, as is the second login interface.
  • the computer resource also has a measuring instance, which can also be designed as a software module.
  • the measuring instance has a control interface for the at least one user application and a measuring interface for the at least one test environment.
  • the control interface transmits display data to the at least one user application, while the user application transmits control data for the test environment, e.g. for a measurement and/or simulation, to the measuring instance via the control interface.
  • the measuring interface ensures that the control data is transmitted to the at least one test environment and that measurement data for generating the display data is received from the at least one test environment. This enables remote access from the user application to the test environment via the computer resource.
  • the aforementioned data can be transmitted in packet-oriented form, i.e. there does not have to be a complete or continuous communication channel from the user application to the test environment, which facilitates remote access from several user applications to a test environment or to different test environments.
  • test manager When registering the test environment, it is planned to send information about the test environment to the experiment manager as configuration data. This means that the experiment manager knows what can be tested in the test environment and how, and also, for example, what type of simulator the test environment has.
  • the at least one measuring instance is set up to process the measurement data for generating the display data depending on display configuration data.
  • the measurement data for generating the display data are thus processed according to the requirements of the User applications are processed.
  • Access to the measurement instance can be established, for example, via the experiment manager.
  • a measurement instance can be set up to communicate with several user applications and/or several test environments and, in particular, to process their data.
  • the at least one measuring instance is set up to process the control data before transmission to the at least one test environment depending on the configuration data. This allows the control data to be adapted to the configuration of the test environment.
  • the test environment can then use this processed control data immediately during testing and/or in the simulation and/or in the measurement.
  • the measuring instance can communicate with several test environments and process and transmit the control data using the configuration data adapted to the respective test environment.
  • the computer resource has a database that is intended for storing information on the registrations, the control data, the measurement data, the configuration data and/or the display configuration data, with the storage being provided in particular by the experiment manager.
  • This storage then makes it possible to trace the processes through remote access. For example, if a communication error occurs, remote access can be reestablished using this stored data.
  • the experiment manager is particularly suitable for storing this data as an instance that controls the storage.
  • the database can be used to enable data exchange of shared data within the computer resource.
  • the computer resource is intended to have a post-processing service that is set up to record and manage the measurement data and to provide access to the measurement data. This measure also enables access to such measurement data at a later date, particularly in the event of communication errors, but also in order to re-understand things from the past.
  • the database and/or another memory is provided for storing the measurement data.
  • the database and the other memory can also be embodied in a common memory.
  • the at least one measurement instance has a control interface for the at least one user application and a measurement interface for the at least one test environment
  • the at least one measuring instance transmits display data to the at least one user application and receives control data for the test environment, in particular a simulation and/or measurement running thereon, from the at least one user application, wherein the at least one measuring instance transmits the control data to the at least one test environment and receives measurement data for generating the display data from the at least one test environment,
  • the method offers the advantage that at least one user at any location can obtain remote access to at least one test environment via a communications network and a computer resource available therewith. This leads to great flexibility as to where the users or the test environment can be located.
  • the use of the computer resource for remote access to the test environment or to several test environments enables different users can access the same test environment or different test environments at the same time.
  • By using the computer resource it is also possible for the respective test environment to be available globally for remote access.
  • the test environment transmits information about the test environment to the experiment manager as configuration data in connection with the registration. This means that the experiment manager knows what can be tested about the test environment and how.
  • the at least one measurement instance can process the measurement data for generating the display data depending on display configuration data.
  • the measurement data for generating the display data is thus processed according to the requirements of the user applications. This enables adaptation to the display options on the respective user application.
  • the at least one measuring instance can process the control data before transmission to the at least one test environment depending on the configuration data. This enables the control data to be adapted to the conditions in the respective test environment.
  • the experiment manager can store information about the registrations, the control data, the measurement data, the configuration data and/or the display configuration data in a database.
  • a post-processing service can be provided which records, manages and/or grants access to the measurement data in a process step.
  • the user application has a user interface for displaying the display data and for entering the control data.
  • the display data is designed in such a way that it is suitable for graphical representation in the user application and also for further analysis by the user. For example, the user can further process the display data using mathematical methods in order to gain further insights.
  • the control data instructs the test environment, for example, to test the device to be tested in certain parameter ranges. device. Therefore, the test environment is set up to communicate with the device, to test the system to be tested, e.g. hardware and/or software, and to generate the measurement data, wherein the measurement data depends on the system to be tested, e.g. the hardware and/or the software.
  • a system which comprises a previously described device, a previously described user application and a previously described test environment.
  • test environment has the software agent, whereby the software agent is intended for logging on to the experiment manager.
  • the test environment can, for example, be located at a location remote from the computer resource.
  • the test environment can also be located on the computer resource and run there, for example, as software.
  • test environment is designed to communicate with the device via the communication network. This is particularly advantageous for embodiments in which the test environment is located at a location remote from the computer resource. This can be particularly advantageous for test environments with a hardware-in-the-loop simulator.
  • Figure 1 is a schematic representation of the system
  • FIG. 2 shows another schematic representation of the system
  • Figure 3 shows a flow chart of the process.
  • Figure 1 shows a schematic example of a system with two user applications BA, two users AW, a computer resource CR and four test environments TU.
  • the computer resource has an experiment manager EM and at least one measurement instance MI. Remote access by a respective user application BA to the respective test environments TU is enabled via the experiment manager EM and the at least one measurement instance MI.
  • Figure 1 shows two users AW with their respective user applications BA as an example. Embodiments with more or fewer users AW are also conceivable.
  • Two of the test environments TU each have a hardware-in-the-loop simulator HIL and are located outside the computer resource CR.
  • Two other test environments TU each have a software-in-the-loop simulator SIL.
  • One of the test environments TU with software-in-the-loop simulator SIL is located outside the computer resource CR.
  • the second of the test environments TU with software-in-the-loop simulator SIL is located inside the computer resource CR.
  • Test environments TU are also conceivable that have several hardware-in-the-loop simulators HIL or several software-in-the-loop simulators SIL.
  • Test environments TU are also conceivable that have at least one hardware-in-the-loop simulator HIL and at least one software-in-the-loop simulator SIL.
  • a system to be tested also called a system under test, is connected to the SIL or HIL simulator.
  • the system to be tested can be implemented as software in a software-in-the-loop simulator (SIL).
  • the system to be tested can be implemented as hardware, e.g. a device or control unit, in a hardware-in-the-loop simulator (HIL).
  • the system to be tested can be accessed separately from the SIL or HIL simulator via the respective software agent (SWA).
  • SWA software agent
  • measurement data can be recorded and other data, such as configuration data, can be read out. Remote access to the system to be tested can therefore also be enabled via the computer resource CR described.
  • the BA user applications show an example of a parameter range from 60.8 to 120.5 and a graphically displayed curve, which, for example, because it comes from one of the test environments TU, ie measurement data from the test environment TU can be displayed in the user applications BA.
  • the values 60.8 and 120.5 shown as examples can also be measurement values at a specific point in time.
  • the curve can also be the temporal progression of a measurement value, for example.
  • the user applications BA communicate via a communication network, such as the Internet, with the computer resource CR, which can be a cloud application, for example.
  • the user applications BA log on to the Experiment Manager EM in the computer resource CR and exchange data with the Experiment Manager EM.
  • This data includes, for example, configuration and display configuration data.
  • the Experiment Manager EM can store such data in a database DB.
  • the experiment manager EM can be connected to a test environment TU or several test environments TU within the computer resource CR and/or to a test environment or several test environments TU outside the computer resource CR. At the same time, it is possible for the experiment manager to be connected to several test environments TU simultaneously, either within the computer resource CR or outside the computer resource CR.
  • test environment TU is within the computer resource CR, it can in particular be a test environment that is designed to test software that therefore has a software-in-the-loop simulator SIL.
  • the test environments TU outside the computer resource CR can in particular be test environments TU that have at least one software-in-the-loop simulator SIL and/or one hardware-in-the-loop simulator HIL.
  • the test environments TU log in to the experiment manager EM and transmit login data that relates to the identity of the test environment and configuration data that relates to the conditions of the test environment TU.
  • the login data allows the experiment manager to determine the login authorization of the respective test environment. If this login authorization is not present, registration is rejected.
  • the Experiment Manager EM transmits the configuration data and/or the login data to a database DB for storage.
  • the TU test environments are registered using a respective SWA software agent.
  • the SWA software agent enables the TU test environment to register itself with the EM experiment manager. It is also possible to log off using the SWA software agent, for example if the TU test environment analyzes that it is no longer functioning properly.
  • the SWA software agent not only registers with the EM experiment manager for the respective test environment, but also transfers the registration data and configuration data for the EM experiment manager for the respective TU test environment.
  • the user application BA can connect to the measuring instance MI in order to exchange display and control data with the test environment TU.
  • the measuring instance MI can be set up in such a way that several user applications BA can exchange data with one or more test environments TU at the same time.
  • a respective measuring instance MI can also exchange control data and display data with a respective user arrangement BA.
  • a respective measuring instance MI can also exchange measurement data and control data with a respective test environment TU.
  • Figure 2 shows a schematic example of another embodiment of the system with a user application BA, a user AW, the computer resource CR and two test environments TU.
  • the system is shown in Fig. 2 with a greater level of detail than Fig. 1.
  • test environments TU has a hardware-in-the-loop simulator HIL and is located outside the computer resource CR.
  • This test environment TU has, in addition to the hardware-in-the-loop simulator HIL, the system to be tested (not shown), which is in the present case designed as hardware. The system to be tested is connected to the hardware-in-the-loop simulator HIL for the test purposes mentioned.
  • Another test environment TU has a software-in-the-loop simulator SIL and is located inside the computer resource CR.
  • This test environment TU has, in addition to the software-in-the-loop simulator SIL, a system to be tested (not shown), which is in the present case designed as software. The system to be tested is connected to the connected to the software-in-the-loop simulator SIL for the test purposes mentioned.
  • the user AW uses his user application BA via a browser BRW.
  • the browser BRW can, for example, be a so-called web browser, which is an application for displaying Internet pages.
  • the user application BA logs on to the experiment manager EM via connection 100 with display configuration data via a first login interface AS-1.
  • the display configuration data state what the user AW wants to see displayed, for example value ranges and other parameters.
  • the experiment manager EM stores this data and other data in the database DB via connection 102.
  • the user application BA then connects to the measuring instance MI via the control interface KS in order to exchange display and control data with the measuring instance MI. This is done via connection 101.
  • the experiment manager EM with its login interfaces AS-1 and AS-2 as well as the measuring instance MI with the control interface KS, but also the further measuring interface MS are all located in the computer resource CR, as is the database DB.
  • the SIL test environment TU logs on to the experiment manager EM via its software agent SWA via connection 103 via the second login interface AS-2.
  • the HIL test environment TU logs on to the experiment manager EM via its software agent SWA via connection 107 via the second login interface AS-2.
  • test environment TU When the test environment TU is registered, configuration data about the test environment TU is also stored with the experiment manager EM, which then stores it in the database DB via connection 102.
  • the test environments TU also connect to the measurement instance MI via connections 104 and 106 via the measurement interface MS.
  • the respective software agent SWA is also used for this.
  • the computer resource CR can be designed in particular so that the experiment manager EM, the measurement instance MI and/or the post-processing service PPS can store data in the database DB and can also read them out again.
  • configuration data can be stored in the database DB and read out again.
  • the database DB can thus also be the storage location for - especially within the computer resource - common used data. This means that data exchange of shared data can be realized via the database DB.
  • the test environment TU logs on to the experiment manager EM via the respective software agent SWA, as described above. This can be reached, for example, via a fixed address known to the test environment TU.
  • the software agent SWA of the test environment TU receives the address of the measurement instance MI from the experiment manager EM, via which it carries out further communication.
  • the user application BA accesses the measurement instance MI in a similar way.
  • the user application BA receives the address of the measurement instance MI from the experiment manager EM. Communication, in particular the exchange of measurement data, between the user application BA and the test environment TU can then take place via the measurement instance MI.
  • a measurement instance MI can communicate with several test environments TU.
  • additional measurement instances MI can be started. This start in the event of high utilization can, for example, be carried out by a higher-level control instance of the computer resource CR. Newly logging in user applications BA and test environments TU can then be assigned the additional, newly started, measurement instances MI.
  • connection 106 between the HIL test environment TU and the measuring instance MI is used to exchange control data and measurement data, whereby the control data is supplied by the measuring instance MI and the measurement data by the test environment TU.
  • Control data is originally supplied by the user application BA to the measuring instance MI via the connection 101, processed by the latter if necessary and transmitted to the HIL test environment TU via the connection 106.
  • the HIL test environment TU outside the computer resource CR. also has an optional memory R2 in which the software agent SWA of the test environment TU can save measurement data.
  • measurement data can be saved locally, which can be particularly advantageous if they occur with a very high data throughput.
  • the connection 106 which can be global via a communication network, cannot record the measurement data arising in the test environment TU sufficiently quickly in terms of latency (delay) and data throughput (amount of data per time).
  • the data stored in the optional The data stored in memory R2 are transmitted to the measuring instance MI via the data connection 106.
  • Measurement data from the measuring instance MI can be fed to a post-processing service PPS for further processing via the connection 105.
  • the post-processing service PPS stores these measurement data in the memory RI via the connection 108.
  • the PPS post-processing service also offers the option of replaying and/or specifically retrieving the recorded data for analysis.
  • the replayed and/or specifically retrieved measurement data is then displayed in the BA user application.
  • the measurement data can be retrieved and displayed either at a specific point in time and/or at a specific time period and/or the data can be played back like in a film. This enables the BA user application to remotely access the measurement data stored in the RI memory via the PPS post-processing service and the MI measurement instance.
  • Figure 3 shows the process in a flow chart.
  • test environments TU log on to the experiment manager EM via their respective software agent SWA.
  • user applications BA log on to the experiment manager EM.
  • the test environments TU and user applications BA can also log on to the experiment manager in the reverse order.
  • control data is then transmitted via the connection 101 from the user application BA to the measuring instance MI and via at least one of the connections 106, 104 to at least one of the test environments TU.
  • the test environment TU carries out appropriate tests/simulations/measurements on the system to be tested using the control data and transmits the measurement data thus determined to the measuring entity MI via the connection 106, 104.
  • the measurement data relate to the measurement carried out and/or the simulation carried out and/or the test carried out.
  • the measurement data can include measured values recorded on the system to be tested.
  • the measurement instance MI processes the measurement data, adapts it to the user application BA and transmits the appropriately prepared measurement data as display data to the user application BA via connection 101.
  • Control data configuration data, display configuration data

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Debugging And Monitoring (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

Die Anmeldung betrifft eine Vorrichtung und ein Verfahren für einen Fernzugriff auf zumindest eine Testumgebung (TU) durch zumindest eine Benutzeranwendung (BA), wobei die Vorrichtung als eine über ein Kommunikationsnetz verfügbare Computerressource (CR) ausgebildet ist. Die Computerressource (CR) weist einen Experimentmanager (EM) und wenigstens eine Messinstanz (MI) auf, wobei der Experimentmanager (EM) der wenigstens einen Benutzeranwendung (BA) eine erste Anmelde-Schnittstelle (AS-1) zur Anmeldung über das Kommunikationsnetz zur Verfügung stellt und der wenigstens einen Testumgebung (TU) eine zweite Anmelde-Schnittstelle (AS-2) zur Anmeldung, insbesondere über das Kommunikationsnetz, zur Verfügung stellt, wobei die zweite Anmelde-Schnittstelle (AS-2) für die Anmeldung der zumindest einen Testumgebung (TU) die Anmeldung über einen Softwareagenten (SWA) vorsieht, wobei die wenigstens eine Messinstanz (MI) eine Kontroll-Schnittstelle (KS) für die wenigstens eine Benutzeranwendung (BA) und eine Mess-Schnittstelle (MS) für die wenigstens eine Testumgebung (TU) aufweist, wobei vorgesehen ist, über die Kontroll-Schnittstelle (KS) Anzeigedaten an die wenigstens eine Benutzeranwendung (BA) zu übermitteln und von der wenigstens einen Benutzeranwendung (BA) Steuerdaten für Testumgebung zu empfangen, wobei vorgesehen ist, über die Mess-Schnittstelle (MS) die Steuerdaten an die wenigstens eine Testumgebung (TU) zu übermitteln und Messdaten für die Erzeugung der Anzeigedaten von der wenigstens einen Testumgebung (TU) zu empfangen, so dass für die wenigstens eine Benutzeranwendung (BA) ein Fernzugriff auf die wenigstens eine Testumgebung (TU) ermöglicht ist.

Description

Vorrichtung und Verfahren für einen Fernzugriff auf zumindest eine Testumgebung durch wenigstens eine Benutzeranwendung
Technisches Gebiet
Die Anmeldung betrifft eine Vorrichtung und ein Verfahren für einen Fernzugriff auf zumindest eine Testumgebung durch wenigstens eine Benutzeranwendung.
Hintergrund
Testumgebungen kommen zum Beispiel bei der Entwicklung von Steuergeräten, wie sie z.B. in der Automobilindustrie oder in der Luftfahrtindustrie zur Steuerung von technischen Systemen, wie z.B. Motoren oder Bremsen, verwendet werden, zum Einsatz. Die Entwicklung von Steuergeräten ist zu einem hochkomplexen Prozess geworden. So sollen neue Steuer- und Regelfunktionen für Steuergeräte so früh wie möglich im Entwicklungsprozess getestet werden, um die Funktionalität zu überprüfen und die weitere Entwicklungsrichtung vorzugeben. Im weiter fortgeschrittenen Entwicklungsprozess ist es wichtig, das schon weit entwickelte Steuergerät möglichst umfassend zu testen.
Testumgebungen können die Möglichkeit bieten, ein solches zu testende System mittels eines Umgebungsmodells zu testen. Ein zu testendes System kann sowohl Funktionen, z.B. Software, als auch Geräte, z.B. Hardware, aufweisen, welche in der Testumgebung getestet werden können. Das Umgebungsmodell simuliert dabei durch geeigneten Datenaustausch für die Software bzw. die Hardware die jeweilige Umgebung. Die Testumgebungen können eine Schnittstelle zu einem Benutzer aufweisen, der mittels der Testumgebungen Experimente mit dem zu testenden System durchführen kann. Über Experimente können Parameter für die Simulationen mit dem zu testenden System und dem Umgebungsmodell gesetzt werden und es können in der Simulation auftretende Werte angezeigt und aufgezeichnet werden.
Übersicht
Eine Vorrichtung für einen Fernzugriff auf zumindest eine Testumgebung durch zumindest eine Benutzeranwendung ist als eine über ein Kommunikationsnetz verfügbare Computerressource ausgebildet. Die Computerressource weist einen Experimentmanager und wenigstens eine Messinstanz auf.
Der Experimentmanager stellt der wenigstens einen Benutzeranwendung eine erste Anmelde-Schnittstelle zur Anmeldung über das Kommunikationsnetz zur Verfügung. Der Experimentmanager stellt der wenigstens einen Testumgebung eine zweite Anmelde-Schnittstelle zur Anmeldung, insbesondere über das Kommunikationsnetz, zur Verfügung. Die zweite Anmelde-Schnittstelle sieht für die Anmeldung der zumindest einen Testumgebung die Anmeldung über einen Softwareagenten vor.
Die wenigstens eine Messinstanz weist eine Kontroll-Schnittstelle für die wenigstens eine Benutzeranwendung und eine Mess-Schnittstelle für die wenigstens eine Testumgebung auf. Es ist vorgesehen, über die Kontroll-Schnittstelle Anzeigedaten an die wenigstens eine Benutzeranwendung zu übermitteln und von der wenigstens einen Benutzeranwendung Steuerdaten für die Testumgebung, z.B. für eine in der Testumgebung ablaufende Messung und/oder Simulation, zu empfangen. Es ist vorgesehen, über die Mess-Schnittstelle die Steuerdaten an die wenigstens eine Testumgebung zu übermitteln und Messdaten für die Erzeugung der Anzeigedaten von der wenigstens einen Testumgebung zu empfangen, so dass für die wenigstens eine Benutzeranwendung ein Fernzugriff auf die wenigstens eine Testumgebung ermöglicht ist.
Die Vorrichtung ermöglicht, dass mittels der Vorrichtung wenigstens ein Benutzer an einem jeweiligen beliebigen Ort über ein Kommunikationsnetz und über eine damit verfügbare Computerressource einen Fernzugriff auf zumindest eine Testumgebung erhält. Dies führt zu einer größeren Flexibilität, wo sich die Benutzer bzw. die Testumgebung befinden können. Beispielsweise ist es möglich, auf eine Testumgebung rund um die Uhr von Benutzern, die sich in unterschiedlichen Zeitzonen befinden, zuzugreifen. Dies führt zu einer effizienteren Nutzung einer solchen Testumgebung und spart damit Kosten und Zeit. Über das Kommunikationsnetz können gleichzeitig auch mehrere Benutzer über den Fernzugriff an der gleichen Testumgebung arbeiten. Durch die Vorrichtung ist dieser Fernzugriff technisch zuverlässig und einfach zu implementieren.
Da sich die Testumgebung durch einen Softwareagenten bei der Computerressource und dabei insbesondere bei dem Experimentmanager anmeldet, ist sei- tens der Testumgebung kein menschliches Handeln notwendig, um den Fernzugriff zu ermöglichen. Die Verwendung der Computerressource für den Fernzugriff auf die Testumgebung oder auf mehrere Testumgebungen ermöglicht, dass verschiedene Benutzer gleichzeitig auf dieselbe Testumgebung oder auf verschiedene Testumgebungen zugreifen können. Durch die Verwendung der Computerressource ist es weiterhin möglich, dass die jeweilige Testumgebung global für einen Fernzugriff zur Verfügung steht.
Unter einem Fernzugriff wird gemäß der Anmeldung verstanden, dass eine Benutzeranwendung, die an einem ersten Ort vorhanden ist, auf eine Testumgebung, die an einem zweiten Ort vorhanden ist, zugreifen kann. Damit können insbesondere große Entfernungen, wie mehrere 100 km oder mehrere 1000 km, zwischen dem ersten und zweiten Ort überwunden werden und so z.B. auch ein globaler, über den Globus verteilter Zugriff ermöglicht werden.
Die zumindest eine Testumgebung liefert entweder softwaretechnisch oder hardwaremäßig eine technische Einrichtung, die ein zu testendes System (engl. System under Test) hinsichtlich seiner Funktionalität prüft und damit Messungen durchführt. Dafür können beispielsweise sogenannte Hardware-in-the-Loop- Simulatoren (HIL) oder Software-in-the-Loop-Simulatoren (SIL) verwendet werden. Mit einem Hardware-in-the-Loop-Simulator können beispielsweise zu testende Geräte, wie z.B. Steuergeräte, die in einem Fahrzeug zur Steuerung eines Systems, beispielsweise eines Motors, verwendet werden, hinsichtlich vieler möglicher Situationen durchgeprüft werden. Mit einem Software-in-the-Loop-Si- mulator kann Software, z.B. Funktionen, die als Softwarecode vorliegen, z.B. im Zusammenspiel mit einer simulierten Umgebung durchgeprüft werden. Dies spart im Falle des Fahrzeugs beispielsweise Testfahrten. Insbesondere beim Einsatz von Elektronik und Software ermöglicht solch eine Testumgebung die Prüfung von einer Vielzahl von Situationen, die im Einsatz dann später vorkommen können. Da Unternehmen, die solche Testumgebungen verwenden, Benutzer in verschiedenen Ländern haben, ist ein solcher Fernzugriff gemäß dieser Anmeldung von besonderem Vorteil, um unabhängig von dem Ort, an dem sich die Benutzer befinden, auf die Testumgebung zugreifen zu können, wobei die Testumgebung an einem anderen Ort aufgebaut sein kann und betrieben werden kann.
Die Benutzeranwendung ist vorgesehen, dem Benutzer, welcher als Anwender die Testumgebung nutzt, einen Zugriff auf die Testumgebung zu ermöglichen. Die Benutzeranwendung kann dabei z.B. eine graphische Benutzeroberfläche aufweisen, um dem Benutzer die Interaktion zu ermöglichen. Bei der Benutzeranwendung kann es sich beispielsweise um eine browserbasierte Software handeln, mit der Messdaten von der Testumgebung grafisch angezeigt und weiter analysiert werden können, und wobei die Benutzeranwendung gemäß den Eingaben des Benutzers Steuerdaten erzeugt, die die Simulation und/oder Messung auf der Testumgebung beeinflussen. Anstatt einer browserbasierten Software sind auch andere Implementierungen der Benutzeranwendung möglich, bspw. durch eine App.
Bei dem Kommunikationsnetz kann es sich beispielsweise um das Internet handeln, aber auch z.B. alternativ oder zusätzlich um ein globales Kommunikationsnetz eines Unternehmens.
Unter der Computerressource kann vorliegend eine sogenannte Cloud-Lösung verstanden werden, die beispielsweise von dem Unternehmen selbst, das die Testumgebung und die Benutzeranwendung verwendet, unterhalten wird oder aber auch von einem Dienstleister, der dann ein sogenanntes Hosting der Computerressource anbietet.
Die Computerressource weist einen Experimentmanager auf, der beispielsweise als Softwaremodul ausgebildet ist und eine erste Anmeldeschnittstelle für die Benutzeranwendung zur Anmeldung über das Kommunikationsnetz zu Verfügung stellt. Der Experimentmanager weist weiterhin eine zweite Anmeldeschnittstelle für die Testumgebung auf, damit sich die Testumgebung wie beschrieben über einen Softwareagenten anmelden kann. Für die Anmeldeschnittstellen werden Software- und Kommunikationstechnologien, die bspw. beim Internet üblich sind, verwendet.
Unter einem Softwareagenten wird ein Computerprogramm verstanden, dass in einem vorgegebenen Rahmen sich eigenständig und eigendynamisch verhält. Was bedeutet, dass abhängig von verschiedenen Zuständen ein bestimmter Verarbeitungsvorgang abläuft, ohne dass von außen ein weiteres Startsignal gegeben wird, oder während des Vorgangs ein äußerer Steuerungseingriff erfolgt. Vorliegend ermöglicht dies der Testumgebung sich beim Experiment Manager über die zweite Anmeldeschnittstelle anzumelden. Wird die Testumgebung demnach in Betrieb genommen, kann sich dann diese Testumgebung über den Softwareagenten danach unmittelbar bei dem Experiment Manager anmelden. Damit steht sie für die Benutzeranwendungen für den Fernzugriff zur Verfügung. Es ist möglich, dass sich verschiedene Testumgebungen bei dem Experiment Manager anmelden, um für den Fernzugriff zur Verfügung zu stehen. Entsprechend können sich viele Benutzer über ihre Benutzeranwendung bei dem Experiment Manager anmelden, wobei dies jedoch durch den Benutzer selbst ausgelöst wird, während der jeweilige Softwareagent für eine automatische Anmeldung beim Experimentmanager für die jeweilige Testumgebung sorgt. Die erste Anmeldeschnittstelle ist demnach ein Softwaremodul des Experimentmanagers ebenso wie die zweite Anmeldeschnittstelle.
Weiterhin weist die Computerressource eine Messinstanz auf, die ebenso als ein Softwaremodul ausgebildet sein kann. Die Messinstanz weist eine Kontrollschnittstelle für die wenigstens eine Benutzeranwendung und eine Messschnittstelle für die wenigstens eine Testumgebung auf. Die Kontrollschnittstelle vermittelt Anzeigedaten an die wenigstens eine Benutzeranwendung, während die Benutzeranwendung Steuerdaten für die Testumgebung, z.B. für eine Messung und/oder Simulation, über die Kontrollschnittstelle an die Messinstanz übermittelt. Die Messschnittstelle sorgt dafür, dass die Steuerdaten an die wenigstens eine Testumgebung übermittelt werden und Messdaten für die Erzeugung der Anzeigedaten von der wenigstens einen Testumgebung empfangen werden. Damit ist über die Computerressource ein Fernzugriff von der Benutzeranwendung auf die Testumgebung ermöglicht. Insbesondere können vorliegend die vorgenannten Daten paketorientiert jeweils übertragen werden, d. h. es muss nicht ein vollständiger bzw. durchgehender Kommunikationskanal von der Benutzeranwendung bis zur Testumgebung vorhanden sein, was den Fernzugriff von mehreren Benutzeranwendungen auf eine Testumgebung oder auch auf verschiedene Testumgebungen erleichtert.
Es ist vorgesehen, im Zusammenhang mit der Anmeldung der Testumgebung Informationen über die Testumgebung als Konfigurationsdaten an den Experimentmanager zu übermitteln. Damit ist dem Experimentmanager bekannt, was über die Testumgebung und wie geprüft werden kann und z.B. auch welche Art von Simulator die Testumgebung aufweist.
Darüber hinaus ist es vorgesehen, dass die wenigstens eine Messinstanz dazu eingerichtet ist, die Messdaten für die Erzeugung der Anzeigedaten in Abhängigkeit von Anzeigekonfigurationsdaten zu bearbeiten. Damit werden die Messdaten für die Erzeugung der Anzeigedaten entsprechend den Anforderungen durch die Benutzeranwendungen bearbeitet. Der Zugriff auf die Messinstanz kann dabei z.B. über den Experimentmanager hergestellt werden. Eine Messinstanz kann eingerichtet sein, mit mehreren Benutzeranwendungen und/oder mehreren Testumgebungen zu kommunizieren und insbesondere deren Daten zu bearbeiten.
Des Weiteren ist es vorgesehen, dass die wenigstens eine Messinstanz dazu eingerichtet ist, die Steuerdaten vor der Übermittlung an die wenigstens eine Testumgebung in Abhängigkeit von den Konfigurationsdaten zu bearbeiten. Damit kann eine Anpassung der Steuerdaten an die Konfiguration der Testumgebung stattfinden. Damit kann dann die Testumgebung diese bearbeiteten Steuerdaten sofort beim Testen und/oder in der Simulation und/oder in der Messung verwenden. Insbesondere kann die Messinstanz mit mehreren Testumgebungen kommunizieren und die Steuerdaten unter Verwendung der Konfigurationsdaten angepasst auf die jeweilige Testumgebung bearbeiten und übermitteln.
Weiterhin ist es vorgesehen, dass die Computerressource eine Datenbank aufweist, die für die Speicherung von Informationen zu den Anmeldungen, den Steuerdaten, den Messdaten, den Konfigurationsdaten und oder den Anzeigekonfigurationsdaten vorgesehen ist, wobei die Speicherung insbesondere durch den Experimentmanager vorgesehen ist. Durch diese Speicherung ist es dann möglich, die Vorgänge durch den Fernzugriff nachzuvollziehen. Beispielsweise wenn ein Kommunikationsfehler stattfindet, kann dadurch wieder der Fernzugriff neu aufgesetzt werden, unter Mithilfe dieser abgespeicherten Daten. Um diese Daten abzuspeichern, eignet sich insbesondere der Experimentmanager als Instanz, der das Abspeichern steuert. Alternativ oder zusätzlich kann über die Datenbank ein Datenaustausch von gemeinsam genutzten Daten innerhalb der Computerressource ermöglicht werden.
Darüber hinaus ist es vorgesehen, dass die Computerressource eine Nachbearbeitungsdienst aufweist, der dazu eingerichtet ist, die Messdaten aufzuzeichnen, zu verwalten und einen Zugriff auf die Messdaten zu gewähren. Auch diese Maßnahme ermöglicht im Nachhinein wieder insbesondere bei Kommunikationsfehlern, aber auch um Dinge aus der Vergangenheit noch mal nachzuvollziehen, einen Zugriff auf solche Messdaten. Darüber hinaus ist es vorgesehen, dass für die Speicherung der Messdaten die Datenbank und/oder ein weiterer Speicher vorgesehen ist. Dabei kann die Datenbank und der weitere Speicher auch in einem gemeinsamen Speicher verkörpert sein.
Für einen Fernzugriff auf zumindest eine Testumgebung durch wenigstens eine Benutzeranwendung, wobei eine über ein Kommunikationsnetz verfügbare Computerressource verwendet wird, welche einen Experimentmanager und wenigstens eine Messinstanz aufweist, wird ein Verfahren mit folgenden Verfahrensschritten vorgeschlagen:
• Anmelden der zumindest einen Benutzeranwendung an dem Experiment Manager,
• Anmelden der zumindest einen Testumgebung an dem Experiment Manager, wobei die wenigstens eine Testumgebung für ihre Anmeldung einen Softwareagenten verwendet,
• wobei die wenigstens eine Messinstanz eine Kontrollschnittstelle für die wenigstens eine Benutzeranwendung und eine Messschnittstelle für die wenigstens eine Testumgebung aufweist,
• wobei die wenigstens eine Messinstanz Anzeigedaten an die zumindest eine Benutzeranwendung übermittelt und von der zumindest einen Benutzeranwendung Steuerdaten für die Testumgebung, insbesondere eine darauf ablaufende Simulation und/oder Messung, empfängt, wobei die wenigstens eine Messinstanz die Steuerdaten an die wenigstens eine Testumgebung übermittelt und Messdaten für die Erzeugung der Anzeigedaten von der wenigstens einen Testumgebung empfängt,
• sodass für die wenigstens eine Benutzeranwendung ein Fernzugriff auf die wenigstens eine Testumgebung ermöglicht wird.
Das Verfahren bietet den Vorteil, dass wenigstens ein Benutzer an einem jeweiligen beliebigen Ort über ein Kommunikationsnetz und über eine damit verfügbare Computerressource einen Fernzugriff auf zumindest eine Testumgebung erhält. Dies führt zu einer großen Flexibilität, wo sich die Benutzer bzw. die Testumgebung befinden können. Die Verwendung der Computerressource für den Fernzugriff auf die Testumgebung oder auf mehrere Testumgebungen ermöglicht, dass verschiedene Benutzer gleichzeitig auf dieselbe Testumgebung oder auf verschiedene Testumgebungen zugreifen können. Durch die Verwendung der Computerressource ist es weiterhin möglich, dass die jeweilige Testumgebung global für einen Fernzugriff zur Verfügung steht.
In einer Ausführungsform des Verfahrens übermittelt die Testumgebung im Zusammenhang mit der Anmeldung Informationen über die Testumgebung als Konfigurationsdaten an den Experimentmanager. Damit ist dem Experimentmanager bekannt, was über die Testumgebung und wie geprüft werden kann.
Die wenigstens eine Messinstanz kann die Messdaten für die Erzeugung der Anzeigedaten in Abhängigkeit von Anzeigekonfigurationsdaten bearbeiten. Damit werden die Messdaten für die Erzeugung der Anzeigedaten entsprechend der Anforderungen durch die Benutzeranwendungen bearbeitet. Dies ermöglicht eine Anpassung auf die Darstellungsmöglichkeiten auf der jeweiligen Benutzeranwendung.
In Ausführungsformen des Verfahrens kann die wenigstens eine Messinstanz die Steuerdaten vor der Übermittlung an die zumindest eine Testumgebung in Abhängigkeit von den Konfigurationsdaten bearbeitet. Dies ermöglicht eine Anpassung der Steuerdaten auf die Gegebenheiten in der jeweiligen Testumgebung.
Damit kann dann die Testumgebung diese bearbeiteten Steuerdaten sofort in der Prüfung verwenden.
In Ausführungsformen des Verfahrens kann der Experimentmanager Informationen zu den Anmeldungen, den Steuerdaten, den Messdaten, den Konfigurationsdaten und/oder den Anzeigekonfigurationsdaten in einer Datenbank abspeichern.
Es kann weiter ein Nachbearbeitungsdienst vorgesehen sein, der in einem Verfahrensschritt die Messdaten aufzeichnet, verwaltet und/oder Zugriff auf diese Messdaten gewährt.
Die Benutzeranwendung weist eine Benutzerschnittstelle zur Anzeige der Anzeigedaten und zur Eingabe der Steuerdaten auf. Die Anzeigedaten sind derart gestaltet, dass sie für eine grafische Darstellung die Benutzeranwendung und auch zur weiteren Analyse durch den Benutzer geeignet sind. Beispielsweise kann mit mathematischen Verfahren der Benutzer die Anzeigedaten weiter aufbereiten, um weitere Erkenntnisse zu gewinnen. Die Steuerdaten weisen die Testumgebung an, beispielsweise in bestimmten Parameterbereichen das zu prüfende Ge- rät zu vermessen. Daher ist die Testumgebung dazu eingerichtet, mit der Vorrichtung zu kommunizieren, das zu prüfende System, z. B. eine Hardware und/oder eine Software, zu testen und die Messdaten zu erzeugen, wobei die Messdaten von dem zu testenden System, z. B. der Hardware und/oder der Software, abhängen.
Weiterhin ist ein System vorgesehen, das eine zuvor beschriebene Vorrichtung, eine zuvor beschriebene Benutzeranwendung und eine zuvor beschriebene Testumgebung aufweist.
Darüber hinaus ist es vorgesehen, dass die Testumgebung den Softwareagenten aufweist, wobei der Softwareagent für die Anmeldung an dem Experimentmanager vorgesehen ist. Die Testumgebung kann sich z.B. an einem von der Computerressource entfernten Ort befinden. Die Testumgebung kann sich auch auf der Computerressource befinden und dort z.B. als Software ablaufen.
Des Weiteren ist es vorgesehen, dass die Testumgebung zur Kommunikation mit der Vorrichtung über das Kommunikationsnetzwerk vorgesehen ist. Dies ist insbesondere für Ausführungsformen vorteilhaft, bei denen die Testumgebung sich an einem von der Computerressource entfernten Ort befindet. Dies kann insbesondere für Testumgebungen mit Hardware-in-the-Loop-Simulator von Vorteil sein.
Figurenliste
Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden in der nachfolgenden Beschreibung näher erläutert.
Es zeigen
Figur 1 eine schematische Darstellung des Systems,
Figur 2 eine weitere schematische Darstellung des Systems und
Figur 3 ein Flussdiagramm des Verfahrens.
Es werden in den Figuren die gleichen Bezugszeichen für gleiche oder ähnliche Elemente verwendet. Die Darstellungen in den Figuren können nicht maßstäblich sein. Figurenbeschreibung
Figur 1 zeigt beispielhaft schematisch ein System mit zwei Benutzeranwendun- gen BA, zwei Benutzern AW, einer Computerressource CR und vier Testumgebungen TU. Die Computerressource weist einen Experimentmanager EM und zumindest eine Messinstanz MI auf. Über den Experimentmanager EM und die zumindest eine Messinstanz MI wird ein Fernzugriff durch eine jeweilige Benutzeranwendung BA auf die jeweiligen Testumgebungen TU ermöglicht.
In Figur 1 sind beispielhaft zwei Benutzer AW mit ihren jeweiligen Benutzeranwendungen BA dargestellt. Es sind auch Ausführungsformen mit mehr oder weniger Benutzern AW denkbar. Zwei der Testumgebungen TU weisen jeweils einen Hardware-in-the-Loop-Simulator HIL auf und befinden sich außerhalb der Computerressource CR. Zwei andere Testumgebungen TU weisen jeweils einen Soft- ware-in-the-Loop-Simulator SIL auf. Eine der Testumgebungen TU mit Software- in-the-Loop-Simulator SIL befindet sich außerhalb der Computerressource CR. Die zweite der Testumgebungen TU mit Software-in-the-Loop-Simulator SIL befindet sich innerhalb der Computerressource CR.
Es sind auch Testumgebungen TU denkbar, die mehrere Hardware-in-the-Loop- Simulatoren HIL oder mehrere Software-in-the-Loop-Simulatoren SIL aufweisen. Ebenso sind auch Testumgebungen TU denkbar, die sowohl zumindest einen Hardware-in-the-Loop-Simulator HIL und zumindest einen Software-in-the-Loop- Simulator SIL aufweisen.
Ein zu prüfendes System, auch zu testendes System oder engl. System under Test genannt, ist dabei jeweils an den Simulator SIL, HIL angeschlossen. Das zu testende System kann dabei bei einem Software-in-the-Loop-Simulator SIL als Software ausgebildet sein. Das zu testende System kann dabei bei einem Hard- ware-in-the-Loop-Simulator HIL als Hardware, z.B. Gerät oder Steuergerät, ausgebildet sein. Über den jeweiligen Softwareagenten SWA kann auf das zu testende System getrennt vom Simulator SIL, HIL zugegriffen werden. Insbesondere können Messdaten erfasst und weitere Daten, wie z.B. Konfigurationsdaten ausgelesen werden. Über die beschriebene Computerressource CR kann somit auch ein Fernzugriff auf das zu testende System ermöglicht werden.
Dargestellt sind in den Benutzeranwendungen BA beispielhaft ein Parameterbereich von 60,8 bis 120,5 sowie eine grafisch dargestellte Kurve, die z.B. von je- weils einer der Testumgebungen TU stammt, d.h. es können in den Benutzeranwendungen BA Messdaten von der Testumgebung TU dargestellt werden. Bei den beispielhaft dargestellten Werten 60,8 und 120,5 kann es sich auch um Messwerte zu einem bestimmten Zeitpunkt handeln. Bei der Kurve kann es sich auch z.B. um den zeitlichen Verlauf eines Messwertes handeln.
Die Benutzeranwendungen BA kommunizieren über ein Kommunikationsnetzwerk, wie beispielsweise dem Internet, mit der Computerressource CR, die beispielsweise eine Cloud-Anwendung sein kann. Dabei melden sich die Benutzeranwendungen BA bei dem Experiment Manager EM in der Computerressource CR an und tauschen mit dem Experimentmanager EM Daten aus. Bei diesen Daten handelt es sich beispielsweise um Konfigurations- und Anzeigekonfigurationsdaten. Der Experimentmanager EM kann solche Daten in einer Datenbank DB abspeichern.
Der Experimentmanager EM kann mit einer Testumgebung TU oder mehreren Testumgebungen TU innerhalb der Computerressource CR verbindbar sein und/oder mit einer Testumgebung oder mehreren Testumgebungen TU außerhalb der Computerressource CR verbindbar sein. Zugleich ist es möglich, dass der Experimentmanager mit mehreren Testumgebungen TU gleichzeitig, sei es innerhalb der Computerressource CR oder außerhalb der Computerressource CR verbunden ist.
Ist die Testumgebung TU innerhalb der Computerressource CR kann es sich insbesondere um eine Testumgebung handeln, die ausgebildet ist, eine Software zu prüfen, die mithin einen Software-in-the-Loop-Simulator SIL aufweist. Bei den Testumgebungen TU außerhalb der Computerressource CR kann es sich insbesondere um Testumgebungen TU handeln, die zumindest einen Software-in-the- Loop-Simulator SIL und/oder einen Hardware-in-the- Loop-Simulator HIL aufweisen.
Wie zuvor dargestellt, melden sich die Testumgebungen TU bei dem Experimentmanager EM an und übertragen Anmeldedaten, die sich auf die Identität der Testumgebung beziehen und Konfigurationsdaten, die sich auf die Gegebenheiten der Testumgebung TU beziehen. Die Anmeldedaten erlauben es dem Experimentmanager eine Anmeldeberechtigung der jeweiligen Testumgebung zu ermitteln. Liegt diese Anmeldeberechtigung nicht vor, so wird eine Anmeldung abgelehnt. Der Experimentmanager EM übermittelt die Konfigurationsdaten und/oder die Anmeldedaten an eine Datenbank DB zur Speicherung.
Die Anmeldung der Testumgebungen TU erfolgt wie zuvor dargestellt, mittels eines jeweiligen Softwareagenten SWA. Der Softwareagent SWA ermöglicht, dass sich die Testumgebung TU selbstständig bei dem Experimentmanager EM anmeldet. Auch eine Abmeldung beispielsweise, wenn die Testumgebung TU analysiert, dass sie nicht mehr funktionsgemäß arbeitet, ist über den Softwareagenten SWA möglich. Der Softwareagent SWA meldet sich nicht nur für die jeweilige Testumgebung beim Experimentmanager EM an, sondern überträgt auch die Anmeldedaten und Konfigurationsdaten für den Experimentmanager EM bezüglich der jeweiligen Testumgebung TU.
Nach der Anmeldung beim Experimentmanager EM kann die Benutzeranwendung BA mit der Messinstanz MI in Verbindung treten, um über diese Anzeige- und Steuerdaten mit der Testumgebung TU auszutauschen. Die Messinstanz MI kann dabei so eingerichtet sein, dass über sie gleichzeitig mehrere Benutzeranwendungen BA mit jeweils einer oder jeweils mehreren Testumgebungen TU Daten austauschen können. Eine jeweilige Messinstanz MI kann dabei zudem mit einer jeweiligen Benutzeranordnung BA Steuerdaten und Anzeigedaten austauschen. Eine jeweilige Messinstanz MI kann dabei zudem mit einer jeweiligen Testumgebung TU Messdaten und Steuerdaten austauschen.
Figur 2 zeigt schematisch beispielhaft eine weitere Ausführungsform des Systems mit einer Benutzeranwendung BA, einem Benutzer AW, der Computerressource CR und zwei Testumgebungen TU. Das System ist in Fig. 2 mit einer größeren Detailtiefe als Fig. 1 dargestellt.
Eine der Testumgebungen TU weist einen Hardware-in-the-Loop-Simulator HIL auf und befindet sich außerhalb der Computerressource CR. Diese Testumgebung TU weist neben dem Hardware-in-the-Loop-Simulator HIL das (nicht dargestellte) zu testende System auf, welches vorliegend als Hardware ausgebildet ist. Das zu testende System ist zu den erwähnten Testzwecken an den Hardware-in- the-Loop-Simulator HIL angeschlossen. Eine andere Testumgebung TU weist einen Software-in-the-Loop-Simulator SIL auf und befindet sich innerhalb der Computerressource CR. Diese Testumgebung TU weist neben dem Software-in- the-Loop-Simulator SIL ein (nicht dargestelltes) zu testendes System auf, welches vorliegend als Software ausgebildet ist. Das zu testende System ist zu den erwähnten Testzwecken an den Software-in-the-Loop-Simulator SIL angeschlossen.
Der Benutzer AW benutzt seine Benutzeranwendung BA über einen Browser BRW. Bei dem Browser BRW kann es sich beispielsweise um einen sogenannten Webbrowser handeln, der eine Anwendung ist, um Internetseiten anzuzeigen.
Die Benutzeranwendung BA führt eine Anmeldung über die Verbindung 100 mit Anzeigekonfigurationsdaten über eine erste Anmeldeschnittstelle AS-1 beim Experimentmanager EM durch. Die Anzeigekonfigurationsdaten sagen aus, was der Benutzer AW dargestellt bekommen möchte, beispielsweise Wertebereiche und andere Parameter. Der Experimentmanager EM speichert über die Verbindung 102 diese Daten wie auch andere Daten in der Datenbank DB ab. Dann tritt die Benutzeranwendung BA über die Kontrollschnittstelle KS mit der Messinstanz MI in Verbindung, um Anzeige- und Steuerdaten mit der Messinstanz MI auszutauschen. Dies geschieht über die Verbindung 101. Der Experimentmanager EM mit seinen Anmeldeschnittstellen AS-1 und AS-2 sowie die Messinstanz MI mit der Kontrollschnittstelle KS, aber auch der weiteren Messschnittstelle MS sind alle in der Computerressource CR angeordnet, ebenso die Datenbank DB.
Testumgebungsseitig meldet sich die SIL Testumgebung TU über ihren Softwareagenten SWA über die Verbindung 103 über die zweite Anmeldeschnittstelle AS-2 bei dem Experimentmanager EM an. Die HIL Testumgebung TU meldet sich über ihren Softwareagenten SWA über die Verbindung 107 über die zweite Anmeldeschnittstelle AS-2 bei dem Experimentmanager EM an.
Bei der jeweiligen Anmeldung der Testumgebung TU werden auch Konfigurationsdaten über die Testumgebung TU beim Experimentmanager EM hinterlegt, die dieser wieder über die Verbindung 102 in der Datenbank DB ablegt. Weiterhin verbinden sich die Testumgebungen TU über die Verbindungen 104 und 106 über die Messschnittstelle MS mit der Messinstanz MI. Auch hierfür wird der jeweilige Softwareagent SWA verwendet.
Die Computerressource CR kann insbesondere so ausgebildet sein, dass der Experimentmanager EM, die Messinstanz MI und/oder der Nachbearbeitungsdienst PPS Daten in der Datenbank DB ablegen können und diese auch wieder auslesen können. Insbesondere können Konfigurationsdaten in der Datenbank DB abgelegt und wieder ausgelesen werden. Die Datenbank DB kann somit auch der Speicherort für - insbesondere innerhalb der Computerressource - gemeinsam genutzte Daten sein. Somit kann eine Datenaustausch der gemeinsam genutzten Daten über die Datenbank DB realisiert werden.
Zur Ermöglichung des Zugriffs der Testumgebung TU auf die Messinstanz MI, meldet sich die Testumgebung TU, wie oben beschrieben, über den jeweiligen Softwareagenten SWA am Experimentmanager EM an. Dieser ist z.B. über eine feste, der Testumgebung TU bekannte, Adresse erreichbar. Der Softwareagent SWA der Testumgebung TU bekommt vom Experimentmanager EM die Adresse der Messinstanz MI mitgeteilt, über die er die weitere Kommunikation durchführt. In ähnlicher Weise erfolgt der Zugriff auf die Messinstanz MI durch die Benutzeranwendung BA. Die Benutzeranwendung BA bekommt vom Experimentmanager EM die Adresse der Messinstanz MI mitgeteilt. Daraufhin kann die Kommunikation, insbesondere der Austausch von Messdaten, zwischen der Benutzeranwendung BA und der Testumgebung TU über die Messinstanz MI erfolgen. Eine Messinstanz MI kann dabei mit mehreren Testumgebungen TU kommunizieren. Im Falle hoher Auslastung können weitere Messinstanzen MI gestartet werden. Dieser Start bei hoher Auslastung kann z.B. durch eine übergeordnete Kontrollinstanz der Computerressource CR erfolgen. Sich neu anmeldende Benutzeranwendungen BA und Testumgebungen TU können dann die weiteren, neu gestarteten, Messinstanzen MI zugewiesen bekommen.
Die Verbindung 106 zwischen der HIL Testumgebung TU und der Messinstanz MI dient zum Austausch von Steuerdaten und Messdaten, wobei die Steuerdaten von der Messinstanz MI geliefert werden und die Messdaten von der Testumgebung TU. Steuerdaten werden ursprünglich von der Benutzeranwendung BA über die Verbindung 101 an die Messinstanz MI geliefert, von dieser ggf. bearbeitet und über die Verbindung 106 and die HIL Testumgebung TU übermittelt.
Die HIL Testumgebung TU außerhalb der Computerressource CR. verfügt weiter über einen optionalen Speicher R2, in dem der Softwareagent SWA der Testumgebung TU Messdaten abspeichern kann. Auf diesem Weg können Messdatenlokal gespeichert werden, was insbesondere von Vorteil sein kann, wenn sie mit sehr hohem Datendurchsatz auftreten. Das ist insbesondere dann sinnvoll, wenn die Verbindung 106, die ja über ein Kommunikationsnetzwerk global sein kann, in Bezug auf Latenz (Verzögerung) und Datendurchsatz (Datenmenge pro Zeit) die in der Testumgebung TU anfallenden Messdaten nicht ausreichend schnell aufnehmen kann. In einem späteren Arbeitsschritt können die im optionalen Speicher R2 abgelegten Daten über die Datenverbindung 106 an die Messinstanz MI übermittelt werden.
Über die Verbindung 105 können Messdaten von der Messinstanz MI für eine Nachbearbeitung einem Nachbearbeitungsdienst PPS zugeführt werden. Der Nachbearbeitungsdienst PPS legt diese Messdaten über die Verbindung 108 in dem Speicher RI ab.
Ebenso ist bietet der Nachbearbeitungsdienst PPS die Möglichkeit, die aufgezeichneten Daten zur Analyse erneut abzuspielen und/oder gezielt abzurufen. Die Darstellung der erneut abgespielten und/oder gezielt abgerufenen Messdaten erfolgt dann insbesondere in der Benutzeranwendung BA. Die Messdaten lassen sich dabei entweder bezogen auf einen bestimmten Zeitpunkt und/oder bezogen auf zu einem bestimmten Zeitraum abrufen und darstellen und/oder die Daten können wie im Film wieder abgespielt werden. Damit ist ein Fernzugriff für die Benutzeranwendung BA auf die im Speicher RI gespeicherten Messdaten über den Nachbearbeitungsdienst PPS und die Messinstanz MI möglich.
Aus der Figurenbeschreibung zu Figur 1 und zu Figur 2 folgt auch, dass für die Computerressource CR ein Fernzugriff für die Benutzeranwendung BA auf die jeweiligen Testumgebungen TU über die Messinstanz MI ermöglicht ist.
In Figur 3 wird das Verfahren in einem Flussdiagramm dargestellt.
In Verfahrensschritt 300 melden sich die Testumgebungen TU beim Experimentmanager EM über ihren jeweiligen Softwareagenten SWA an. In Verfahrensschritt 302 meldet sich die Benutzeranwendungen BA sich beim Experimentmanager EM an. Die Anmeldung von Testumgebungen TU und Benutzeranwendung BA am Experimentmanager kann auch in umgekehrter Reihenfolge erfolgen.
In Schritt 304 werden dann Steuerdaten über die Verbindung 101 von der Benutzeranwendung BA an die Messinstanz MI übermittelt und über zumindest eine der Verbindungen 106, 104 an zumindest eine der Testumgebungen TU übermittelt.
Die Testumgebung TU führt unter Verwendung der Steuerdaten entsprechende Tests/Simulationen/Messungen an dem zu prüfenden System durch und über- trägt die so ermittelten Messdaten über die Verbindung 106, 104 an die Messinstanz MI. Die Messdaten beziehen sich auf die durchgeführten Messung und/oder die durchgeführte Simulation und/oder auf den durchgeführten Test. Insbesondere können die Messdaten am zu prüfenden System erfasste Messwerte umfas- sen.
Die Messinstanz MI bearbeitet die Messdaten, passt sie an die Benutzeranwendung BA an und überträgt die entsprechend aufbereiteten Messdaten als Anzeigedaten and die Benutzeranwendung BA über die Verbindung 101.
Damit ist der Fernzugriff von einer oder mehreren Benutzeranwendungen BA auf eine oder mehrere Testumgebungen TU ermöglicht.
Bezugszeichenliste
AW Nutzer;
AS-1 erste Anmelde-Schnittstelle;
AS-2 zweite Anmelde-Schnittstelle;
BRW Browser;
BA Benutzeranwendung;
TU Testumgebung;
CR Computerressource;
EM Experimentmanager;
KS Kontroll-Schnittstelle;
MS Mess-Schnittstelle;
DB Datenbank;
MI Messinstanz;
PPS Nachbearbeitungsdienst;
HIL Hardware-in-the- Loop-Simulator;
SIL Software-in-the- Loop-Simulator;
SWA Softwareagent;
RI, R2 Speicher;
100 Verbindung mit Datenaustausch : Anmeldung,
Anzeigekonfigurationsdaten ;
101 Verbindung mit Datenaustausch : Anzeigedaten, Steuerdaten;
102 Verbindung mit Datenaustausch : Informationen zu Anmeldungen,
Steuerdaten, Konfigurationsdaten, Anzeigekonfigurationsdaten;
103 Verbindung mit Datenaustausch : Anmeldung, Konfigurationsdaten;
104 Verbindung mit Datenaustausch : Steuerdaten, Messdaten;
105 Verbindung mit Datenaustausch : Messdaten;
106 Verbindung mit Datenaustausch : Steuerdaten, Messdaten;
107 Verbindung mit Datenaustausch : Anmeldung, Konfigurationsdaten;
108 Verbindung mit Datenaustausch : Messdaten;
300-304 Verfahrensschritte.

Claims

Ansprüche
1. Vorrichtung für einen Fernzugriff auf zumindest eine Testumgebung (TU) durch zumindest eine Benutzeranwendung (BA), wobei die Vorrichtung als eine über ein Kommunikationsnetz verfügbare Computerressource (CR) ausgebildet ist, wobei die Computerressource (CR.) einen Experimentmanager (EM) und wenigstens eine Messinstanz (MI) aufweist, wobei der Experimentmanager (EM) der wenigstens einen Benutzeranwendung (BA) eine erste Anmelde-Schnittstelle (AS-1) zur Anmeldung über das Kommunikationsnetz zur Verfügung stellt und der wenigstens einen Testumgebung (TU) eine zweite Anmelde-Schnittstelle (AS-2) zur Anmeldung, insbesondere über das Kommunikationsnetz, zur Verfügung stellt, wobei die zweite Anmelde-Schnittstelle (AS-2) für die Anmeldung der zumindest einen Testumgebung (TU) die Anmeldung über einen Softwareagenten (SWA) vorsieht, wobei die wenigstens eine Messinstanz (MI) eine Kontroll-Schnittstelle (KS) für die wenigstens eine Benutzeranwendung (BA) und eine Mess-Schnittstelle (MS) für die wenigstens eine Testumgebung (TU) aufweist, wobei vorgesehen ist, über die Kontroll-Schnittstelle (KS) Anzeigedaten an die wenigstens eine Benutzeranwendung (BA) zu übermitteln und von der wenigstens einen Benutzeranwendung (BA) Steuerdaten für die Testumgebung zu empfangen, wobei vorgesehen ist, über die Mess-Schnittstelle (MS) die Steuerdaten an die wenigstens eine Testumgebung (TU) zu übermitteln und Messdaten für die Erzeugung der Anzeigedaten von der wenigstens einen Testumgebung (TU) zu empfangen, so dass für die wenigstens eine Benutzeranwendung (BA) ein Fernzugriff auf die wenigstens eine Testumgebung (TU) ermöglicht ist.
2. Vorrichtung nach Anspruch 1, wobei im Zusammenhang mit der Anmeldung der Testumgebung (TU) Informationen über die Testumgebung (TU) als Konfigurationsdaten an den Experimentmanager (EM) übermittelbar sind.
3. Vorrichtung nach Anspruch 2, wobei die wenigstens eine Messinstanz (MI) dazu eingerichtet ist, die Messdaten für die Erzeugung der Anzeigedaten in Abhängigkeit von Anzeigekonfigurationsdaten zu bearbeiten.
4. Vorrichtung nach Anspruch 2 oder 3, wobei die wenigstens eine Messinstanz (MI) dazu eingerichtet ist, die Steuerdaten vor der Übermittlung an die wenigstens eine Testumgebung (TU) in Abhängigkeit von den Konfigurationsdaten zu bearbeiten.
5. Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die Computerressource (CR) eine Datenbank (DB) aufweist, die für die Speicherung von Informationen zu den Anmeldungen, den Steuerdaten, den Messdaten, den Konfigurationsdaten und/oder den Anzeigekonfigurationsdaten vorgesehen ist, wobei die Speicherung insbesondere durch den Experimentmanager (EM) vorgesehen ist.
6. Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die Computerressource einen Nachbearbeitungsdienst (PPS) aufweist, der dazu eingerichtet ist, die Messdaten aufzuzeichnen, zu verwalten und Zugriff auf die Messdaten zu gewähren.
7. Vorrichtung nach Anspruch 6, wobei für die Speicherung der Messdaten die Datenbank (DB) und/oder ein weiterer Speicher (RI) vorgesehen ist.
8. Verfahren für einen Fernzugriff auf zumindest eine Testumgebung (TU) durch wenigstens eine Benutzeranwendung (BA), wobei eine über ein Kommunikationsnetz verfügbare Computerressource (CR.) verwendet wird, welche einen Experimentmanager (EM) und wenigstens eine Messinstanz (MI) aufweist, wobei das Verfahren aufweist:
Anmelden der zumindest einen Benutzeranwendung (BA) an dem Experimentmanager (EM),
Anmelden der zumindest einen Testumgebung (TU) an dem Experimentmanager (EM), wobei die wenigstens eine Testumgebung (TU) für ihre Anmeldung einen Softwareagenten (SWA) verwendet, wobei die wenigstens eine Messinstanz (MI) eine Kontroll-Schnittstelle (KS) für die wenigstens eine Benutzeranwendung (BA) und eine Mess-Schnittstelle (MS) für die wenigstens eine Testumgebung (TU) aufweist, wobei die wenigstens eine Messinstanz (MI) Anzeigedaten an die zumindest eine Benutzeranwendung (BA) übermittelt und von der zumindest einen Benutzeranwendung (BA) Steuerdaten für die Testumgebung empfängt, wobei die wenigstens eine Messinstanz (MI) die Steuerdaten an die wenigstens eine Testumgebung (TU) übermittelt und Messdaten für die Erzeugung der Anzeigedaten von der wenigstens einen Testumgebung (TU) empfängt, so dass für die wenigstens eine Benutzeranwendung (BA) ein Fernzugriff auf die wenigstens eine Testumgebung (TU) ermöglicht wird.
9. Verfahren nach Anspruch 8, wobei die Testumgebung (TU) im Zusammenhang mit der Anmeldung Informationen über die Testumgebung (TU) als Konfigurationsdaten an den Experimentmanager übermittelt.
10. Verfahren nach Anspruch 9, wobei die wenigstens eine Messinstanz (MI) die Messdaten für die Erzeugung der Anzeigedaten in Abhängigkeit von Anzeigekonfigurationsdaten bearbeitet.
11. Verfahren nach Anspruch 9 oder 10, wobei die wenigstens eine Messinstanz (MI) die Steuerdaten vor der Übermittlung die zumindest eine Testumgebung (TU) in Abhängigkeit von den Konfigurationsdaten bearbeitet.
12. Verfahren nach einem der Ansprüche 8 bis 11, wobei der Experimentmanager (EM) Informationen zu den Anmeldungen, den Steuerdaten, den Messdaten, den Konfigurationsdaten und/oder den Anzeigekonfigurationsdaten in einer Datenbank (DB) abspeichert.
13. Verfahren nach einem der Ansprüche 8 bis 12, wobei ein Nachbearbeitungsdienst (PPS) die Messdaten aufzeichnet, verwaltet und/oder Zugriff auf diese Messdaten gewährt.
14. Benutzeranwendung (BA) für eine Vorrichtung nach einem der Ansprüche 1 bis 7, die dazu eingerichtet ist, mit der Vorrichtung über das Kommunikationsnetzwerk zu kommunizieren, wobei die Benutzeranwendung (BA) eine Nutzerschnittstelle zur Anzeige der Anzeigedaten und zur Eingabe der Steuerdaten aufweist.
15. Testumgebung (TU) für eine Vorrichtung nach einem der Ansprüche 1 bis 7, die dazu eingerichtet ist, mit der Vorrichtung zu kommunizieren, wobei die Testumgebung (TU) dazu eingerichtet ist, ein zu testendes System zu testen und die Messdaten zu erzeugen, wobei die Messdaten von dem Testen des zu testenden Systems abhängen.
16. Testumgebung nach Anspruch 15, wobei die Testumgebung (TU) den Softwareagenten (SWA) aufweist, wobei der Softwareagent (SWA) für die Anmeldung an dem Experiment-Manager (EM) vorgesehen ist.
17. Testumgebung nach Anspruch 15 oder 16, wobei die Testumgebung (TU) zur Kommunikation mit der Vorrichtung über das Kommunikationsnetzwerk vorgesehen ist.
18. System mit einer Vorrichtung nach einem der Ansprüche 1 bis 7, einer Benutzeranwendung (BA) nach Anspruch 14 und einer Testumgebung (TU) nach einem der Ansprüche 15 bis 17.
EP23836346.9A 2023-02-16 2023-12-14 Vorrichtung und verfahren für einen fernzugriff auf zumindest eine testumgebung durch wenigstens eine benutzeranwendung Pending EP4666172A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102023103766.8A DE102023103766A1 (de) 2023-02-16 2023-02-16 Vorrichtung und Verfahren für einen Fernzugriff auf zumindest eine Testumgebung durch wenigstens eine Benutzeranwendung
PCT/EP2023/085746 WO2024170132A1 (de) 2023-02-16 2023-12-14 Vorrichtung und verfahren für einen fernzugriff auf zumindest eine testumgebung durch wenigstens eine benutzeranwendung

Publications (1)

Publication Number Publication Date
EP4666172A1 true EP4666172A1 (de) 2025-12-24

Family

ID=89474911

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23836346.9A Pending EP4666172A1 (de) 2023-02-16 2023-12-14 Vorrichtung und verfahren für einen fernzugriff auf zumindest eine testumgebung durch wenigstens eine benutzeranwendung

Country Status (4)

Country Link
EP (1) EP4666172A1 (de)
JP (1) JP2026506044A (de)
DE (1) DE102023103766A1 (de)
WO (1) WO2024170132A1 (de)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130305222A1 (en) * 2012-05-11 2013-11-14 Microsoft Corporation Development System
KR20140099109A (ko) * 2013-02-01 2014-08-11 한국전자통신연구원 다중 클라우드를 이용한 응용 서비스 시험 지원 시스템 및 그 방법
CN105446872B (zh) * 2014-08-29 2018-04-10 国际商业机器公司 测试移动应用的管理器、测试代理器及方法
US12038456B2 (en) * 2020-11-05 2024-07-16 Tektronix, Inc. Multi-user test instrument

Also Published As

Publication number Publication date
DE102023103766A1 (de) 2024-08-22
JP2026506044A (ja) 2026-02-20
WO2024170132A1 (de) 2024-08-22

Similar Documents

Publication Publication Date Title
EP2685382B1 (de) Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms
EP2715677B1 (de) Diagnosevorrichtung für kraftfahrzeuge und diagnoseverfahren
DE102008010299A1 (de) Verfahren zum Testen eines Mobilfunkgeräts
EP3736688A1 (de) Virtuelles steuergerät
EP3832517A1 (de) Computerimplementiertes verfahren zur einbindung mindestens eines signalwerts in einem virtuellen steuergerät
DE102011052512A1 (de) Verfahren zur Verarbeitung von Daten in einem Beeinflussungsgerät
DE102019111558A1 (de) Verfahren und system zum testen von systemen
WO2024170132A1 (de) Vorrichtung und verfahren für einen fernzugriff auf zumindest eine testumgebung durch wenigstens eine benutzeranwendung
EP2672660B1 (de) Verfahren zur Beeinflussung der Buskommunikation eines Steuergeräts
EP4735963A1 (de) VERFAHREN UND SYSTEM ZUR DURCHFÜHRUNG EINER MAßNAHME AN EINEM HYDRAULIKGERÄT
EP3211830A1 (de) Verfahren zum überwachen und planen einer produktionszelle und netzwerkmanagementsystem für eine produktionszelle
DE102008064337B4 (de) Automatische Reproduzierung eines Anlagenverhaltens
EP3553679A1 (de) Verfahren zur computergestützten fehlerdiagnose für ein technisches system
EP4204826B1 (de) Programmierbare signalverarbeitungseinheit und verfahren zum betrieb einer programmierbaren signalverarbeitungseinheit
DE10121587A1 (de) Verfahren und Vorrichtung zur automatisierten Prüfung grundlegender CAN-Eigenschaften von Steuergeräten
EP4174660B1 (de) Verfahren zum testen von steuergeräte
DE102019117839A1 (de) Verfahren, Vorrichtung, Computerprogramm und Computerprogrammprodukt zur Datenverarbeitung in einem Fahrzeug und Fahrzeug
EP2653850A1 (de) Verfahren und IT-System zum Durchführen von Gesamtfahrzeugtests
DE102023106786A1 (de) Prüfstand, Fahrzeug, System und Verfahren zur Steuergeräteprüfung
EP3720056B1 (de) Verfahren und system zur parallelen echtzeitanalyse bei funktionsprüfungen von hardware und software von steuergeräten
DE102023207751A1 (de) Verfahren und System zur Durchführung einer Maßnahme an einem virtuellen Hydraulikgerät
DE19529342C2 (de) Verfahren zur Visualisierung des Überdeckungsgrades beim Test eines endlichen Automaten
DE102024131539A1 (de) Testumgebung und computerimplementiertes Verfahren zum Überprüfen einer Kommunikation
DE102021125430A1 (de) Verfahren zur automatisierten Fehleridentifikation von Hardware/Software-Systemen
EP3193221A1 (de) Signalpfadüberprüfungsvorrichtung

Legal Events

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

Free format text: STATUS: UNKNOWN

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

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 ME MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: DSPACE SE & CO. KG