Semantische Suche

To enable the concurrent use of products of different vendors, they communicate with standardized protocols. To program a controller, an engineering tool is used to describe the topology of the system such that the programmer of the controller knows how to access data received from and how to send data to different devices. Device configuration files are imported into the engineering tool to provide information about the process data a device sends and expects to receive, about parameters that can be used to alter the behavior of a device, and about what diagnostic data the controller can expect from a device.Those configuration files are dependent on the protocol that is used for communication. One device type can support multiple protocols; therefore, multiple configuration files need to be provided for that device type. Since such configuration files can easily exceed thousands of lines in length, it is not efficient to write them by hand. Therefore, typically a generator is used to generate the configuration files based on some kind of description of the device type. We call the process of describing device types device type configuration and the system that is used for the process device type configuration system (DTCS). We propose a migration process from a database-based DTCS to a multi-level modeling DTCS. First, we analyze an industrial database-based DTCS to derive requirements for a DTCS. Then we present our migration process, which results in an FMMLx multi-level model with six levels. We evaluate the migration process with an expert survey. A model-driven approach enables model checking and consistent device types. Multi-level models enable the reuse of parts of the domain specific language.

The primary objective is to standardize the engineering lifecycle and extend the system’s reusability from the application level to the infrastructure level. The solution is evaluated using the Goal-Question-Metric (GQM) methodology, validating three core pillars: Standardization, Integration, and Reproducibility. The work introduces a Three-Layer Configuration Architecture to decouple infrastructure from experimental variables. As a key contribution, RAMSES Kubernetes Instantiation (RAMSESKube) is developed as the Kubernetes-native instantiation of Pi-RAMSES, utilizing abstract interfaces to bridge the gap between the imperative MAPE-K logic and the declarative orchestrator.

Diese Arbeit adressiert die beschriebene Problematik durch die Einführung eines datengetriebenen Test-Monitorings als Gray-Box-Ansatz mit geringer Abhängigkeit von der kon- kreten Implementierung. Das vorgestellte Konzept besteht aus drei Phasen: Datenerfassung, Datenpersistenz und Datenvisualisierung. In der ersten Phase wird die Regelabdeckung einzelner Modelltransformationen erfasst. In der zweiten Phase werden diese Regelabdeckungen in einer zeitreihentauglichen Datenbank gespeichert. In der dritten Phase werden die gespeicherten Daten mithilfe der Metrik des Regelabdeckungsgrads sowie weiterer Kennzahlen in verschiedenen Dashboards visualisiert. Die grafischen Darstellungen dienen der Orientierung und Analyse des Testzustands eines Regelmodells und liefern Indikatoren zur gezielten Verbesserung der Regelabdeckung.

Das datengetriebene Test-Monitoring ist in der Praxis anhand der modellbasierten Elektrik-/Elektronik-Entwicklungsumgebung PREEvision evaluiert worden. Als Datenbasis haben ein vollständiges Testpaket sowie nahezu sämtliche Testfälle eines Regelmodells gedient. Die in verschiedenen Dashboards dargestellten Visualisierungsergebnisse haben die Grundlage der Evaluation gebildet, sodass die gesamte Systeminfrastruktur ganzheitlich betrachtet werden konnte. Die Ergebnisse sind aus unterschiedlichen Perspektiven analysiert und mit Referenzberechnungen verglichen worden, die auf derselben logischen Grundlage wie die Visualisierungen basiert haben. Das System hat sowohl abgedeckte als auch nicht abgedeckte Regeln zuverlässig identifiziert und daraus korrekt die Metrik des Regelabdeckungsgrads eines Regelmodells abgeleitet. Sämtliche Dashboards haben konsistente und fachlich korrekte Endergebnisse ihrer jeweiligen Visualisierungen geliefert. Dadurch ist die Nachvollziehbarkeit der Testaktivitäten gewährleistet worden und es haben potenzielle Indikatoren zur Verbesserung der Regelabdeckung abgeleitet werden können. Auf diese Weise hat sich die Anzahl nicht abgedeckter Regeln schrittweise reduziert oder der Regelabdeckungsgrad ist gesteigert worden. Das Feedback an die Anwender ist in nahezu allen Dashboards innerhalb relativ kurzer Antwortzeiten erfolgt, lediglich in einem Einzelfall hat die Rückmeldezeit im akzeptablen Bereich gelegen.