WO2011023487A1 - Verfahren zur prüfung der modellierung technischer systeme - Google Patents

Verfahren zur prüfung der modellierung technischer systeme Download PDF

Info

Publication number
WO2011023487A1
WO2011023487A1 PCT/EP2010/061003 EP2010061003W WO2011023487A1 WO 2011023487 A1 WO2011023487 A1 WO 2011023487A1 EP 2010061003 W EP2010061003 W EP 2010061003W WO 2011023487 A1 WO2011023487 A1 WO 2011023487A1
Authority
WO
WIPO (PCT)
Prior art keywords
modeling
sysml
description language
feature
uml
Prior art date
Application number
PCT/EP2010/061003
Other languages
English (en)
French (fr)
Inventor
Thomas Ehben
Nasser Jazdi
Camelia Maga
Thilo Tetzner
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to US13/392,752 priority Critical patent/US20120158386A1/en
Publication of WO2011023487A1 publication Critical patent/WO2011023487A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques

Definitions

  • the invention relates to a method and a system for testing the modeling of technical systems within the engineering or design process for technical systems.
  • SysML of the OMG (Object Management Group) exists. Based on this language are simple Variant formations representable, but not with a simultaneous description of explicit rules for their combinatorics. In addition, they do not offer the possibility to present a complete system version with several selection decisions of different characteristics, some of which can be made independently (http://www.omgsysml.org/).
  • the object of the present invention is to provide a method and a system for testing possible variants in the modeling of technical systems, wherein the test is based on a general standard and is applicable across technologies or interdisciplinary.
  • the object is provided with a method for automatically testing the modeling of technical systems, in particular of technical installations, within an engineering or design process, comprising the following steps:
  • a first advantageous embodiment of the invention is that the method comprises, as a further step, the display of incompatibilities in the modeling on the output medium. An operator is immediately alerted to model incompatibilities (e.g., mating of improper components such as the assembly of an electric motor with an exhaust) and receives a warning. Recognizing incompatibilities at an early stage of the planning process avoids expensive later changes.
  • a further advantageous embodiment of the invention is that the method is integrated into a modeling application or modeling environment. Here, too, there is an advantage in detecting incompatibilities in an early phase of the planning process when applying the method in a modeling application.
  • a further advantageous embodiment of the invention is that the method as a stand-alone application reali- is siert.
  • the method can thus be integrated into a modeling application or modeling environment, but it can also be used as a stand-alone application (eg as a desktop application).
  • a further advantageous embodiment of the invention is that the modeling takes place in the description language SysML or UML.
  • SysML and UML are widely used standard languages for modeling products or systems, not just software projects.
  • FODA e.g. is very specific and not widely used.
  • SysML or UML ensures that no tool break or method break occurs, because SysML or UML are increasingly used anyway as design tools.
  • a further advantageous embodiment of the invention lies in the fact that the first and second elements of the system description language are formed by stereotypes of the description language SysML or UML.
  • the construct of the stereotypes allows for easy extensibility of the description language, flexibly tailored to specific needs (e.g., domains, industries, products) and constraints (e.g., project requirements).
  • a further advantageous embodiment of the invention is that the system components, the relationships between the system components and the rules are mapped to a common data format in which the compatibility check is performed.
  • This facilitates an automatic compatibility check.
  • a data format e.g. XMI (XML Metadata Interchange) can be used, this allows an examination by standard XML parser.
  • XMI is a popular exchange format for UML or SysML models.
  • a further advantageous embodiment of the invention is that the method for modeling variants of technical components and / or products and / or systems and / or equipment is used. This enables a forma- ble variant formation and representation.
  • a further advantageous embodiment of the invention lies in the fact that, during automatic checking, the data records to be checked are provided as a file or data stream via a network connection of the test unit as a standardized data exchange format, in particular XML, and the check is carried out with a standard parser.
  • the test is therefore not restricted to special or proprietary data formats and can be performed with standard tools (for example, standard XML parser).
  • the object is further achieved with an engineering system or a software development environment for performing the method.
  • Standard off-the-shelf tools can be used, such as CAx tools, PLM tools (PLM stands for Product Lifecycle Management), engineering tools, or custom (customized) tools are used.
  • Method integration into an existing engineering system ensures that no method and media break occurs. This increases the quality and efficiency of the modeling or modeling results.
  • SysML blocks and packages represent technical systems and their properties.
  • FIG. 1 shows an optional feature of a SysML block
  • FIG. 2 shows a required feature of a SysML block
  • FIG. 3 shows an alternative feature of a SysML block
  • FIG. 4 shows a selected feature of a SysML block (variant with "or")
  • FIG. 5 shows a selected feature of a SysML block (variant with "choice")
  • FIG. 6 shows an optional feature of a SysML packet
  • FIG. 7 shows a required feature of a SysML packet
  • FIG. 8 shows an alternative feature of a SysML packet
  • FIG. 10 shows a selected feature of a SysML packet (variant with "choice")
  • FIG. 11 shows an exemplary flow chart for carrying out the method
  • the stereotype stereotype is an extension of existing model elements of a description language that supports stereotypes, such as Unified Modeling Language (UML) or Systems Modeling Language (SysML).
  • stereotypes primarily indicate the possible usage contexts (usage context) of a class, a relationship or a package.
  • a stereotype specifies, such as a metaclass predefined by the UML meta-model for a specific field of application can be adapted.
  • Stereotypes can be created or adapted, ie formalized, for specific domains, industries or products. Stereotypes can further define and formalize rules for the composition of components of these domains, industries or products.
  • UML or SysML models can be mapped to data formats (eg XML or XMI), allowing for automatic checking for incompatibilities in these data formats.
  • data formats eg XML or XMI
  • stereotypes the width of a description language can be specifically flexibly extended or adapted by a user.
  • a representation of system variants based on the SysML or UML description language is proposed. This is achieved by an enrichment of SysML or UML by additionally defined stereotypes.
  • the power of these description languages allows the definition of additional stereotypes to extend the scope of speech that can be used by a user.
  • the method can be applied to any description language that offers stereotypes or similar constructs.
  • Stereotypes can be used to define rules for arranging and combining (for example, aggregating) language elements that allow syntactic and semantic verification of a descriptive language model.
  • a user is thereby automatically (online or in batch mode) pointed to incompatibilities of the model. Batching is particularly useful in modeling large systems that consist of many subsystems and that involve many modelers (e.g., system architects). After merging (merging) the partial models, a check for incompatibilities can take place in batch mode.
  • FIGS. 1 to 10 each show ways of presenting variants based on blocks and packets. Blocks and packages are integral parts of the
  • FIGS. 1 to 5 show a variant representation on the basis of the speech constructs block.
  • FIGS. 6 to 10 show a variant representation on the basis of the language constructs packages.
  • An optional feature of an entity is represented by a respective SysML block for the entity EE1 and its feature EE2, and the relationship between entity and feature is replaced by a new SysML Stereotype ZEl, which is based on the symbol aggregation and is supplemented by the text "optional”.
  • a required feature of an entity is represented by a respective SysML block for the entity EE3 and its feature EE 4.
  • the relationship between entity and feature is replaced by a new SysML Stereotype ZE2 is shown, which is based on the symbol for a composition and is supplemented by the additional text "mandatory".
  • Feature of a set of possible features is represented by a SysML block for the entity EE5 and one block EE6, EE7 for two or more possible variants, of which exactly one can be selected.
  • the relationship between entity EE5 and feature EE6, EE7 is replaced by a new one
  • SysML stereotype ZE3 which is based on the symbol for generalization (inheritance) and is supplemented by the text "alternative.”
  • FIG 4 shows a "selected feature" of a SysML or UML block (variant with "or”).
  • a selected feature of an entity is identified by a SysML block EE8 for the Entity and one block EE9, EE10 for two or more possible variants, one or more of which can be selected represented.
  • the relationship between entity and feature is represented by a new SysML stereotype ZE4, which is based on the symbol for an aggregation and supplemented by the text suffix "or".
  • FIG. 5 shows a "selected feature" of a SysML or UML block (variant with "choice”).
  • a selected feature of an entity is selected by a entity SysML block EEIl and a block EE12, EE13 for two or more possible variants, one or more of which are selected can, represented.
  • the relationship between entity and feature is represented by a new SysML stereotype ZE5, which is based on the symbol for an aggregation and supplemented by the text suffix "choice”.
  • FIGS. 6 to 10 show examples for variant representation on the basis of packets.
  • FIG. 6 shows an "optional feature" of a SysML package or UML package
  • An optional feature of an entity is represented by a respective SysML package or UML package for the entity and its feature
  • the relationship between entity EE14 and feature EE15 is represented by a new SysML stereotype ZE6, which is based on the symbol for an element Import or Package Import and is supplemented by the text "optional”.
  • a required feature of an entity is represented by a respective SysML or UML packet for the entity EE16 and its feature EE17
  • the relationship between entity EE16 and Feature EE17 is represented by a new SysML stereotype ZE7, which appears on the symbol for an egg ment Import or Package Import is based and supplemented by the text addition "mandatory”.
  • FIG. 8 shows an "alternative feature" of a SysML packet or UML packet
  • An alternative feature of an entity is represented by a entity SysML block EE18 and an auxiliary package EE19.
  • entity SysML block EE18 and an auxiliary package EE19.
  • auxiliary package EE19 their individual feature variants, from which exactly one can be selected, are represented as further packages
  • the relationship between entity EE18 and feature is represented by a new SysML stereotype ZE8 , which is based on the symbol for an item Import or Package Import, and is supplemented by the text "xor" or "alternative", located between the entity EE18 and the aid package EE19.
  • a selected feature of an entity is represented by a SysML block for the entity EE20 and an auxiliary package EE21 representing the set of possible features.
  • Auxiliary packages EE21 are their individual feature variants, from which one or more can be selected, represented as further packages.
  • the relationship between entity EE20 and feature is represented by a new SysML stereotype ZE9, which is based on the symbol for an element Import or Package Import and is supplemented by the text suffix "or" or "choice". It is located between the entity EE20 and the aid package EE21.
  • a selected feature of an entity is represented by a SysML block for the entity EE22 and an auxiliary package EE23 representing the set of possible features.
  • auxiliary package EE23 representing the set of possible features.
  • Auxiliary packages EE23 are their individual feature variants, from which one or more can be selected, represented as further packages.
  • the relationship between entity EE22 and feature is represented by a new SysML stereotype ZE10, which is based on the symbol for an element Import or Package Import and is supplemented by the text suffix "or" or "choice". It is located between the entity EE22 and the aid package EE23.
  • FIG. 11 shows an exemplary flow diagram for carrying out the method for modeling technical systems within an engineering or design process.
  • step Modeling M the (usually graphical or tabular) description of a technical system (product equipment, machine, robot, etc.), a product (cam-corder, vehicle, etc.), or a technical problem to be solved (eg efficient energy transfer from a producer to a consumer).
  • the modeling takes place in a suitable description language (eg UML, SysML) by a user (eg sales or automation engineer) by input and output means on a computer (eg laptop, PC).
  • the language element stereotype can be used in the description language to define rules for assembling and combining objects.
  • the description language can thus be expanded by a user in terms of industry, domain or product.
  • a branch-, domain- or product-specific variant formation can be represented in a formalized way.
  • the formalized representation is a prerequisite for an automatic check P of a created model for incompatibilities.
  • Check P can be done online or in batch mode.
  • the steps Convert K and Display A are optional.
  • a data exchange format eg XML or XMI
  • the coupling / integration to other tools eg simulation programs
  • standard parsers for the check for incompatibilities exist for standardized data exchange formats (eg XML)
  • Graphical display A of incompatibilities in the model allows a user to immediately and specifically improve incorrect entries.
  • FIG. 12 shows an exemplary system 10 for implementing the method.
  • the method may be integrated, for example, by a software tool of an engineering system, a CAx tool (CAD, CAM, etc.), or a Product Lifecycle Management (PLM) tool that includes one described in SysML (or in UML or a similar description language) Compare the individual system characteristics with the selection rules described above and inform the user if the selected characteristics are compatible with the regulations. In case of incompatibility, the user has specific hints or Warnings on an output unit 3 (eg screen), which combinations used violate which rules.
  • CAD Computer-CAM
  • PLM Product Lifecycle Management
  • a stand-alone application Here, the tool exists as a stand-alone application that can be started independently of other programs. It preferably reads the data records to be checked as a file or data stream via a network connection.
  • a data format this is e.g. the XMI (XML Metadata Interchange) format in question.
  • a user can perform the modeling in the description language via a computer 1 with the aid of input means 2 (mouse, keyboard, etc.) on the graphical work surface 4 of an output unit 3.
  • input means 2 mouse, keyboard, etc.
  • a database 5 is usually available, which is connected to the computer 1 (laptop, industrial PC, workstation, etc.) via a suitable data connection 6 (cable or wireless). It is also possible to operate the process as a web application service via intranet or Internet.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Verfahren und Engineeringsystem zur automatischen Prüfung der Modellierung von technischen Systemen innerhalb eines Engineering- oder Designprozesses, bei dem die verwendete Beschreibungssprache (z.B. UML oder SysML) durch geeignet definierte Stereotype erweitert wird, insbesondere geeignet zur automatischen Erkennung von Inkompatibilitäten bei der Variantenbildung technischer Systeme oder Produkte.

Description

Beschreibung
Verfahren zur Prüfung der Modellierung technischer Systeme Die Erfindung betrifft ein Verfahren und ein System zur Prüfung der Modellierung von technischen Systemen innerhalb des Engineering- oder Designprozesses für technische Systeme.
Technische Systeme oder Lösungen zeichnen sich häufig durch eine Mischung wiederverwendeter Entwicklungsleistungen und individueller Ausprägungen aus. Für die Realisierung eines Konstruktes werden häufig vorentwickelte Merkmale bereitgehalten, die für die Schaffung einer individuellen Ausprägung des Systems nach spezifischen Regeln kombiniert werden können.
Aus der Softwareindustrie ist der Darstellungsstandard „FODA" (Feature Oriented Domain Analysis) des SEI (Software Engineering Institute) der Carnegie Mellon University in den USA be- kannt (Kang, K.; Cohen, S.; Hess, J. A.; Novak, W. E.; Peter- son, S.A.: Feature Oriented Domain Analysis (FODA) Feasabili- ty Study. Technical Report, Software Engineering Institute (SEI), Carnegie-Mellon University, 1990), der aber nicht weit verbreitet ist und die Darstellung von Varianten technischer Systeme oder technischer Komponenten nur unzureichend unterstützt, da er für die Belange der Softwareindustrie entwickelt wurde.
Eine weitere Variantenbeschreibung, ebenfalls für die Soft- wareentwicklung entworfen, ist mit sog. Variationspunkten gegeben. Diese verbindet eine an FODA angelehnte Kombinations- Syntax mit einer graphischen Darstellung der damit verbundenen Anwendungsfällen (Pohl, Böckle, van der Linden: Software Product Line Engineering, 2000) .
Für Systeme und Lösungen, die über Software hinausgehen, existiert die Beschreibungssprache SysML der OMG (Object Management Group) . Basierend auf dieser Sprache sind einfache Variantenbildungen darstellbar, jedoch nicht unter gleichzeitiger Beschreibung expliziter Regeln für deren Kombinatorik. Außerdem bieten sie nicht die Möglichkeit, eine vollständige Systemausprägung mit mehreren, z.T. unabhängig zu treffenden Auswahlentscheidungen unterschiedlicher Merkmale darzustellen (http://www.omgsysml.org/) .
In der Patentanmeldung US2007/0073429A1 ist ein Verfahren für den Entwurf von Komponenten basierend auf gemeinsamen und un- terschiedlichen Designvarianten offenbart.
Die Aufgabe der vorliegenden Erfindung ist es, ein Verfahren und ein System zur Prüfung möglicher Varianten bei der Modellierung von technischen Systemen anzugeben, wobei die Prüfung auf einem allgemeinen Standard beruht und technologieübergreifend bzw. interdisziplinär anwendbar ist.
Die Aufgabe wird mit einem Verfahren zur automatischen Prüfung der Modellierung von technischen Systemen, insbesondere von technischen Anlagen, innerhalb eines Engineering- oder Designprozesses, umfassend die folgenden Schritte:
a) Modellierung (M) des Systems in einer, insbesondere grafischen, Systembeschreibungssprache durch Ein- und Ausga¬ bemitteln,
wobei Systemkomponenten durch erste Elemente (EEl -
EE23) der Systembeschreibungssprache repräsentiert werden, wobei Beziehungen zwischen den Systemkomponenten oder zwischen den Systemkomponenten und einer Umgebung durch zweite Elemente (ZEl - ZElO) der Systembeschreibungssprache rep- räsentiert werden,
wobei für die Kombination von Systemkomponenten untereinander und für die Modellierung von Beziehungen zwischen Systemkomponenten festlegbare Regeln vorhanden sind, und
wobei die Regeln Anforderungen einer zu verwendenden Technologie und/oder einer Branche und/oder einer Domäne rep¬ räsentieren;
b) automatisches Prüfen (P) durch eine Prüfeinheit, ob das modellierte System kompatibel zu den festgelegten Regeln ist. Das Verfahren ermöglicht ein formalisierbares Spektrum möglicher Kombinationen von Komponenten technischer Systeme oder Produkte und möglicher Komponenten- oder Produktvarianten. Die Kombination von Systemmerkmalen spezifiziert eine individuelle Systemausprägung, während die Regeln, denen jede Kombination genügen muss, durch die verwendete Technologie und/oder Anforderungen der jeweiligen Branche oder Domäne vorgegeben sind. So ist es z.B. für den Käufer eines PKWs möglich, sich für die Diesel- oder Benzinvariante eines Mo- tors zu entscheiden, während die Anzahl „eins" des Motors für sein Fahrzeug durch die Gestaltung von Kraftfahrzeugen allgemein vorgegeben ist. Für das Verfahren sind Standardsoftwarewerkzeuge einsetzbar wie CAx-Tools, PLM-Tools oder Engineeringtools für Produkt- oder Anlagenentwurf. Ein Beispiel für eine Regel ist ein Mindestumfang von Merkmalen. Die Prüfung auf Einhaltung dieser Regel würde dann die Vollständigkeit des Merkmalsatzes sicherstellen.
Eine erste vorteilhafte Ausgestaltung der Erfindung liegt darin, dass das Verfahren als weiteren Schritt das Anzeigen von Inkompatibilitäten in der Modellierung auf dem Ausgabemittel umfasst. Ein Bediener wird sofort auf Inkompatibilitäten bei der Modellierung (z.B. beim Zusammenfügen von unpassenden Komponenten, wie etwa das Zusammenfügen von einem Elektromotor mit einem Auspuff) hingewiesen, und erhält eine Warnung. Das Erkennen von Inkompatibilitäten in einer frühen Phase des Planungsprozesses vermeidet teuere spätere Änderungen . Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass das Verfahren in eine Modellierungs-Applikation oder Modellierungsumgebung integriert ist. Auch hier liegt ein Vorteil im Erkennen von Inkompatibilitäten in einer frühen Phase des Planungsprozesses bei der Anwendung des Verfah- rens in einer Modellierungs-Applikation.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass das Verfahren als Stand-Alone-Applikation reali- siert ist. Das Verfahren kann somit sowohl in eine Modellierungs-Applikation oder Modellierungsumgebung integriert werden, es kann aber auch als Stand-Alone-Applikation verwendet werden (z.B. als Desktop-Applikation) .
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Modellierung in der Beschreibungssprache SysML oder UML erfolgt. SysML und UML sind weitverbreitete Standardsprachen für die Modellierung von Produkten oder Sys- temen und nicht nur für reine Softwareprojekte einsetzbar. FODA z.B. ist sehr spezifisch und nicht weit verbreitet.
Weiterhin stellt der Einsatz von SysML oder UML sicher, dass kein Toolbruch oder Methodenbruch auftritt, da SysML oder UML immer häufiger sowieso als Entwurfswerkzeuge verwendet wer- den.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die ersten und zweiten Elemente der Systembeschreibungssprache durch Stereotypen der Beschreibungssprache SysML oder UML gebildet sind. Das Konstrukt der Stereotypen ermöglicht eine einfache Erweiterbarkeit der Beschreibungssprache, flexibel zugeschnitten bzw. adaptierbar auf jeweilige Anforderungen (z.B. Domänen, Branchen, Produkte) und Randbedingungen (z.B. Projekterfordernisse).
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Systemkomponenten, die Beziehungen zwischen den Systemkomponenten und die Regeln auf ein gemeinsames Datenformat abgebildet werden, in welchem die Kompatibilitäts- prüfung durchgeführt wird. Dies erleichtert eine automatische Kompatibilitätsprüfung. Als Datenformat kann z.B. XMI (XML Metadata Interchange) verwendet werden, dies ermöglicht eine Prüfung durch handelsübliche XML-Parser. XMI ist ein weitverbreitetes Austauschformat für UML- oder SysML-Modelle .
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass das Verfahren zur Modellierung von Varianten von technischen Komponenten und/oder Produkten und/oder Systemen und/oder Anlagen verwendet wird. Dies ermöglicht eine forma- lisierbare Variantenbildung und -darstellung.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass das Verfahren zur Modellierung von technischen
Komponenten und/oder Produkten und/oder Systemen und/oder Anlagen verwendet wird. Dies ermöglicht eine formalisierbare Überprüfung der Modellierung und Darstellung von Ausprägungen oder Variationen von technischen Komponenten und/oder Produk- ten und/oder Systemen und/oder Anlagen.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass beim automatischen Prüfen die zu prüfenden Datensätze als Datei oder Datenstrom über eine Netzwerkverbindung der Prüfeinheit als standardisiertes Datenaustauschformat, insbesondere XML, bereitgestellt werden und mit einem Standard-Parser die Prüfung durchgeführt wird. Die Prüfung ist somit nicht auf spezielle oder proprietäre Datenformate beschränkt und kann mit handelsüblichen Werkzeugen (z.B. Stan- dard-Parser für XML) durchgeführt werden.
Die Aufgabe wird weiterhin gelöst mit einem ein Engineeringsystem oder eine Softwareentwicklungsumgebung, zur Durchführung des Verfahrens. Es können Standardwerkzeuge von der Stange (Commercials off the shelf) verwendet werden, wie z.B. CAx-Tools, PLM-Tools (PLM steht für Product Lifecycle Management) , Engineeringtools, oder angepasste (customized) Tools eingesetzt werden. Die Methodenintegration in ein vorhandenes Engineeringsystem stellt sicher, dass kein Methoden- und Me- dienbruch erfolgt. Dies erhöht die Qualität und die Effizienz der Modellierung bzw. der Modellierungsergebnisse.
Ein Ausführungsbeispiel der Erfindung ist in der Zeichnung dargestellt und wird im Folgenden erläutert. SysML-Blocks und Pakete repräsentieren darin technische Systeme und deren Ei- genschaften.
Dabei zeigen: FIG 1 ein optionales Merkmal eines SysML-Blocks, FIG 2 ein erforderliches Merkmal eines SysML-Blocks, FIG 3 ein alternatives Merkmal eines SysML-Blocks,
FIG 4 ein ausgewähltes Merkmal eines SysML-Blocks (Variante mit „or") , FIG 5 ein ausgewähltes Merkmal eines SysML-Blocks (Variante mit „choice") ,
FIG 6 ein optionales Merkmal eines SysML-Pakets, FIG 7 ein erforderliches Merkmal eines SysML-Pakets, FIG 8 ein alternatives Merkmal eines SysML-Pakets,
FIG 9 ein ausgewähltes Merkmal eines SysML-Pakets (Vari- ante mit „or" ) ,
FIG 10 ein ausgewähltes Merkmal eines SysML-Pakets (Variante mit „choice" ) , FIG 11 ein beispielhaftes Ablaufdiagramm zur Durchführung des Verfahrens, und
FIG 12 ein beispielhaftes System zur Realisierung des Verfahrens .
Das Sprachelement Stereotyp (stereotype) ist eine Erweiterung vorhandener Modellelemente einer Beschreibungssprache, die Stereotypen unterstützt, wie z.B. Unified Modeling Language (UML) oder Systems Modeling Language (SysML) . In der Praxis geben Stereotype vor allem die möglichen Verwendungszusammenhänge (Verwendungskontext) einer Klasse, einer Beziehung oder eines Paketes an. Ein Stereotyp spezifiziert, wie eine bereits durch das Metamodell der UML vorgegebene Metaklasse für ein spezifisches Einsatzgebiet angepasst werden kann. Stereotypen sind für spezifische Domänen, Branchen oder Produkte erstellbar bzw. anpassbar, d.h. formalisierbar . Durch Stereotype können weiterhin Regeln für die Zusammensetzung von Kom- ponenten dieser Domänen, Branchen oder Produkte definiert und formalisiert werden. UML- oder SysML-Modelle können auf Datenformate (z.B. XML oder XMI) abgebildet werden, was eine automatische Prüfung auf Inkompatibilitäten in diesen Datenformaten ermöglicht. Durch einen Benutzer können durch Ste- reotypen die Mächtigkeit einer Beschreibungssprache spezifisch flexibel erweitert bzw. angepasst werden.
Erfindungsgemäß wird eine Darstellung von Systemvarianten auf Basis der SysML- oder UML-Beschreibungssprache vorgeschlagen. Dies wird durch eine Anreicherung von SysML bzw. UML durch zusätzlich definierte Stereotypen erreicht. Die Mächtigkeit dieser Beschreibungssprachen ermöglicht die Definition zusätzlicher Stereotypen, um den für einen Benutzer verwendbaren Sprachumfang, zu erweitern. Prinzipiell kann das Verfah- ren auf jede Beschreibungssprache angewendet werden, die Stereotypen oder ähnliche Konstrukte bietet. Durch Stereotypen lassen sich Regeln zur Anordnung und Kombination (z.B. Aggregation) von Sprachelementen definieren, die eine syntaktische und semantische Überprüfung eines mit der Beschreibungsspra- che erstellten Modells ermöglichen. Ein Benutzer wird dabei automatisch (online oder im Batchbetrieb) auf Inkompatibilitäten des Modells hingewiesen. Batchbetrieb eignet sich besonders bei der Modellierung großer Systeme, die aus vielen Teilsystemen bestehen und bei denen viele Modellierer (z.B. Systemarchitekten) beteiligt sind. Nach einem Mergen (Zusammenführen) der Teilmodelle kann im Batchbetrieb eine Überprüfung auf Inkompatibilitäten erfolgen.
In den FIG 1 bis 10 werden jeweils Darstellungsarten für die Variantenbildung auf Basis von Blöcken und Paketen vorgeschlagen. Blöcke und Pakete sind feste Bestandteile des
SysML- bzw. des UML-Sprachumfangs und als solche einem
Systemmodellierer (z.B. Systemarchitekt) wohlbekannt. Prinzi- piell ist das erfindungsgemäße Modellierungsverfahren mit allen Beschreibungssprachen durchführbar, die das Sprachkon- strukt Stereotyp o.a. zulassen. Die FIG 1 bis 5 zeigen eine Variantendarstellung auf der Basis der Sprachkonstrukte Blö- cke . Die FIG 6 bis 10 zeigen eine Variantendarstellung auf der Basis der Sprachkonstrukte Pakete.
FIG 1 zeigt ein „optionales Merkmal" eines SysML- bzw. UML- Blocks. Ein optionales Merkmal einer Entität wird durch je einen SysML-Block für die Entität EEl und deren Merkmal EE2 dargestellt. Die Beziehung zwischen Entität und Merkmal wird durch ein neues SysML-Stereotyp ZEl dargestellt, das auf dem Symbol Aggregation basiert und durch den Textzusatz „optional" ergänzt wird.
FIG 2 zeigt ein „erforderliches Merkmal" eines SysML- bzw. UML-Blocks. Ein erforderliches Merkmal einer Entität wird durch je einen SysML-Block für die Entität EE3 und deren Merkmal EE4 dargestellt. Die Beziehung zwischen Entität und Merkmal wird durch ein neues SysML-Stereotyp ZE2 dargestellt, das auf dem Symbol für eine Komposition basiert und durch den Textzusatz „mandatory" ergänzt wird.
FIG 3 zeigt ein „alternatives Merkmal" eines SysML- bzw. UML- Blocks. Ein alternatives Merkmal einer Entität (genau ein
Merkmal aus einer Menge möglicher Merkmale) wird durch einen SysML-Block für die Entität EE5 und je einen Block EE6,EE7 für zwei oder mehrere mögliche Varianten, von denen genau eine ausgewählt werden kann, dargestellt. Die Beziehung zwi- sehen Entität EE5 und Merkmal EE6,EE7 wird durch ein neues
SysML-Stereotyp ZE3 dargestellt, das auf dem Symbol für eine Generalisierung (Vererbung) basiert und durch den Textzusatz „alternative" ergänzt wird. FIG 4 zeigt ein „ausgewähltes Merkmal" eines SysML- bzw. UML- Blocks (Variante mit „or") . Ein ausgewähltes Merkmal einer Entität (ein Merkmal oder mehrere Merkmale aus einer Menge möglicher Merkmale) wird durch einen SysML-Block EE8 für die Entität und je einen Block EE9,EE10 für zwei oder mehrere mögliche Varianten, von denen eine oder mehrere ausgewählt werden kann, dargestellt. Die Beziehung zwischen Entität und Merkmal wird durch ein neues SysML-Stereotyp ZE4 dargestellt, das auf dem Symbol für eine Aggregation basiert und durch den Textzusatz „or" ergänzt ist.
FIG 5 zeigt ein „ausgewähltes Merkmal" eines SysML- bzw. UML- Blocks (Variante mit „choice") . Ein ausgewähltes Merkmal ei- ner Entität (ein Merkmal oder mehrere Merkmale aus einer Menge möglicher Merkmale) wird durch einen SysML-Block EEIl für die Entität und je einen Block EE12,EE13 für zwei oder mehrere mögliche Varianten, von denen eine oder mehrere ausgewählt werden kann, dargestellt. Die Beziehung zwischen Entität und Merkmal wird durch ein neues SysML-Stereotyp ZE5 dargestellt, das auf dem Symbol für eine Aggregation basiert und durch den Textzusatz „choice" ergänzt ist.
FIG 6 bis 10 zeigen Beispiele zur Variantendarstellung auf Basis von Paketen.
FIG 6 zeigt ein „optionales Merkmal" eines SysML-Pakets bzw. UML-Pakets. Ein optionales Merkmal einer Entität wird durch je ein SysML-Paket bzw. UML-Paket für die Entität und deren Merkmal dargestellt. Die Beziehung zwischen Entität EE14 und Merkmal EE15 wird durch ein neues SysML-Stereotyp ZE6 dargestellt, das auf dem Symbol für einen Element Import oder Pa- ckage Import basiert und durch den Textzusatz „optional" er- gänzt wird.
FIG 7 zeigt ein „erforderliches Merkmal" eines SysML-Pakets bzw. UML-Pakets. Ein erforderliches Merkmal einer Entität wird durch je ein SysML- bzw. UML-Paket für die Entität EE16 und deren Merkmal EE17 dargestellt. Die Beziehung zwischen Entität EE16 und Merkmal EE17 wird durch ein neues SysML- Stereotyp ZE7 dargestellt, das auf dem Symbol für einen EIe- ment Import oder Package Import basiert und durch den Textzusatz „mandatory" ergänzt wird.
FIG 8 zeigt ein „alternatives Merkmal" eines SysML-Pakets bzw. UML-Pakets. Ein alternatives Merkmal einer Entität (genau ein Merkmal aus einer Menge möglicher Merkmale) wird durch einen SysML-Block EE18 für die Entität und ein Hilfspa- ket EE19, das die Menge der möglichen Merkmale repräsentiert, dargestellt. Innerhalb des Hilfspaketes EE19 sind deren ein- zelne Merkmalsvarianten, aus denen genau eine ausgewählt werden kann, als weitere Pakete dargestellt. Die Beziehung zwischen Entität EE18 und Merkmal wird durch ein neues SysML- Stereotyp ZE8 dargestellt, das auf dem Symbol für einen Element Import oder Package Import basiert, und durch den Text- zusatz „xor" oder „alternative" ergänzt wird. Es befindet sich zwischen der Entität EE18 und dem Hilfspaket EE19.
FIG 9 zeigt ein „ausgewähltes Merkmal" eines SysML- bzw. UML- Pakets (Variante mit „or") . Ein ausgewähltes Merkmal einer Entität (ein Merkmal oder mehrere Merkmale aus einer Menge möglicher Merkmale) wird durch einen SysML-Block für die Entität EE20 und ein Hilfspaket EE21, das die Menge der möglichen Merkmale repräsentiert, dargestellt. Innerhalb des
Hilfspaketes EE21 sind deren einzelne Merkmalsvarianten, aus denen eine oder mehrere ausgewählt werden können, als weitere Pakete dargestellt. Die Beziehung zwischen Entität EE20 und Merkmal wird durch ein neues SysML-Stereotyp ZE9 dargestellt, das auf dem Symbol für einen Element Import oder Package Import basiert und durch den Textzusatz „or" oder „choice" er- gänzt wird. Es befindet sich zwischen der Entität EE20 und dem Hilfspaket EE21.
FIG 10 zeigt ein „ausgewähltes Merkmal" eines SysML-bzw. UML- Pakets (Variante mit „choice" ) . Ein ausgewähltes Merkmal ei- ner Entität (ein Merkmal oder mehrere Merkmale aus einer Menge möglicher Merkmale) wird durch einen SysML-Block für die Entität EE22 und ein Hilfspaket EE23, das die Menge der möglichen Merkmale repräsentiert, dargestellt. Innerhalb des Hilfspaketes EE23 sind deren einzelne Merkmalsvarianten, aus denen eine oder mehrere ausgewählt werden können, als weitere Pakete dargestellt. Die Beziehung zwischen Entität EE22 und Merkmal wird durch ein neues SysML-Stereotyp ZElO darge- stellt, das auf dem Symbol für einen Element Import oder Pa- ckage Import basiert und durch den Textzusatz „or" oder „choice" ergänzt wird. Es befindet sich zwischen der Entität EE22 und dem Hilfspaket EE23. Vorteilhafterweise wird vorgeschlagen, neben den Stereotyp-
Erweiterungen in englischer Sprache auch Übersetzungen in der jeweiligen Landessprache des Anwenders zu verwenden.
Neben den Beziehungsmerkmalen „optional", „mandatory", „al- ternative" oder „choice" können auch weitere Querbeziehungen wie „Required", „Recommended", „Forbids", „Discourages" oder „Influences" durch zusätzliche SysML-Stereotypen mit entsprechenden Texten in Verbindung mit „Usage"-Beziehungen beschrieben werden können. Die Spracherweiterungen sind beson- ders vorteilhaft, weil sie nicht nur auf Softwaresysteme anwendbar sondern auch einfach und allgemeinverständlich sind und auf anerkannte und verbreitete Beschreibungssprachen wie SysML oder UML aufbauen. Durch die Verwendung des Begriffs „Alternativ" im weiteren Sinne ist eine Exklusiv-Auswahl auch aus Grundmengen mit mehr als zwei Merkmalen möglich. Weiterhin ermöglicht die vorgeschlagene Spracherweiterung eine toolunterstützte Prüfung von Auswahlentscheidungen für Systemmerkmale, die während der Systemspezifikation getroffen werden. Ein weiterer Vorteil ist die Fähigkeit der visuellen Beschreibungssprachen eine vollständige Systemausprägung gleichzeitig mit Auswahloptionen verschiedener Merkmale darzustellen .
FIG 11 zeigt ein beispielhaftes Ablaufdiagramm zur Durchfüh- rung des Verfahrens zur Modellierung von technischen Systemen innerhalb eines Engineering- oder Designprozesses. Im Schritt Modellieren M erfolgt die (üblicherweise grafische oder tabellarische) Beschreibung eines technischen Systems (Produk- tionsanlage, Maschine, Roboter, etc.), eines Produktes (Cam- Corder, Fahrzeug, etc.), oder einer zu lösenden technischen Problemstellung (z.B. effiziente Energieübertragung von einem Erzeuger zu einem Verbraucher) . Die Modellierung erfolgt in einer geeigneten Beschreibungssprache (z.B. UML, SysML) durch einen Benutzer (z.B. Vertriebs- oder Automatisierungsingenieur) durch Eingabe- und Ausgabemittel an einem Computer (z.B. Laptop, PC) . Durch das Sprachelement Stereotyp lassen sich in der Beschreibungssprache Regeln zum Zusammensetzten und zur Kombination von Objekten definieren. Die Beschreibungssprache lässt sich somit von einem Benutzer branchen-, domänen- oder produktspezifisch erweitern. Somit ist eine branchen-, domänen- oder produktspezifische Variantenbildung formalisiert darstellbar. Die formalisierte Darstellung ist Voraussetzung für eine automatische Prüfung P eines erstellten Modells auf Inkompatibilitäten .
Die Überprüfung P kann online oder im Batchbetrieb erfolgen. Die Schritte Konvertieren K und Anzeigen A sind optional. Durch das Konvertieren in ein Datenaustauschformat (z.B. XML oder XMI) ist zum einen die Ankopplung/Integration an weitere Werkzeuge (z.B. Simulationsprogramme) möglich, zum anderen existieren für standardisierte Datenaustauschformate (z.B. XML) Standard-Parser für die Überprüfung auf Inkompatibilitä- ten. Ein grafisches Anzeigen A von Inkompatibilitäten im Modell ermöglicht es einem Benutzer sofort und gezielt Falscheingaben zu verbessern.
FIG 12 zeigt ein beispielhaftes System 10 zur Realisierung des Verfahrens. Das Verfahren kann z.B. durch ein Software- Werkzeug eines Engineeringsystems, eines CAx-Tools (CAD, CAM usw.) oder eines PLM-Tools (Product Lifecycle Management) integriert sein, das eine in SysML (oder in UML oder einer ähnlichen Beschreibungssprache) beschriebene individuelle Sys- temausprägung mit dem wie oben beschriebenen Auswahl- Regelwerk vergleicht und dem Nutzer mitteilt, ob die gewählte Ausprägung mit dem Regelwerk kompatibel ist. Im Falle einer Inkompatibilität gibt es dem Nutzer spezifische Hinweise oder Warnungen auf einer Ausgabeeinheit 3 (z.B. Bildschirm), welche verwendeten Kombinationen welche Regeln verletzen. Für die Implementierung eines solchen Werkzeugs bieten sich zwei grundsätzliche Architekturen an:
Zum einen die Integration in eine existierende Modellierungs- Applikation: Hier ist die Funktion des Werkzeugs in den
Workflow und die graphische Oberfläche 4 der Applikation integriert .
Zum anderen eine Stand-Alone-Applikation : Hier besteht das Werkzeug als eine eigenständige Applikation, die unabhängig von anderen Programmen gestartet werden kann. Sie liest die zu prüfenden Datensätze vorzugsweise als Datei oder Daten- ström über eine Netzwerkverbindung ein. Als Datenformat kommt hierfür z.B. das XMI-Format (XML Metadata Interchange) in Frage .
Bei beiden Architekturen kann ein Benutzer über einen Compu- ter 1 mit Hilfe von Eingabemitteln 2 (Maus, Keyboard, etc.) auf der grafischen Arbeitsfläche 4 einer Ausgabeeinheit 3 die Modellierung in der Beschreibungssprache durchführen. Zur Archivierung steht üblicherweise eine Datenbank 5 zur Verfügung, die mit dem Computer 1 (Laptop, Industrie-PC, Worksta- tion, etc.) über eine geeignete Datenverbindung 6 (Kabel oder wireless) verbunden ist. Es ist auch denkbar das Verfahren als Web Application Service über Intranet oder Internet zu betreiben .
Verfahren und Engineeringsystem zur automatischen Prüfung der Modellierung von technischen Systemen innerhalb eines Engineering- oder Designprozesses, bei dem die verwendete Beschreibungssprache (z.B. UML oder SysML) durch geeignet defi- nierte Stereotype erweitert wird, insbesondere geeignet zur automatischen Erkennung von Inkompatibilitäten bei der Variantenbildung technischer Systeme oder Produkte. Bezugszeichen
EEl - EE23 Erstes Element der Beschreibungssprache
ZEl - ZElO Zweites Element der Beschreibungssprache
M Verfahrensschritt
K Verfahrensschritt
P Verfahrensschritt
A Verfahrensschritt
10 System
1 Computer
2 Eingabemittel
3 Ausgabeeinheit
4 Arbeitsfläche
5 Datenbank
6 Verbindung

Claims

Patentansprüche
1. Verfahren zur automatischen Prüfung der Modellierung von technischen Systemen, insbesondere von technischen Anlagen, innerhalb eines Engineering- oder Designprozesses, umfassend die folgenden Schritte:
a) Modellierung (M) des Systems in einer, insbesondere grafischen, Systembeschreibungssprache durch Ein- und Ausga¬ bemitteln,
wobei Systemkomponenten durch erste Elemente (EEl -
EE23) der Systembeschreibungssprache repräsentiert werden, wobei Beziehungen zwischen den Systemkomponenten oder zwischen den Systemkomponenten und einer Umgebung durch zweite Elemente (ZEl - ZElO) der Systembeschreibungssprache rep- räsentiert werden,
wobei für die Kombination von Systemkomponenten untereinander und für die Modellierung von Beziehungen zwischen Systemkomponenten festlegbare Regeln vorhanden sind, und
wobei die Regeln Anforderungen einer zu verwendenden Technologie und/oder einer Branche und/oder einer Domäne rep¬ räsentieren;
b) automatisches Prüfen (P) durch eine Prüfeinheit, ob das modellierte System kompatibel zu den festgelegten Regeln ist .
2. Verfahren nach Anspruch 1, weiter umfassend:
c) Anzeigen (A) von Inkompatibilitäten in der Modellierung auf dem Ausgabemittel (3) .
3. Verfahren nach Anspruch 1 oder 2, wobei das Verfahren in eine Modellierungs-Applikation oder eine Modellierungsumgebung integriert ist.
4. Verfahren nach Anspruch 1 oder 2, wobei das Verfahren als Stand-Alone-Applikation realisiert ist.
5. Verfahren nach einem der vorstehenden Ansprüche, wobei die Modellierung (M) in der Beschreibungssprache SysML oder UML erfolgt .
6. Verfahren nach einem der vorstehenden Ansprüche, wobei die ersten (EEl - EE23) und zweiten (ZEl - ZElO) Elemente der Systembeschreibungssprache durch Stereotypen der Beschreibungssprache SysML oder UML gebildet sind.
7. Verfahren nach einem der vorstehenden Ansprüche, wobei die Systemkomponenten, die Beziehungen zwischen den Systemkomponenten und die Regeln auf ein gemeinsames Datenformat abgebildet werden (K) , in welchem die Kompatibilitätsprüfung (P) durchgeführt wird.
8. Verfahren nach einem der vorstehenden Ansprüche, wobei das Verfahren zur Modellierung (M) von Varianten von technischen Komponenten und/oder Produkten und/oder Systemen und/oder Anlagen verwendet wird.
9. Verfahren nach einem der vorstehenden Ansprüche, wobei das Verfahren zur Modellierung (M) von technischen Komponenten und/oder Produkten und/oder Systemen und/oder Anlagen verwendet wird.
10. Verfahren nach einem der vorstehenden Ansprüche, wobei beim automatischen Prüfen (P) die zu prüfenden Datensätze als Datei oder Datenstrom über eine Netzwerkverbindung der Prüfeinheit als standardisiertes Datenaustauschformat, insbeson- dere XML, bereitgestellt werden und mit einem Standard-Parser die Prüfung durchgeführt wird.
11. System (10), insbesondere ein Engineeringsystem oder eine Softwareentwicklungsumgebung, zur Durchführung eines Verfah- rens nach einem der Ansprüche 1 bis 10.
PCT/EP2010/061003 2009-08-26 2010-07-29 Verfahren zur prüfung der modellierung technischer systeme WO2011023487A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/392,752 US20120158386A1 (en) 2009-08-26 2010-07-29 Method for the inspection of the modeling of technical systems

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102009038882.6 2009-08-26
DE102009038882 2009-08-26

Publications (1)

Publication Number Publication Date
WO2011023487A1 true WO2011023487A1 (de) 2011-03-03

Family

ID=43038226

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2010/061003 WO2011023487A1 (de) 2009-08-26 2010-07-29 Verfahren zur prüfung der modellierung technischer systeme

Country Status (2)

Country Link
US (1) US20120158386A1 (de)
WO (1) WO2011023487A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108988315A (zh) * 2018-06-15 2018-12-11 国电南瑞科技股份有限公司 一种基于单元制配电网模型的自动成图方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140012118A1 (en) * 2012-07-09 2014-01-09 Dexcom, Inc. Systems and methods for leveraging smartphone features in continuous glucose monitoring
US9165090B2 (en) * 2012-09-30 2015-10-20 International Business Machines Corporation Concise modeling and architecture optimization
US9858641B2 (en) * 2014-12-15 2018-01-02 International Business Machines Corporation Representing a system using viewpoints
CN107664952B (zh) * 2017-09-12 2019-07-09 哈尔滨工业大学 基于SysML的航天飞行器系统模拟方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070073429A1 (en) 2002-04-26 2007-03-29 Bae Systems Plc Optimisation of the design of a component

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10161065A1 (de) * 2001-12-12 2003-07-03 Siemens Ag System und Verfahren zum Testen und/oder Debuggen von Laufzeitsystemen zur Lösung von MES-Aufgaben
US8015541B1 (en) * 2002-10-24 2011-09-06 Rage Frameworks, Inc. Business process technology for the enterprise
EP1560094A1 (de) * 2004-01-27 2005-08-03 Siemens Aktiengesellschaft Bereitstellung von Diensten innerhalb eines Netzwerks mit gekoppelten Rechnern

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070073429A1 (en) 2002-04-26 2007-03-29 Bae Systems Plc Optimisation of the design of a component

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
KANG, K.; COHEN, S.; HESS, J.A.; NOVAK, W.E.; PETERSON, S.A.: "Feature Oriented Domain Analysis (FODA) Feasability Study", TECHNICAL REPORT, SOFTWARE ENGINEERING INSTITUTE (SEI), 1990
SELONEN P ET AL: "Validating UML models against architectural profiles", SOFTWARE ENGINEERING NOTES ACM USA, vol. 28, no. 5, September 2003 (2003-09-01), pages 58 - 67, XP002609352, ISSN: 0163-5948 *
TEWFIK ZIADI ET AL: "Towards a UML Profile for Software Product Lines", 25 May 2004, SOFTWARE PRODUCT-FAMILY ENGINEERING; [LECTURE NOTES IN COMPUTER SCIENCE;;LNCS], SPRINGER-VERLAG, BERLIN/HEIDELBERG, PAGE(S) 129 - 139, ISBN: 978-3-540-21941-5, XP019004535 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108988315A (zh) * 2018-06-15 2018-12-11 国电南瑞科技股份有限公司 一种基于单元制配电网模型的自动成图方法
CN108988315B (zh) * 2018-06-15 2021-09-14 国电南瑞科技股份有限公司 一种基于单元制配电网模型的自动成图方法

Also Published As

Publication number Publication date
US20120158386A1 (en) 2012-06-21

Similar Documents

Publication Publication Date Title
EP1401171B1 (de) Elektronische Vorrichtung für ein Bussystem
EP1454280B1 (de) System und verfahren zum testen und/oder debuggen von laufzeitsystemen zur lösung von mess-aufgaben
WO2008040664A1 (de) Verfahren zur rechnergestützten bewertung von softwarequellcode
DE102005046996A1 (de) Anwendungs-generischer Sequenzdiagrammerzeuger, getrieben durch eine nicht-proprietäre Sprache
WO2011023487A1 (de) Verfahren zur prüfung der modellierung technischer systeme
DE10147706A1 (de) Verfahren zum Bedienen eines Feldgerätes
EP2718774A1 (de) Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt
US20110153056A1 (en) Functional Mechatronic Objects
EP2290593A1 (de) Verfahren zur Unterstützung einer Planung einer technischen Anlage
DE102021004346A1 (de) Verfahren zum Aufbau und zur Pflege einer Fahrzeugtypbibliothek
Becker et al. Hanfor: Semantic Requirements Review at Scale.
DE102014108126A1 (de) FDT Host als FDI UIP in generischem FDI Package
EP3617912A1 (de) Verfahren und vorrichtung zum rechnergestützten generieren einer komponente für ein technisches system
DE102017130842A1 (de) Konfigurationssystem zur Konfiguration eines zum Testen eines elektronischen Steuergeräts geeigneten Testsystems
DE102010044039A1 (de) Verfahren und Vorrichtung zur Qualitätsanalyse von Systemmodellen
DE102006021543A1 (de) System und Verfahren zur automatisierten Übernahme und Bewertung der Qualität von Massendaten eines technischen Prozesses oder eines technischen Projektes
WO2022100965A1 (de) Trainingsdatengenerator und verfahren zum generieren von trainingsdatensätzen
DE102011012071A1 (de) Anforderungseinbringungs-/-auslesewerkzeug, genannt r2db
EP2267562A1 (de) Verfahren und Gerät zur Überprüfung von zwischen Komponenten auszutauschenden Daten in einem XML-Format
DE102017208143A1 (de) Verfahren zur rechnergestützten Benutzerassistenz bei der Erstellung eines Programms zur Analyse von Daten zumindest eines technischen Systems
EP2230609A2 (de) Verfahren zum Erstellen von Anforderungsspezifikationen für Prozessleitsysteme der Kraftwerksleittechnik
DE102005058802A1 (de) System und Verfahren zur automatischen Prüfung von Planungsergebnissen
DE102016101853A1 (de) Computerimplementiertes Verfahren zur Simulation eines Restbus-Steuergeräteverbundes
Lee et al. Current Activities Related to the Core Manufacturing Simulation Data Standards Development Effort
WO2015078601A1 (de) Vorrichtung, verfahren zur automatischen erzeugung eines fem modells und regler

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10740202

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13392752

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 10740202

Country of ref document: EP

Kind code of ref document: A1