Roman Gumzej

Measuring the Performance of Real-Time Systems

So far, performance measures for real time systems did not receive much attention. An assessment of the few existing benchmarking methods for real time systems will reveal that they are highly inappropriate. Taking a closer look into the fundamental issues of real time systems it will become clear, that for hard real time systems qualitative characteristics are much more important than quantitative measures. The major qualitative performance criteria are compiled. Systems fulfiling the qualitative aspects may then be compared on the basis of costs.

An approach to modeling and verification of real-time systems

An approach to the modeling and verification of real-time systems is presented. The Specification PEARL description language is used for hardware/software modeling. It has its origins in the standard Multiprocessor PEARL language. Its usefulness has been enhanced for asymmetrical multiprocessor system modeling, and parameters for schedulability analysis have been added. It is meant to be an over-layer for PEARL programs and supports the corresponding program model. The detailed program models are represented internally by timed state transition automata. The model of the co-designed system is verified for feasibility with co-simulation. The resulting information may be used for changes in the current design to gain a feasible model of the system. After that, the program models may be enhanced to their full functionality. Schedulability analysis, which should provide the designer with more precise information, can then be done. The new information can be reused on the system model in order to discover bottlenecks or possible discrepancies with the estimated times. By utilising this methodology, the possibility of implementing a non-feasible system should be minimised.

Design of Real-time Systems for QoS

It was discovered early, that in order to achieve the desired QoS properties a design methodology for real-time systems has to include appropriate measures to ensure that the QoS criteria are considered during the entire life-cycle. These have been joined in the framework of the ISO/IEC 13236 [31] and ISO/IEC TR 13243 [32] standards for QoS in information technology, and the standard IEC 61508 [28], which includes the necessary activities for safety-related systems from a project’s start until the end of its life-cycle. Like safety, security is also an issue that is gaining importance for embedded (real-time) applications [76], and which must be dealt with during the design phase, too.

Entwurf und Analyse verteilter Echtzeitsysteme

In den letzten Jahren hat sich die Spezifikationssprache UML [114] als Standard fur den objektorientierten Entwurf informationsverarbeitender Systeme herauskristallisiert. Die Sprache wird intensiv zur Entwicklung komplexer Informationssysteme eingesetzt und von den meisten Werkzeugen zur objektorientierten Modellierung unterstutzt. Zwar beinhaltet UML ein groses Spektrum verschiedener Diagrammtypen und Erweiterungsmechanismen, mit denen Zielsysteme visuell modelliert werden konnen, jedoch fehlen den spezifischen Bedurfnissen verteilter Echtzeitumgebungen angemessene Konstrukte. Deshalb gibt es eine Reihe von Ansatzen wie z.B. UML-RT [115], UML entsprechend zu erweitern. Alle kranken jedoch daran, dass ihnen ein nur unzureichendes Verstandnis der Anforderungen und Merkmale des Echtzeitbetriebs zugrunde liegt.

Leistungsbewertung und Dienstqualität von Echtzeitsystemen

Immer ofter werden wir mit der Notwendigkeit konfrontiert, Entscheidungen hinsichtlich der Vor- und Nachteile beim Einsatz von Datenverarbeitungssystemen zu treffen. Fur diese Aufgabe muss man sich uber geeignete Bewertungskriterien im Klaren sein, die fur jede Anwendung unterschiedlich sind. Wahrend fruher immer die Rechengeschwindigkeit als wichtigstes Kriterium galt, legen die Nutzer schon seit den 1980er Jahren immer mehr Wert auf andere Kriterien, wie z.B.

Qualitätssicherung von Echtzeitsystemen

Die im klassischen Ingenieurwesen benutzten Qualitatsstrategien betreffen hauptsachlich probabilistisch verteilte Fehler von Bestandteilen, die durch Verschleis, Drift oder unbeabsichtigte Ereignisse in der Umgebung verursacht werden. Software kann jedoch nicht verschleisen, noch konnen Gegebenheiten der Umwelt Software-Fehler verursachen. Alle Software-Fehler sind rein systematischer Natur. Sie entstehen auf Grund unzureichender Kenntnis des eigentlichen Problems, was zu unvollstandigen oder unangemessenen Spezifikationen und Entwurfsfehlern fuhrt. Programmierfehler konnen neue Fehlerquellen hinzufugen, die auf der Spezifikationsebene nicht aufgetreten sind. Daruber hinaus stellen Software-Module haufig individuelle Losungen dar, fur die keine Benutzungshistorie existiert, aus der Zusicherungen bezuglich ihrer Verlasslichkeit abgeleitet werden konnten. Daher sind die Genehmigungsinstanzen bei der Lizenzierung sicherheitsbezogener Systeme, deren Verhalten ausschlieslich programmgesteuert ist, noch zuruckhaltend. Von vielen Forschern wird in der Anwendung formaler Methoden eine Losung der Probleme bei der Entwicklung von Software mit hohen Qualitatsanspruchen gesehen.

Profiling Specification Pearl Designs

An approach to holistic system modelling is presented, based on the Specification PEARL hardware/software co-design methodology, having its origin in the standard Multiprocessor PEARL specification language. Specification PEARL specifications and models represent prototypes of systems and programs, based on the PEARL program model. The system models built are checked for timely execution by co-simulation. The resulting information shall be used for fine-tuning the designs. Through the analysis of simulation traces a profiling process takes place. An integral CASE tool facilitating this holistic approach has also been devised. After the profiling process has produced a feasible system model, the program prototypes may be enhanced to their full functionality. As long as their timing properties are not changed by this, utilising this methodology should minimise the possibility of implementing an infeasible system.