Tagungsband des Dagstuhl-Workshops - TU Clausthal...Architekturen insbesondere für langlebige und...

MBEES 2015 MBEES 2015 MBEES 2015 MBEES 2015 MBEES 2015

Tagungsband des Dagstuhl-Workshops

Modellbasierte Entwicklung eingebetteter Systeme XI

Matthias Riebisch Michaela Huhn Jan Philipps

Bernhard Schätz

Tagungsband

Dagstuhl-Workshop MBEES: Modellbasierte Entwicklung

eingebetteter Systeme XI

Model-Based Development of Embedded Systems 22.03.2015 – 25.03.2015

fortiss GmbH Guerickestr. 25 80805 München

Organisationskomitee Prof. Dr.-‐Ing.habil. Matthias Riebisch, Universität Hamburg

Dr. Michaela Huhn, TU Clausthal

Jan Philipps, Validas AG

Dr. Bernhard Schätz, fortiss GmbH

Programmkomitee

Dr. Mirko Conrad, samoconsult GmbH

Prof. Dr. Ulrich Epple, RWTH Aachen

Prof. Dr. Holger Giese, Hasso-‐Plattner-‐Institut an der Universität Potsdam

Dr. Michaela Huhn, TU Clausthal

Dr. Hardi Hungar, DLR

Prof. Dr.-‐Ing. Klaus D. Müller-‐Glaser, Karlsruher Institut für Technologie KIT

Ulrich Nickel, Delta Energy Systems

Prof. Dr. Oliver Niggemann, Fraunhofer IOSB-‐INA


Dr. Ralf Pinger, Siemens AG

Prof. Dr. Bernhard Rumpe, RWTH Aachen

Dr. Bernhard Schätz, fortiss GmbH

Prof. Dr. Albert Zündorf, Universität Kassel

Inhaltsverzeichnis

Beyond Modeling Guidelines - Challenges of the DO-331 Software Model Standards

Markus Hornauer, Mirko Conrad, Florian Holzapfel 1 Kombinierte Entwicklung und Konfiguration von Hardware- und Software-Produktlinien unter Berücksichtigung von deren Abhängigkeiten

Christopher Brink, Martin Hirsch, Sabine Sachweh 7

Duplikatserkennung und Refactoring in Matlab/Simulink-Modellen

Thomas Gerlitz, Stefan Schake, Stefan Kowalewsk 17

Reducing Re-Validation Efforts for Real-time Systems

Stefan Henkler, Achim Rettberg 27

Integration von Virtueller Inbetriebnahme und Variantenmanagement

Johannes H. Möck, Jens Weiland 33

Re-Engineering Automation Systems as Dynamic Software Product Lines

Sascha Lity, Johannes Bürdek, Malte Lochau, Markus Berens, Andy Schürr, and Ina Schaefer 43

A Methodology for Hierarchical Multidisciplinary Modeling and Analysis of Mechatronic Systems

Benjamin Mensing and Ina Schaefer 53

Feature and Constraint Mapping for Configuration and Evolution of Variable Manufacturing Automation Systems

Yibo Wang, Matthias Riebisch 63

Models for Adaptable Automation Software An Overview of Plug-and-Produce in Industrial Automation

Oliver Niggemann, Steffen Henning, Sebastian Schriegel, Jens Otto, Anas Anis 73

Chancen und Herausforderungen bei der virtuellen Absicherung verteilter Body&Comfort-Funktionen auf Basis von AUTOSAR

Dr. Thomas Ringler, Christian Dziobek, Dr. Florian Wohlgemuth 83

Problemstellungen bei der Entwicklung von Ladegeräten für Elektro- und Hybridfahrzeuge

Markus Cordero, Ulrich Nickel 94

Deployment Calculation and Analysis for a Fault-Tolerant System Platform

Klaus Becker, Bernhard Schätz 100

Formalizing Performance Degradation Strategies as an Enabler for Self-healing Smart Energy Systems

Pragya Kirti Gupta, Klaus Becker, Markus Duchon, Bernhard Schätz 110

Innerhalb der Gesellschaft für Informatik e.V. (GI) befasst sich eine große Anzahl von Fachgruppen explizit mit der Modellierung von Software- bzw. Informationssystemen. Der erst neu gegründete Querschnittsfachausschuss Mod-ellierung der GI bietet den Mitgliedern dieser Fachgruppen der GI - wie auch nicht organisierten Wissenschaftlern und Praktikern - ein Forum, um gemeinsam aktuelle und zu-künftige Themen der Modellierungsforschung zu erörtern und den gegenseitigen Erfahrungsaustausch zu stimu-lieren.

Die Arbeitsgruppe Grundlagen der Informatik am Institut für Informatik der TU Clausthal forscht auf dem Gebiet der formalen Methoden für sicherheitskritische, soft-waregesteuerte Systeme. Dies umfasst modellbasierte Entwurfsmethoden sowie formale Validierung und Verifika-tion. Erarbeitet werden Methoden und Werkzeuge zum Nachweis der funktionalen Korrektheit, aber auch zum Echtzeit- und Störungsverhalten komplexer eingebetteter Systeme. In diesem Rahmen wird auch die Qualitätspla-nung und Sicherheitsnachweisführung thematisiert. Die Anwendbarkeit der Lösungen wird immer wieder in indus-trienahen Projekten überprüft, wobei bisher auf Koopera-tionen mit der Automobilindustrie und ihren Zulieferern, der Bahnindustrie und aus der Robotik verwiesen werden kann.

Schloss Dagstuhl wurde 1760 von dem damals re-gierenden Fürsten Graf Anton von Öttingen-Soetern-Hohenbaldern erbaut. 1989 erwarb das Saarland das Schloss zur Errichtung des Internationalen Begegnungs- und Forschungszentrums für Informatik. Das erste Semi-nar fand im August 1990 statt. Jährlich kommen ca. 2600 Wissenschaftler aus aller Welt zu 40-45 Seminaren und viele sonstigen Veranstaltungen.

Die fortiss GmbH ist ein Innovationszentrum für software-intensive Systeme in Form eines An-Instituts der Tech-nischen Universität München. Als Forschungs- und Trans-ferinstitut liegt der Fokus auf der angewandten Forschung zukünftiger Software- und Systemlösungen mit Schwerpunkt eingebettete und verteilte Systeme sowie In-formationssysteme. Bearbeitete Themenfelder sind dabei unter anderem Modellierungstheorien einschließlich funk-tionaler, zeitlicher und nicht-funktionaler Aspekte, Werkzeugunterstützung zur Erstellung von dömanen-spezifischen, modellbasierten Entwicklungswerkzeugen, Architekturen insbesondere für langlebige und sicher-heitskritische Systeme, sowie modellbasierte Anforder-unganalyse und Qualitätsicherung. Lösungen werden dabei vorwiegend in den Anwendungsfeldern Automobilin-dustrie, Luft- und Raumfahrt, Automatisierungstechnik, Medizintechnik, Kommunikationstechnik, öffentliche Ver-waltung und Gesundheitswirtschaft erarbeitet.

Der Arbeitsbereich Softwareentwicklungs- und -konstruktionsmethoden SWK im Fachbereich Informatik der Universität Hamburg forscht auf dem Gebiet der Evolu-tion von Softwaresystemen. Dazu gehören Arbeiten zu modellbasierter Softwareentwicklung, Softwarearchi-tekturen, Software-Reengineering sowie deren Einbettung in Entwicklungsprozesse. Das Ziel der Arbeiten sind inge-nieurgemäße Vorgehensweisen und Methoden und deren Anwendbarkeit in der industriellen Praxis.

Die Validas AG ist ein Beratungsunternehmen im Bereich Software-Engineering für eingebettete Systeme. Die Vali-das AG bietet Unterstützung in allen Entwicklungsphasen, vom Requirements- Engineering bis zum Abnahmetest. Die Auswahl und Einführung qualitätssteigender Maßnah-men folgt dabei den Leitlinien modellbasierter Entwick- lung, durchgängiger Automatisierung und wissenschaft-licher Grundlagen.

Dagstuhl-Workshop MBEES:

Modellbasierte Entwicklung eingebetteter Systeme XI

(Model-Based Development of Embedded Systems)

Wie in den Jahren zuvor bestätigen auch dieses Jahr die Beiträge Grundthesen der MBEES-‐Workshop-‐Reihe, dass sich Modelle an der Problem-‐ anstatt der Lö-‐sungsdomäne orientieren müssen und die Durchgängigkeit eines modellbasier-‐ten Vorgehens über mehrere Phasen des Entwicklungsprozesses ein wesentli-‐cher Erfolgsfaktor ist. Stand in früheren Jahren die Generierung von ablauffähi-‐ger, einbettbarer Software aus ausführbaren Modellen – das sogenannte „Au-‐tocoding“– im Zentrum der industriellen Anwendung, so setzen sich zunehmend facettenreichere Anwendungen von Modellen in der Praxis durch. Nicht zuletzt die Entwicklung oder Anpassung von Normen und Standards, die den Einsatz von modellbasierter Entwicklung explizit berücksichtigen wie z.B. in der ISO 26262, trägt zu anderen Anwendungsformen von Modellen bei: Produktlinien-‐ oder Architekturmodelle zur Dokumentation von Entwurfswissen, oder Platt-‐formmodelle zur Realisierung verteilter Anwendungen sind dabei nur einige Beispiele. Damit wächst aber auch die Bedeutung der Qualität von Modellen, wie Beiträge zu Modellinspektionen oder –Walk-‐Throughs, Modellierungsrichtli-‐nien, Modell-‐Refactoring oder der Einsatz von domänenspezifischen Sprachen zeigen.

Verstärkt hat sich im Vergleich zum ersten Workshop 2005 die Beschäftigung mit modellbasierten Methoden in praktisch allen Bereiche des Produktlebens-‐zyklus: Vor-‐ und nachgelagerte Entwicklungstätigkeiten, wie der Architek-‐turentwicklung und -‐optimierung oder der Systemintegration, sowie auch As-‐pekte jenseits des funktionellen Entwurfs eingebetteter Systeme wie etwa die Erweiterung von Modellen um sicherheitsrelevante Aspekte wie Zuverlässigkeit, die Ableitung von Diagnosemodellen und Sicherheitsnachweise werden zuneh-‐mend modellbasiert angegangen.

In bewährter Tradition stellen die in diesem Tagungsband zusammengefassten Papiere sowohl gesicherte Ergebnisse, als auch Work-‐In-‐Progress, industrielle Erfahrungen und innovative Ideen aus diesem Bereich zusammen und erreichen damit eine interessante Mischung theoretischer Grundlagen und praxisbezoge-‐ner Anwendung. Genau wie bei den ersten zehn, in den Jahren 2005 bis 2014 erfolgreich durchgeführten Workshops sind damit wesentliche Ziele dieses Workshops erreicht:

§ Austausch über Probleme und existierende Ansätze zwischen den unter-‐schiedlichen Disziplinen (insbesondere Elektro-‐ und Informationstechnik, Ma-‐schinenwesen/Mechatronik und Informatik)

§ Austausch über relevante Probleme in der Anwendung/Industrie und existie-‐rende Ansätze in der Forschung

§ Verbindung zu nationalen und internationalen Aktivitäten (z.B. Initiative des IEEE zum Thema Model-‐Based Systems Engineering, GI-‐AK Modellbasierte

Entwicklung eingebetteter Systeme, GI-‐FG Echtzeitprogrammierung, MDA Ini-‐tiative der OMG)

Die Themengebiete, für die dieser Workshop gedacht ist, sind fachlich sehr gut abgedeckt. Die Beiträge adressieren verschiedenste Aspekte modellbasierter Entwicklung eingebetteter Softwaresysteme, unter anderem:

-‐ Domänenspezifische Ansätze zur Modellierung von Systemen

-‐ Modelle in der architekturzentrierten Entwicklung und bei der Produktlinien-‐entwicklung

-‐ Bewertung und Verbesserung der Qualität von Modellen

-‐ Modellbasierte Validierung, Verifikation und Diagnose

-‐ Funktionale Sicherheit und modellbasierte Entwicklung

-‐ Evolution von Modellen

-‐ Modelle und Simulation

-‐ Tracing in der Modellbasierten Entwicklung

Das Organisationskomitee ist der Meinung, dass mit den Teilnehmern aus In-‐dustrie, Werkzeugherstellern und der Wissenschaft die bereits seit 2005 erfolgte Community-‐Bildung erfolgreich fortgeführt wurde. Der nunmehr elfte MBEES Workshop belegt, dass eine solide Basis zur Weiterentwicklung des Themas mo-‐dellbasierter Entwicklung eingebetteter Systeme existiert. Der hohe Anteil von deutschen Forschern und Entwicklern an den in den in den letzten Jahren einge-‐richteten internationalen Konferenzreihen zu Modellierung und Cyper-‐Physical Systems zeigt, dass die deutsche Zusammenarbeit in diesem Themenfeld Früchte getragen hat.

Die Durchführung eines erfolgreichen Workshops ist ohne vielfache Unterstützung nicht möglich. Wir danken daher den Mitarbeitern von Schloss Dagstuhl.

Schloss Dagstuhl im März 2015,

Das Organisationskomitee:

Michaela Huhn, TU Clausthal


Matthias Riebisch, Uni Hamurg

Bernhard Schätz, fortiss GmbH

Mit Unterstützung von

Sergej Zverlov, fortiss GmbH

Beyond Modeling Guidelines -

Challenges of the DO-331 Software Model Standards

Markus Hornauer*, Mirko Conrad

*, Florian Holzapfel

**

* samoconsult GmbH, Berlin, Germany

{mirko.conrad | markus.hornauer}@samoconsult.de

** Institute of Flight System Dynamics,

Technische Universität München, Germany

[email protected]

Abstract: During the past decades software design standards have become integral parts of

the development of safety-critical airborne software according to DO-178B. With the release

of DO-178C and DO-331, the model-based development and verification supplement to DO-

178C, this concept was re-applied to model-based development. As a new requirement, DO-

331 calls for the creation of additional software model standards which require the applicant

to precisely define the intended usage of model-based techniques for design models. In

particular, DO-331 calls for the documentation of the syntax and semantics of the modeling

language(s) utilized, the creation of style guidelines, complexity restrictions, and constraints

for the use of modeling language(s) and tool(s). These aspects need to be considered to

safeguard the utilization of modeling techniques and to ensure compliance with the proposed

verification process.

Nowadays, modeling guideline collections and corresponding modeling guideline checkers

for modeling tools such as Simulink® and TargetLink

® are commonly used to meet the

objectives pertaining to software design standards. However, their current scope may fall

short of addressing the various aspects of the newer DO-331 software model standards.

This paper will outline the requirements for software design and software model standards in

DO-178C / DO-331. Based on this, the authors discuss what needs to be done in addition to

current practice to facilitate compliance with the software model standards according to DO-

331.

1 Software Design and Model Standards in DO-178C / DO-331

Released in 1992, DO-178B “Software Considerations in Airborne Systems and Equipment

Certification” [DO-178B] was the industry-accepted guidance for satisfying airworthiness

requirements of software used on aircraft and engines. When it emerged, DO-178B captured

the common understanding of the state of the art in aerospace software engineering. Later,

when model-based development and automatic code generation became popular, these new

concepts had to be fit into the existing DO-178B framework. This issue was resolved with

the update of DO-178B in late 2011, resulting in DO-178C [DO-178C] and DO-331 [DO-

331]. DO-178C applies slight updates and clarifications to the objectives of DO-178B. In

addition, DO-331, a new “Model-Based Development and Verification Supplement to DO-

178C and DO-278A” [DO-331], was introduced. When using model-based development and

verification, the applicant would now need to satisfy the applicable requirements and

objectives of both, DO-178C and DO-331.

1

In addition to the actual software development processes, the DO-178C software life cycle

also addresses the software planning process (cf. DO-178C, Tab. A-1). One of the

objectives of the planning process is the definition of software development standards

consistent with the safety objectives for the airborne software. These software development

standards would typically include software design standards. As per DO-331, additional

standards, termed software model standards, might be needed (cf. DO-331, Tab. MB.A-1).

1.1 Software Design Standards

The purpose of software design standards is to define the methods, rules, and tools to be

used to develop the software architecture and the software low-level requirements (LLR).

DO-178C and DO-331 inherit the requirements for software design standards (cf. DO-178C,

11.7; DO-330, MB.11.7) from DO-178B. Software design standards should include:

a) Design description method(s) to be used;

b) Naming conventions to be used;

c) Conditions imposed on permitted design methods (e.g., scheduling, use of interrupts and

event-driven architectures, dynamic tasking, re-entry, global data, and exception

handling, and rationale for their use);

d) Constraints on the use of the design tools;

e) Constraints on design (e.g., exclusions of recursion, dynamic objects, data aliases, and

compacted expressions);

f) Complexity restrictions (e.g., maximum level of nested calls or conditional structures,

use of unconditional branches, and number of entry/exit points of code components).

1.2 Software Model Standards

Software model standards need to be defined in addition to software design standards if the

LLR and/or the software architecture are expressed by models (cf. DO 331, MB.11.7). In

these standards, the applicant needs to define the modeling techniques for design models1 by

specifying (cf. DO-331, MB.11.23):

a) Methods and tools used for developing the models;

b) Modeling languages to be used, incl. data that unambiguously defines syntax and

semantics of the language w.r.t. the type of software life cycle data the model

represents. This may require limiting the use of some modeling features;

c) Style guidelines and complexity restrictions for the use of the modeling languages and

tools (e.g., naming conventions, diagram layout, allowable elements, maximum number

of nesting levels, maximum number of model elements per diagram, and maximum

number of architectural layers);

d) Constraints on the use of the modeling tool(s) (e.g., scheduling methods, and/or global

data) and use of model element libraries;

e) Method to be used to identify and delimit the requirements contained in the model and

the means to establish traceability between requirements and other life cycle data;

1 DO-331 distinguishes two types of models, specification models and design models, and introduces five model

usage scenarios. Some scenarios only utilize design models, others only specification models, or both types of

models. This paper assumes usage scenario MB Example 1 (cf. DO-331, MB.1.6.3) where at least one design model represents the LLR and/or the software architecture. In MB Example 1, it is assumed that the design model is

developed to meet textual high-level requirements, i.e., specification models are not being used.

2

f) Method to be used to identify and delimit the derived requirements contained in the

model and the method to provide derived requirements to the system processes,

including the system safety assessment process;

g) Means to identify each model element that does not contribute to the representation of a

software requirement or of the software architecture and is not an input to a subsequent

software development process or activity (e.g., a comment block);

h) Rationale for the suitability of the technique for the type of information expressed by a

design model.

1.3 Standards Definition and Standards Compliance

Tool vendors and third-party organizations established multiple modeling guideline

collections to aid the definition of those aspects of software development standards

pertaining to the use Simulink®

[SL] and TargetLink®

[TL] models. For avionics software,

such guideline collections include the Orion GN&C MATLAB / Simulink Standards

[NASA], the Modeling Guidelines for High-Integrity Systems [MGHI], and the Modeling

Guidelines for MATLAB / Simulink / Stateflow and TargetLink [MGTL]. These guideline

collections could be used as-is or tailored / extended by the applicants.

As per DO-178C / DO-331, the applicant would need to conduct reviews and analyses to

reveal errors that may have been introduced during the development of the software

architecture and during the software design process (cf. DO-331, Tab. MB.A-4 and

MB.A.7). One of the objectives of these reviews and analyses is to ensure that the software

design standards and software model standards were followed during the software design

process and that deviations to these standards are justified (cf. DO-331, MB.6.3.2, and

MB.6.3.3).

To demonstrate conformance to the established modeling guidelines collections and to

identify guideline deviations, multiple tool vendors also came-up with modeling guideline

checkers. Examples include MES Model Examiner®

[MXAM], and Model Advisor [SLVV].

In addition to report guideline violations, both tools provide auto-repair capabilities that

allow to automatically resolve certain guideline deviations.

However, the scope of today’s guideline collections and guideline checkers may fall short of

addressing the additional aspects of the newer DO-331 software model standards.

2 Challenges of the Software Model Standards

The advent of the software model standards as a new software life cycle data artifact results

in additional information that has to be compiled and documented by the applicant in order

to satisfy the requirements of DO-331. Furthermore, conformance to the model standards

needs to be demonstrated. Meeting these additional requirements requires applicants to

broaden their existing approaches to fulfill the objectives pertaining to software model

standards in multiple aspects including, but not limited to the following:

2.1 Modeling Language Definitions

The software model standards should include language definitions for each modeling

language used (or references to those definitions). DO-331 calls for an unambiguous

3

definition of both the syntax and the semantics of the language(s) (cf. DO-331, MB.11.23 b).

Depending on the modeling language at hand, this may or may not be satisfied with the user

documentation of the corresponding modeling tool. The requirement for an unambiguous

definition of the semantics may require restricting the use of some features of the language.

If language features are limited or prohibited, corresponding modeling guidelines and

guideline checks would need to be added. However, this does not mean that syntax and

semantics of all capabilities provided by the modeling language needs to be formally

defined.

2.2 Modeling Tool Constraints

DO-331 also calls for dedicated information specific to the modeling tools in use, such as

complexity restrictions and constraints for the modeling tools (cf. DO-331, MB.11.23 c, d)

to facilitate correct tool operation. In practice, this affects:

Robustness considerations to restrict models and accompanying scripts such that the

tool can reliably load and open model files, simulate, produce code, and save model

files and derived artifacts (e.g., simulation results or generated reports). Examples are

caps on the total number of elements per model or per hierarchy level, a limit for the

number of levels in a block diagram, or maximum lengths of signal and parameter

names. In case of Simulink, this could also include the limitation of data logging points

for model simulation.

The correctness of simulation results if credit is sought for model simulation. This

focuses on restricting tool features to facilitate correct results of open-loop and closed-

loop simulation. In case of Simulink, this includes the deactivation of automatic

handling of algebraic loops and rate transitions, restrictions on the use of ODE solvers,

and avoidance of implicit fixed-point data type conversions.

The usage of language features in the generated source code that are of special interest

in DO-178C, in particular if they were not explicitly defined at the model level, but

induced by the code generator. As an example, when generating C code from Simulink,

the code generator may use global data to preserve internal states (e.g., for Stateflow

charts, integrators, or filters) between function calls. When using global data to store or

exchange information, the verification of the corresponding data coupling and the

determination of the correctness and consistency of the source code regarding data

corruption is required as per DO-178C. Therefore, it would be advisable to provide

dedicated modeling guidelines for model elements that trigger global data usage and

configuration settings for the coder to control these capabilities and facilitate

downstream analysis and testing.

Whereas constraints that facilitate correct code generation are already part of many guideline

collections, systematic complexity restrictions and constraints for modeling tools are less

common. A starting point to gather this information might be the available information from

the respective tool vendors. As an example, the Simulink documentation lists some size

limits for models (Figure 1). These vendor provided complexity restrictions may need to be

extended, requiring the user to define additional limitations, resulting e.g., from the run-time

environment in which the tool operates. An example is a cap on data logging points

depending on the available memory. If the tools do not ensure adherence to their own size

and complexity restrictions, it might be advisable to add corresponding checking

capabilities.

4

Figure 1: List of size and complexity limits for Simulink models [SL]

2.3 Separation of Concerns and Modeling Methods

In a design model, three different kinds of elements can be distinguished: (1) model

elements that represent software LLR or the software architecture, (2) model elements that

represent derived LLR, and (3) model elements that do not contribute to the representation

of a software requirement or the software architecture and are not an input to subsequent

software development processes or activities. In all three cases, DO-331 calls for

documenting the methods that allow to identify and delimit those elements. Thus, method

descriptions and potentially additional modeling guidelines have to be compiled by the

applicant to satisfy the requirements given in DO-331, subsections MB.11.23 e) to g).

One way to address (1) is to describe how traceability between the high-level requirements

(HLR) and the corresponding elements in the design model can be established and verified.

When using Simulink models to capture the LLR, this could be supported by using the

Requirements Management Interface [SLVV] or one of various third party tools. Preferably,

such a tool would use APIs of the modeling tool and not parse model files. A model

coverage analysis can help to verify the traces to the HLR due to the fact, that executing the

tests defined for a HLR should exercise the model elements that are associated with this

requirement.

A focus of DO-178C is to ensure that there is no unintended, unknown, or undocumented

functionality in airborne software. Therefore, (2) calls for a method to identify model

elements representing requirements which are not directly traceable to higher level

requirements, and/or which specify behavior beyond that defined by the system

requirements or the higher level software requirements. Those derived LLR have to be

clearly identified and need to be fed into the system processes, in particular to the system

safety assessment process. A combination of model coverage analysis and model reviews

can be used to verify that all derived requirements were analyzed and marked correctly. (2)

could be addressed by tagging model elements representing derived requirements in a

particular way, e.g., by tags contained in the names of the corresponding blocks or

subsystems. Then a guideline checker could produce a list of all model elements tagged this

way for further analysis and provision to the system processes.

To syntactically identify model elements that do not contribute to the subsequent software

development process (3), a list of those elements can be included in the software model

standards and guidelines addressing their usage should be defined. In case of Simulink

5

models, such a list could e.g., include doc blocks, model info blocks, or model annotations.

3 Summary and conclusion

DO-178C and its model-based development and verification supplement DO-331 introduce

new requirements, objectives, and artifacts into the development process for software used

on aircrafts and engines. Among these are the software model standards, a new type of

software development standards, which need to be defined when utilizing models in the low-

level design or for software architectural purposes. The creation of software model standards

requires the applicant to gather and document additional information regarding modeling

languages, modeling tools, and modeling methods. Established approaches based on

modeling guidelines and modeling guideline checkers remain a solid foundation to satisfy

the DO-178C / DO-330 objectives pertaining to software model standards, however the

underlying approach needs to be broadened and deepened. Based on their experience, the

authors expect efforts that go beyond the current practice mainly in three areas: (1)

unambiguous definitions of the syntax and semantics of the modeling languages or

provisions to limit the use of language features where this is not feasible, (2) the definition

of constraints and complexity limits for the modeling tools, and (3) documented methods to

distinguish model elements based on their traceability to higher level requirements and on

their contribution to downstream software development activities.

References

[DO-178B] DO-178B Software Considerations in Airborne Systems and Equipment Certification.

RTCA SC-167 / EUROCAE WG-12, Washington, DC, 1992

[DO-178C] DO-178C Software Considerations in Airborne Systems and Equipment Certification.

RTCA SC-205 / EUROCAE WG-71, Washington, DC, 2011

[DO-331] DO-331 Model-Based Development and Verification Supplement to DO-178C and DO-

278A. RTCA SC-205 / EUROCAE WG-71, Washington, DC, 2011

[MGHI] Modeling Guidelines for High-Integrity Systems (R2014b). The MathWorks, Inc., 2014

[MGTL] Modeling Guidelines for MATLAB/Simulink/Stateflow and TargetLink (V 3.0). dSPACE

GmbH, 2010

[SLVV] Simulink® Verification and ValidationTM (product page). The MathWorks, Inc., 2014

www.mathworks.com/products/simverification

[MXAM] MES Model Examiner® (product page). Model Engineering Solutions GmbH, 2014

www.model-engineers.com/en/model-examiner.html

[NASA] FltDyn-CEV-08-148 Orion GN&C MATLAB/Simulink Standards (V 15). GN&C

Structured Improvement Activity/LM21 Project Team, NASA, 2011

[SL] Simulink® (product page). The MathWorks, Inc., 2014

www.mathworks.com/products/simulink

[TL] TargetLink® (product page). dSPACE GmbH, 2014

www.dspace.com/de/gmb/home/products/sw/pcgs/targetli.cfm

6

http://www.mathworks.com/products/simverification

http://www.model-engineers.com/en/model-examiner.html

http://www.mathworks.com/products/simulink

http://www.dspace.com/de/gmb/home/products/sw/pcgs/targetli.cfm

Kombinierte Entwicklung und Konfiguration vonHardware- und Software-Produktlinien unterBerucksichtigung von deren Abhangigkeiten∗

Christopher Brink1,2, Martin Hirsch2, Sabine Sachweh21Softwaretechnik, Heinz Nixdorf Institut, Universitat Paderborn

[email protected] Dortmund

{Martin.Hirsch ‖ Sabine.Sachweh}@fh-dortmund.de

Abstract: Heutzutage werden Software-Produktlinien (SPL) in der Automobilindus-trie eingesetzt, um die Entwicklung von Produkten auf der Basis von bestehendenProduktlinien (PL) zu unterstutzen. Diese Produktlinien bestehen aus tausenden vonVarianten, die sich sowohl auf Hardware als auch auf Software beziehen konnen. Eingutes Beispiel hierfur sind die Electronic Control Units (ECUs), deren Software inder Regel als (Software) Produktlinien implementiert werden. Dabei existieren beider Entwicklung enge Verbindungen zwischen Hardware und Software, beispielswei-se wird die Software in der Regel stark auf Prozessor-Merkmale abgestimmt.Auch wenn einige Ansatze zur Berucksichtigung von Hardwareeigenschaften in SPLexistieren, ist die nachvollziehbare und moglichst flexible gemeinsame Modellierungund Konfiguration von HW/SW-Produktlinien ein weiterhin bestehendes Problem. Umdiesem Problem zu begegnen, schlagen wir einen Modellierungsansatz und Entwick-lungsprozess vor, der die Modellierung von Hardware- und Softwarevarianten in se-paraten Modellen erlaubt, Abhangigkeiten zwischen den dort modellierten Hardware-und Softwarevarianten ermoglicht und diese fur eine gemeinsame Konfiguration nutzt.

1 Einleitung

Die steigende Anzahl von elektronischen Steuergeraten (ECUs) in der Automobilindus-trie lasst die Entwicklung solcher eingebetteter Systeme zunehmend komplexer werden.Im Jahr 2007 bestand ein BMW 7 aus etwa 67 vernetzten Steuergeraten [PBKS07]. Bisheute stieg diese Zahl in modernen Autos auf uber 100 ECUs mit tausenden von Software-Funktionen [VPBK10].

Aus diesem Grund entwickeln Automobilzulieferer diese ECUs normalerweise als Soft-ware-Produktlinien (SPL) [CN01]. Diese ermoglichen es, verschiedene Markte oder Fahr-zeugreihen abzudecken. Die gemeinsamen und variablen Teile einer SPL konnen in derForm eines Feature-Modelles [KCH+90] beschrieben werden. Ein solches Modell bestehtaus hierarchisch angeordneten Merkmalen (engl. Feature), die uber verschiedene Arten

∗Die Arbeiten werden in Teilen vom BMBF im ITEA 3 Projekt AMALTHEA4public (Nr. 01IS11020J)gefordert.

7

von Assoziationen verbunden sind (vgl. Abb. 1). Feature-Modelle werden sowohl wahrendder Entwicklung als auch der spatere Produktkonfiguration [CHE05, BPS12] verwendet.

Dabei beschreibt jedes Feature eine Eigenschaft oder Funktion des Systems, unterscheidetjedoch nicht, ob diese durch Software, Hardware oder eine Kombination aus beidem rea-lisiert wird. Dies ist besonders in eingebetteten Systemen dann problematisch, wenn wiebei automobilen Systemen sehr lange oder unterschiedliche Lebenszyklen existieren, beidenen es zum Austausch von Hardware- oder Softwarekomponenten kommt. Hierbei sindnicht triviale HW/SW-Abhangigkeiten zu berucksichtigen, die in einem einzelnen Mo-dell ggf. nicht berucksichtigt werden bzw. die Analyse des gemeinsamen Modells unnotigkomplex gestaltet. Beispielsweise werden die CPU-Leistung, die Flash-Speicher-Großeoder die Peripheriegerate fur die jeweilige Softwarefunktion optimiert [PBKS07]. DieseAnforderungen fuhren zu bestimmten Fahigkeiten, die eine Hardwareplattform aufwei-sen muss, sodass dies die Auswahl an Hardwareplattformen und Varianten wahrend derKonfiguration einschrankt [BKPS14].

Temperaturüberwachung (TM)

Aktuelle Temperatur Visualisierung

100°C Warnung

Service-schnittstelle

History-Daten Einstellbarer MessabstandAnalog Digital

Legende

FeatureNotwendigOptional

Abbildung 1: Softwarevarianten eines Temperaturuberwachungssystems (TM)

Wir argumentieren, dass die Software- und Hardwarevarianten in unterschiedlichen Mo-dellen beschrieben werden sollten, da hierdurch die Abstimmung zwischen Software- undHardwarevarianten nachvollziehbar und flexibel durchgefuhrt werden kann. Dies ist be-sonders bei unterschiedlichen Lebenszyklen der Fall. Hierfur schlagen wir eine Methodezur getrennten Modellierung von Hardware- und Softwarevarianten vor. Die Modelle wer-den mittels Eigenschaften (hierarchisch geordnete Name-Wert-Paare) verbunden, sodassdiese nur lose gekoppelt sind und keine explizite Beziehung zwischen ihnen besteht. ZurKonfiguration wird ein Tool-basierter Matching-Algorithmus vorgestellt, der die notwen-digen Eigenschaften ermittelt. Hierdurch wird ein einfacherer Austausch der Hardwareermoglicht, sofern sich die Hardwareplattform andert. Weiterhin wird ein Entwicklungs-prozess fur eine kombinierte Entwicklung von HW/SW-Produktlinien vorgestellt.

Im folgenden Abschnitt wird eine Beispielproduktlinie vorgestellt, bevor in Abschnitt 2 dieverwandten Arbeiten beschrieben werden. Daraufhin wird das Konzept eines Hardware-Variabilitatmodells und eines Software-Variabilitatsmodells sowie die Modellierung derBeziehung diskutiert. Anschließend wird in Abschnitt 3 das Hardware-Variabilitatsmodellund die Modellierung von Abhangigkeiten beschrieben. Abschließend wird der Entwick-lungsprozess vorgestellt und eine Zusammenfassung gegeben.

Beispielanwendung: Zur Uberprufung des Ansatzes wurde eine Beispielproduktlinie ei-nes Temperaturuberwachungssystems (TM) verwendetet. Fur die Hardware wurden frei

8

verfugbare Arduino-Plattformen1 sowie Erweiterungen (Shields) verwendet. Das Beispiel-system besteht aus einem Arduino Mega Board und einem Shield, welches den Tempera-tursensor realisiert. Daruber hinaus werden andere Shields genutzt, um die Varianten zurealisieren. Dabei realisiert ein Ethernet Shield w5100 eine Schnittstelle zu dem Systemund ein LCD Keypad Shield die digitale Ausgabe von Werten auf einem LCD. Das Systemund der Ansatz wurden im Rahmen des europaischen Forschungsprojekt AMALTHEA2

entwickelt und wird im Rahmen von AMALTHEA4public erweitert. Innerhalb der Projek-te wurde/wird zusammen mit der Automobilindustrie eine offene open-source Entwick-lungsumgebung fur die Entwicklung von eingebetteten multi-core Systemen konzipiert,die Produktlinien unterstutzt.

Abbildung 1 fasst die verschiedenen Softwarevarianten des TM-Systems in einem Feature-Modell zusammen. In jedem Fall misst das System die aktuelle Temperatur und gibt dieseuber ein USB-Schnittstelle aus. Optional ist es moglich, eine digitale Visualisierung sowieeine Warnfunktion zu wahlen, die angezeigt, wenn die Temperatur uber 100 Grad Cel-sius steigt. Eine weitere optionale Variante ist die Service-Schnittstelle, die eine Verbin-dung mit dem System uber eine Ethernet-Schnittstelle ermoglicht. Uber diese Schnittstel-le konnen aktuelle und fruhere Temperaturwerte sowie die aktuelle Samplerate angezeigtwerden. Eine weitere Variante ermoglicht es, die Samplerate zu verandern.

2 Verwandte Arbeiten

Der Entwicklungsprozess fur Software-Produktlinien unterscheidet zwischen zwei Teilen,der Domanenentwicklung und der Anwendungsentwicklung [vdL02]. Dabei fokussiert dieDomanenentwicklung die Konzipierung der Plattform und die Anwendungsentwicklungdas Ableiten von Produkten unter Zuhilfenahme der Plattform. Fur die Domanenanalysewerden Feature-Modelle [KCH+90] eingesetzt, die wir ebenfalls fur die Modellierung derSoftwarevariabilitat verwenden.

Die Herausforderung, Hardware- und Softwareproduktlinien gemeinsam zu betrach-ten, wurde bereits im Telekommunikations- und Automobilbereich beschrieben [MH03,Bro06]. Einige Ansatze behandeln die Berucksichtigung von Hardwareaspekten im SPL-Entwicklungsprozess. Liebig et. al. [LALL09] erweitern den Prozess um eine weitere Pha-se der Domanenentwicklung fur die Hardware. Dabei werden Software- und Hardwareva-rianten in unterschiedlichen Feature-Modellen beschrieben, allerdings wird der Austauschvon Hardwareplattformen oder mehrere nahezu aquivalente Hardwareplattformen nichtberucksichtigt. Daher werden in diesem Ansatz direkte Abhangigkeiten zwischen Hard-ware und Software verwendet, was es jedoch nicht ermoglicht, zwei Hardwareplattformenoder Varianten mit gleichen Eigenschaften zu berucksichtigen. Wir verwendeten diese Ideeals Basis und erweiterten diese um eine Moglichkeit, Abhangigkeiten zu beschreiben, ohnedirekte Verbindungen zwischen Varianten zu spezifizieren.

Die Verwendung von Annotationen in Feature-Modellen wurde schon mehrfach fur Attri-

1www.arduino.cc2www.AMALTHEA-Project.org

9

bute oder Nicht-funktionale Anforderungen beschrieben [SRKS08, GWW+11]. Guo et al.schlagen ein Konzept zur optimierten Variantenauswahl auf Basis von einem gegebenenSatz von Ressourcenabhangigkeiten vor [GWW+11]. Dabei wird eine Menge an Soft-warevarianten ermittelt, die die gegebenen Ressourcenbeschrankungen einhalt. Bei die-sem Ansatz werden jedoch keine Hardwareplattformen oder Hardwarevarianten ermitteltoder spezifiziert, da lediglich Softwarevarianten betrachtet werden. In Bezug auf bisherigeAnsatzen annotieren wir nicht nur nicht-funktionale, sondern auch funktionale Anforde-rungen (Hardwareanforderungen und eine dazugehorige hierarchische Hardwarestruktur).Karatas et al. beschreiben einen Ansatz fur die Spezifikation von komplexen Abhangig-keiten in erweiterten (attributierten) Feature-Modellen [KOD10]. Dies eignet sich auchfur die Beschreibung von Abhangigkeiten zwischen Hardware und Software, allerdingswerden die Abhangigkeiten an einen Merkmalsnamen gebunden. Beim Austausch einesTeilbaum (z.B. der Hardwareplattform) oder bei Merkmalen die aquivalente Hardwarean-forderungen erfullen sind diese daher nicht ausreichend. Einige Ansatze behandeln denUmgang mit mehreren Softwareproduktlinien in Form von Multi-Produktlinien [HGR12].Im Unterschied zu unserer Arbeit wird dabei der Fokus auf die Aufteilung bzw. Verteilungvon großen Software-Produktlinien auf Team bzw. Organisationen gelegt.

In der Automobilindustrie ist AUTOSAR der de-facto-Standard fur die Beschreibungvon Steuergerate-Architekturen einschließlich der Software- und Hardwareanteile, wiezum Beispiel ein Beschreibungsmodell fur die Steuergeratehardware. Seit Ende 2013 un-terstutzt der Standard Softwarevarianten sowie deren Modellierung in Feature-Modellen[AUT14b]. Zudem ist es moglich, die Hardwarearchitektur von Steuergeraten einemAUTOSAR-eigenen Hardwaremodell in Form von Elementen und Attributen zu beschrei-ben. Eine Modellierung von Hardwarevarianten sieht die Spezifikation nicht vor und somitwerden auch keine Abhangigkeiten zwischen Hardware und Software berucksichtigt. Wirorientieren uns an dem Hardwaremodell und erweitern dies um Varianten.

3 Modellierung von variablen Systemteilen

Bei der Entwicklung von eingebetteten Systemen sind verschiedene Systemteile wie bei-spielsweise Software, Hardware, das Betriebssystem sowie deren Abhangigkeiten zu be-rucksichtigen. Um diese Entwicklung von variablen eingebetteten Systemen der Automo-bilindustrie zu ermoglichen, umfasst unser Ansatz zwei Modelle. Eins zur Beschreibungder Softwarevarianten und ein weiteres fur Hardwareplattformen und deren Varianten.

Zur Modellierung von Softwarevarianten werden erweiterte Feature-Modelle [KCH+90]eingesetzt. Um Abhangigkeiten zwischen den unterschiedlichen Varianten zu beschreiben,werden die bekannten require und exclude Constraints [CE00] eingesetzt. Abhangigkeiteninnerhalb eines Feature-Modells zur Beschreibung der Software wurden bereits mehrfachbeschrieben [CE00, KOD10] und sind nicht Fokus unserer Arbeit. Die Feature-Modellewurden um Annotationen zur Spezifikation von erforderlichen Hardwareeigenschaften er-weitert. Diese Annotationen beschreiben die erforderlichen Eigenschaften und die dazu-gehorige hierarchischen Hardwarestrukturen (vgl. Abschnitt 3.2).

10

3.1 Modell zur Beschreibung von Hardwareplattformen und Varianten

Fur die Beschreibung von Hardwareplattformen wurde, anders als in [LALL09], keinFeature-Modell verwendet, sondern ein eigenes Hardware-Variabilitatsmodell (HVM)spezifiziert (Abbildung 2). Dies Modell baut auf dem AUTOSAR Hardwaremodell[AUT14a] auf und fokussiert die Beschreibung der hierarchischen Hardwarestruktur so-wie die zur Verfugung stehenden Eigenschaften (Property). Zudem ist es moglich, Vari-

VariationPointVariationPointConstraintsourcetarget

Property

VariationElementHardwareElementPlatformaffectedElement

Abbildung 2: HVM Metamodel

anten (VariationPoint) zu spezifizieren und require und exclude Abhangigkeiten (Varia-tionPointConstraint) zwischen Varianten zu definieren. Jede Variante enthalt Elemente,die angeben, an welcher Stelle (VariationElement) die hierarchische Struktur der Hardwa-re geandert werden muss und welche Hardwareelemente (HardwareElement) sowie zu-gehorigen Eigenschaften (Property) hinzugefugt oder entfernt werden mussen.

Das HVM hat gegenuber einem Feature-Modell den Vorteil, dass es ermoglicht, Hard-wareelemente und Eigenschaften direkt fur die spatere Verbindung mit der Software zuverwenden. Weiterhin wird die Hierarchie der Elemente abgebildet, sodass Eigenschafteneindeutig identifizierbar sind. Zum Beispiel kann sich eine Eigenschaft Size 8KB auf ver-schiedene Hardwareelemente wie den Flash-Speicher oder SRAM der Beispielanwendungbeziehen. Abbildung 3 zeigt die modellierte Hardwareplattform der Beispielanwendung,einschließlich der Varianten. Diese enthalt die Variante Ethernet Schild W5100, die einHardware-Element Network mit dem Namen Ethernet zu der Plattform hinzufugt. Weiter-hin wird das Hardwareelement Network um die Eigenschaft Type mit dem Wert Etherneterweitert. Da kein vorheriges Hardwareelement Network oder dazugehorige Eigenschaf-ten existieren, sind keine Elemente aus der Plattform zu entfernen. Außerdem zeigt dieAbbildung die eindeutige Identifikation einer Eigenschaft. Beispielsweise identifiziert Ar-duino Mega 2560 − Speicher EEPROM 4 KB − size eindeutig das Hardwareelement, zudem die Eigenschaft size mit dem Wert 4096 gehort.

3.2 Abhangigkeiten in der Konfiguration von HW/SW-Produktlinien

Um die Abbildung von Abhangigkeiten in HW/SW-Produktlinien zu realisieren, ver-wendeten wir zunachst die bekannten require und exclude Abhangigkeiten der Feature-Modelle. Dabei stellte sich heraus, dass diese nicht ausreichen, da es wahrend der Konfi-guration dazu kommen kann, dass eine ebenfalls ausreichende Hardwarevariante aufgrundder direkten Abhangigkeit nicht gewahlt werden kann, wenn beispielsweise die Hardwa-

11

reeigenschaft size eines Hardwareelements memory mit dem Wert 32KB durch eine Vari-ante auf 64KB erhoht wird (vgl. [BKPS14]). Hier kann bei einer require-Abhangigkeit zuder 32KB Variante die Variante mit 64KB nicht mehr ausgewahlt werden, obwohl diesedie Anforderung ebenfalls erfullen wurde. Dieses Problem tritt ebenfalls auf, wenn ver-schiedene Hardwareplattformen wahrend der Konfiguration berucksichtigt werden sollen.Bei der Verwendung von komplexen Abhangigkeiten, wie sie beispielsweise in [KOD10]

Eigenschaft

Hardwareelement

Legende

Plattform

Abbildung 3: Hardwareplattform mit Varianten des TM-Systems (Tool-Sicht)

beschrieben werden, ist es moglich dies zu umgehen. Hierzu werden Bedingungen spezifi-ziert, die sich auf Attribute von Merkmalen beziehen, beispielsweise CPU 1.speed > 800.Falls ein anderes Merkmal (z.B. CPU 2) dieses Attribut erfullt, reicht dies allerdings nichtaus, da Bedingung an den Feature-Namen gebunden ist.

Um diese Probleme zu losen wurden Annotationen fur Softwarevarianten eingefuhrt, dienotwendige Hardwareeigenschaften, bestehend aus dem Namen der Eigenschaft und ei-nem Wert, angeben. Weiterhin wird eine Relation (großer, kleiner, gleich) angegeben, diewahrend der spateren Konfiguration mit einbezogen wird. Um die Eigenschaften eindeu-tig identifizieren zu konnen, wird zudem die Hierarchie der entsprechenden Hardwareele-menttypen annotiert. Diese Hierarchie beschreibt eine abstrakte Hardwarearchitektur (bei-spielsweise Microcontroller.Memory) und bezieht sich nicht auf konkrete Instanzen wiezum Beispiel Mikrocontroller Arduino Mega 2560.Memory EEPROM 4 KB. Hierdurchwird einerseits verhindert, dass eine notwendige Eigenschaft an einen Elementnamen ge-bunden wird und andererseits ermoglicht es, die spezifizierten notwendigen Eigenschaftenaufgrund ihrer abstrakten Beschreibung bei dem vollstandigen Austausch der Hardwarewiederzuverwenden.

Die erforderlichen Eigenschaften der ausgewahlten Softwarevarianten werden wahrendder Konfiguration zu einer abstrakten Hardwareplattform, die nur aus Hardwareelement-typen und Eigenschaften besteht, zusammengefugt. Dabei wird jede erforderliche Eigen-

12

Temperatur-überwachung

Visualisierung

History-Daten Einstellbarer Messabstand

Analog

Notwendige EigenschaftenAusgewähltes SW-Feature

Sensor.type=TMP36

Microcontroller.Memory.type=EEPROMMicrocontroller.Memory.direction=RW

Network.type=ETHERNET Automatische Prüfung

Platform Microcontroller Memory direction=RW type=EEPROM Network type=ETHERNET Sensor type=TMP36

Abstrakte HW-Plattform

HVM

...Service-schnittstelle

Aktuelle Temperatur

Abbildung 4: Matching-Verfahren wahrend der Produktkonfiguration

schaft der gewahlten Softwarevarianten unter Berucksichtigung der Hierarchie der entspre-chenden Hardwareelementtypen in die Plattform integriert. Eigenschaften mit der gleichenHierarchie von Elementtypen wie beispielsweise Microcontroller.Memory.type=EEPROMund Microcontroller.Memory.direction=RW werden auf einer Ebene eingefugt. Die Platt-form wird daraufhin von einem Matching-Algorithmus elementweise mit den konkretenHardwareplattformen (siehe Abbildung 3) und Varianten verglichen. Dabei wird zunachstuberpruft, ob die Blatter des abstrakten HW-Baums, z.B. Memory, in dem HVM vorhandensind. Ist dies der Fall, werden auch die Eigenschaften (z.B. direction=RW) entsprechendder spezifizierten Relation uberpruft. Sollten auch diese durch das HVM erfullt werden,wird zuletzt gepruft, ob die Hierarchie (Microcontroller.Memory) ubereinstimmt (Abb. 4).

Die zusatzliche Hardwaremodellierung wahrend der Entwicklung kann die Komplexitaterhohen, allerdings wird es hierdurch moglich, automatisch zu prufen, ob Hardware undSoftware zusammenpassen. Dies muss anderenfalls nach dem Auswahlprozess per Handdurchgefuhrt werden und ware dadurch aufwandiger und fehleranfalliger. Eine andereMoglichkeit ware die Spezifikation der Hardware auf der Implementierungsebene unddie Verwendung eines Variantenmodells fur Hardware und Software. Dies wurde unsererMeinung nach die Komplexitat aufgrund der Abhangigkeiten jedoch nur auf eine andereEbene verschieben und verhindern, dass Beteiligte entscheiden konnen, welche Hardwa-replattform verwendet werden soll, wenn mehr als eine zur Softwarekonfiguration passt.Daruber hinaus ist die Kombination von Hardware und Softwarevariabilitat beim Hard-wareaustausch hilfreich, da Tool-seitig uberpruft werden kann, ob die neue Plattform diegleichen Softwarevarianten unterstutzt.

4 Kombinierter Modellierungsprozess fur HW/SW-Produktlinien

Im Folgenden wird der kombinierte Modellierungsprozess fur die Entwicklung von wie-derverwendbaren Hardware- und Softwarevarianten vorgestellt, der dem Standard SPL-Prozess [vdL02] und dem von Liebig et. al. vorgeschlagenen Verfahren [LALL09] nahekommt. Wir stimmen mit Liebig et. al. uberein, dass der Standard-SPL Prozess um eineweitere Domanenentwicklungsphase fur die Hardware erweitert werden muss. Basierendauf unseren Erfahrungen bei der Umsetzung der Beispielanwendung sind wir jedoch der

13

Meinung, dass es notwendig ist, die Domanen-Analyse fur alle Systemteile gemeinsamdurchzufuhren. Abbildung 5 gibt einen Uberblick uber den Modellierungsprozess.

Domanenentwicklung: Die Domanenentwicklung startet mit der Domanenanalyse in derauf Basis von Domanenwissen und Anforderungen die Hardware- und Softwarevarian-ten definiert werden. Dieser Schritt (1) wird gemeinsam durchgefuhrt, da Fachwissenaus beiden Disziplinen notwendig ist und gegenseitige Einflusse, wie sie in eingebette-ten oder mechatronischen Systemen existieren [ABD+14], berucksichtigt werden mussen.Die Softwarevarianten werden in einem Feature-Modell und Hardwarevarianten in einemHVM, welches die Hierarchie der Hardwareelemente berucksichtigt, zusammengefasst.Weiterhin werden in diesem Schritt erste Abhangigkeiten zwischen Software und Hard-ware analysiert und spezifiziert.

Anwendungsentwicklung

Domänenentwicklung Verfeinern der Softwarevarianten-

beschreibung2b

Ermitteln von Produktvarianten

Analyse von Abhängigkeiten

Varianten-modelle

1

Spezifizieren der Komponenten-

architektur

Spezifizieren des Komponenten-

verhaltensKomponentenmodell

Ermitteln der Hardware-plattformen

2a

3

Verfeinern der Komponenten-beschreibung4b

4a

Verfeinern der Hardwarevarianten-

beschreibung5b

Definieren der Hardware-

eigenschaften5a

Domänen-wissen

Hardware Modelle

Target-spezifische Entwicklung

HW-Plattform & Plattform-spezifischer

Code

Software-partitionierung

Software-mapping

Varianten-konfiguration

6 7 8

Mapping-simulation

9

ECU-Konfiguration

12 13

Tracing

10 Traceanalyse

Analyse von Abhängigkeiten

Mapping-Optimierung

11

ArtefaktProzessschritt Integrierter AnalyseschrittGeplante Iteration

Legende

Parallele AusführungAlternative Ausführung

Abbildung 5: Kombinierter Hardware/Software-Entwicklungsprozess fur Produktlinien

Im Anschluss an die Variantendefinition werden die entsprechenden Software- und Hard-warearchitekturen definiert (2a, 3), wobei diese Schritte parallel durchgefuhrt werdenkonnen. Die Softwarekomponentenarchitektur definiert neben einer gemeinsamen Platt-form fur die Produktlinie auch die erforderlichen Schnittstellen und die Komponenten, dieeinzelne Varianten realisieren. Diese Realisierungen werden mit den jeweiligen Varian-ten uber Traceability-Links verbunden (2b). Weiterhin wird das Verhalten der Software-komponenten uber weitere Modelle (z.B. Blockdiagramme) definiert (4a, 4b). Wahrendder Realisierung der Software werden iterativ identifizierte Hardwareanforderungen indem Softwarevariantenmodell erganzt (5a), sodass diese fur die spatere Konfiguration zurVerfugung stehen. Zur Spezifikation dieser Anforderungen werden die beschriebenen an-notierten Hardwareeigenschaften verwendet. Die Hardwarearchitektur wird mittels Hard-wareelementen und Eigenschaften innerhalb des HVMs spezifiziert und enthalt zudem diezuvor definierten Varianten. Da Hardwareplattformen sehr unterschiedlich sein konnen,

14

obwohl sie eine ahnliche Funktionalitat bieten, ist es nicht immer ausreichend, diese mit-tels Varianten zu modellieren. Daher konnen in diesem Schritt mehrere Plattformen sowieVarianten definiert werden, die alle fur die Konfiguration berucksichtigt werden. Die spe-zifizierten Plattformen und weiteren Hardwarevarianten verfeinern das HVM (Schritt 5b).

Anwendungsentwicklung: In diesem Schritt wird ein Produkt aus der Produktlinie durchdie Auswahl von Varianten erzeugt. Diese Konfiguration berucksichtigt Hardware undSoftware gemeinsam (6) und wird mittels einer automatisch aus dem Software- undHardwarevariantenmodell generierten Konfigurationsansicht durchgefuhrt. Dabei werdenAbhangigkeiten berucksichtigt und nicht mehr wahlbare Varianten automatisch deakti-viert. Zudem wird gepruft, ob eine Hardwareplattform sowie deren verfugbare Variantenzu der Softwarekonfiguration passen (vgl. Abschnitt 3.2). Das Ergebnis der Konfigurati-on ist ein Softwareprodukt sowie eine kompatiblen Hardwareplattform. Da der Entwick-lungsprozess fur die Automobildomane vorgesehen ist, sind im Anschluss weitere Akti-vitaten notwendig, um die Software auf der Hardwareplattform zur Ausfuhrung zu bringen(7-13). Hierfur wird die Software zunachst aufgeteilt und auf Hardwareelemente verteilt.Anschließend ist es moglich, dies zu simulieren oder auf der Hardware Messungen durch-zufuhren und daraufhin Verbesserungen vorzunehmen. Alternativ kann die Software unterBerucksichtigung der ECU-Konfiguration auf die Hardware gebracht werden.

5 Zusammenfassung und Ausblick

In diesem Artikel wurde ein Ansatz und ein Prozess fur die kombinierte Entwicklungund Konfiguration von SW/HW-Produktlinien vorgestellt. Hierbei wurde ein Modell zurBeschreibung von Hardwarevarianten definiert und eine Technik zur Beschreibung vonAbhangigkeiten zwischen Software und Hardware vorgestellt. Weiterhin wurde diskutiert,warum wir der Meinung sind, dass sich Feature-Modelle nur bedingt fur die Modellierungder Hardware eignen. Zudem wurde ein Matching-Algorithmus beschrieben, der Konfi-gurationen hinsichtlich der Kombinierbarkeit von Hardware und Software uberpruft. Wirargumentieren, dass unser Ansatz den Aufwand der Konfiguration reduziert und einen ein-facheren Austausch von Hardwareplattformen und Varianten sowie Analysen ermoglicht.

Ausgehend von diesen Arbeiten, sollen zukunftig weitere Systemteile bei der Entwick-lung von variablen eingebetteten Systemen berucksichtigt und der Ansatz um eine Analy-semethode erweitert werden, die Anderungen hinsichtlich ihrer Auswirkungen analysiert.Dies soll die Ermittlung von Softwarevarianten ermoglichen, die nach einem Hardwa-reaustausch nicht mehr unterstutzt werden konnen. Weiterhin ist die Skalierbarkeit desAnsatzes durch große Modelle zu uberprufen.

Literatur

[ABD+14] H. Anacker, C. Brenner, R. Dorociak, R. Dumitrescu, J. Gausemeier, P. Iwanek,W. Schafer und M. Vaßholz. Methods for the Domain-Spanning Conceptual Design.

15

In Design Methodology for Intelligent Technical Systems. 2014.

[AUT14a] AUTOSAR GbR. AUTOSAR 4.1 - Generic Structure Template, 2014.

[AUT14b] AUTOSAR GbR. AUTOSAR 4.1 - Specification of ECU ResourceTemplate, 2014.

[BKPS14] C. Brink, E. Kamsties, M. Peters und S. Sachweh. On Hardware Variability and the Rela-tion to Software Variability. In 40th EUROMICRO Conference on Software Engineeringand Advanced Applications (SEAA), 2014.

[BPS12] C. Brink, M. Peters und S. Sachweh. Configuration of Mechatronic Multi Product Lines.In Proceedings of the 3rd International Workshop on Variability & Composition, 2012.

[Bro06] M. Broy. Challenges in automotive software engineering. In Proc. of the 28th int. conf.on Software engineering, 2006.

[CE00] K. Czarnecki und U. Eisenecker. Generative Programming Methods, Tools, Applicati-ons. Addison-Wesley, Boston, 2000.

[CHE05] K. Czarnecki, S. Helsen und U. Eisenecker. Staged Configuration Through Specializa-tion and Multi-Level Configuration of Feature Models. In Third International SoftwareProduct Line Conference, 2005.

[CN01] P. Clements und L. Northrop. Software Product Lines: Practices and Patterns. Addison-Wesley Professional, 2001.

[GWW+11] J. Guo, J. White, G. Wang, J. Li und Y. Wang. A genetic algorithm for optimizedfeature selection with resource constraints in software product lines. Journal of Systemsand Software, 2011.

[HGR12] G. Holl, P. Grunbacher und R. Rabiser. A systematic review and an expert survey oncapabilities supporting multi product lines. Information and Software Technology, 2012.

[KCH+90] K. C. Kang, S. Cohen, J. Hess, W. Novak und A. Peterson. Feature-Oriented DomainAnalysis, Feasibility Study. Bericht CMU/SEI-90-TR-21, SEI, 1990.

[KOD10] A. Karatas, H. Oguztuzun und A. Dogru. Mapping Extended Feature Models to Cons-traint Logic Programming over Finite Domains. In Software Product Lines: GoingBeyond, Lecture Notes in Computer Science. 2010.

[LALL09] J. Liebig, S. Apel, C. Lengauer und T. Leich. RobbyDBMS: a case study on hardwa-re/software product line engineering. In First Workshop on Feature-Oriented SoftwareDevelopment. ACM, 2009.

[MH03] A. Maccari und A. Heie. Managing Infinite Variability. In Workshop on Software Varia-bility Management, The Netherlands, 2003.

[PBKS07] A. Pretschner, M. Broy, I.H. Kruger und T. Stauner. Software Engineering for Automo-tive Systems: A Roadmap. In Future of Software Eng., 2007.

[SRKS08] M. Siegmund, N.and Kuhlemann, M. Rosenmuller, C. Kaestner und G. Saake. Inte-grated product line model for semi-automated product derivation using non-functionalproperties. In Workshop on Variability Modelling of Software-intensive Systems, 2008.

[vdL02] F. van der Linden. Software Product Families in Europe: The Esaps & Cafe Projects.Software, IEEE, 2002.

[VPBK10] K. Venkatesh Prasad, M. Broy und I. Krueger. Scanning Advances in Aerospace &Automobile Software Technology. Proc. of the IEEE, 2010.

16

Duplikatserkennung und Refactoring inMatlab/Simulink-Modellen

Thomas Gerlitz, Stefan Schake, Stefan Kowalewski

Embedded Software LaboratoryRWTH Aachen University

Aachen, Germany{gerlitz | schake | kowalewski}@embedded.rwth-aachen.de

Abstract: In dieser Arbeit wird ein Rahmenwerk zur Erkennung und Refactoring vonduplizierten Modellfragmenten innerhalb von Matlab/Simulink-Modellen vorgestellt.Dazu wird auf ein Duplikatserkennungsverfahren auf Basis von Layoutinformationenaus Matlab/Simulink-Modellen und auf aus der Literatur bekannte Verfahren zurückge-griffen. Die durch die eingesetzten Verfahren gefundenen Duplikate werden durch dasRahmenwerk kategorisiert, zusammengeführt und ggf. erweitert, so dass im Resultatder Analyse kein Duplikat oder dessen Vorkommen im Model mehrfach ausgegebenwird. Somit können die Erkennungsspektren einzelner Analysen kombiniert und dieGesamtpräzision erhöht werden. Zusätzlich zur Duplikatserkennung können gefundeneDuplikate durch das Rahmenwerk in einen gemeinsamen generischen Bibliotheksblocktransformiert werden. Dabei kann der erstellte Block zusätzlich mit Dokumentation zumVerhalten des Blocks oder anderen Metainformationen angereichert werden. GefundeneDuplikate können dann durch einen entsprechend parametrierten Bibliotheksblocksemi-automatisch refactored werden. Dies erhöht die Nachverfolgbarkeit bei Wieder-verwendung und Wartung von Modellteilen und verbessert gleichzeitig die Qualität desModells.

1 Einleitung

Während der modellbasierten eingebetteten Softwareentwicklung werden in der Automobil-und Avionikindustrie Werkzeuge wie Matlab/Simulink [MAT14] von The MathWorkseingesetzt. Matlab/Simulink ermöglicht über eine grafische Oberfläche die Modellierungvon Datenflussdiagrammen zur Realisierung von regelungstechnischen Anwendungen wiebeispielsweise der adaptiven Regelung des Außenlichts eines Automobils. Dafür kön-nen aus vorgegebenen oder selbsterstellten Bibliotheken Funktionsblöcke im Diagrammplatziert und durch Signale miteinander verbunden werden. Zusätzlich kann aus den inMatlab/Simulink erstellten Datenflussdiagrammen Programmcode für Steuergeräte gene-riert werden. Stateflow, eine Erweiterung von Matlab/Simulink, wird in dieser Arbeit nichtbetrachtet. Ebenso wie bei der traditionellen Softwareentwicklung müssen bei der Model-lierung von Software mit Matlab/Simulink Qualitätskriterien wie Modularität, Wiederver-wendbarkeit und Wartbarkeit aus der ISO/IEC 9126 [ISO01] beachtet werden. MöglicheQualitätseinbußen entstehen beispielsweise durch Duplizierung von Modellteilen oder

17

der erneuten Modellierung bereits vorhandener Funktionalitäten als Modellduplikate inSimulink-Modellen. Durch Modellduplikate wird die Redundanz innerhalb eines Modellserhöht was sich negativ auf die Wartbarkeit bzw. Änderbarkeit des Modells auswirkt, daFehlerkorrekturen und Änderungen an allen (möglicherweise unbekannten) Duplikatsvor-kommen durchgeführt werden müssen.

1.1 Problemstellung

Duplikatserkennung in modellbasierten Softwarearetefakten stellt seit einigen Jahren einenaktiven Forschungsbereich dar. Duplikate werden dabei nach verschiedenen Typen ka-tegorisiert, die sich an dem Übereinstimmungsgrad eines Duplikatsvorkommen zu einerDuplikatsbasis orientieren. Nach einer Taxonomie für Datenflussmodelle nach [GKHB10]wird zwischen vier Typen unterschieden:

∙ Grad 0: Exaktes Modellduplikat liegt vor

∙ Grad 1: Duplikatsvorkommen unterscheidet sich lediglich bezüglich Layout undanderen nicht-semantischen Attributen

∙ Grad 2: Duplikatsvorkommen kann sich zusätzlich durch im Block konfigurierteLiterale unterscheiden

∙ Grad 3: Duplikatsvorkommen kann zusätzlich weitere Blöcke enthalten bzw. Blöckeder Duplikatsbasis sind nicht mehr vorhanden

Zusätzlich zu diesen Duplikatstypen, welche sich hauptsächlich auf strukturelle Duplikatekonzentrieren, existieren ebenfalls semantische Duplikate, d.h. Modelle mit unterschiedli-cher Struktur, jedoch gleicher Funktionalität.

Auf dem Gebiet der Modellduplikatserkennung existieren bereits einige Arbeiten [DHJ+08,DS13, Cor13], jedoch sind diese oftmals auf bestimmte Duplikatstypen ausgerichtet oderverwenden Heuristiken, um Skalierungsproblemen zu umgehen, welche während der Lö-sung der Duplikatsentdeckung zugrundeliegenden Subgraph-Isomorphie entstehen. DieseAlgorithmen finden bei Anwendung auf dem gleichen Modell teilweise disjunkte bzw.sich überschneidende Duplikatsmengen. Zusätzlich stellt sich die Frage wie Duplikate imZuge der Modellwiederverwendung sinnvoll aufgelöst bzw. refactored werden können,sodass eine solche Refactoring-Entscheidung zum einen nachverfolgbar, als auch mit einersinnvollen Dokumentation des wiederverwendeten Modellfragments einhergeht.

Um die Präzision der Duplikatserkennung zu erhöhen wird in dieser Arbeit ein Verfahrenfür Matlab/Simulink-Modelle vorgestellt, welches durch mehrere Duplikatserkennungs-mechanismen gefundene Duplikate in einer eindeutigen Ergebnismenge zusammenführt.Dabei werden mehrfach erkannte Duplikate bzw. deren Vorkommen verworfen und alleVorkommen eines Duplikats, unabhängig von dem verwendeten Algorithmus, in einerErgebnismenge vereint. Zur Duplikatserkennung werden drei voneinander unterschiedlicheVerfahren verwendet. Ein in dieser Arbeit vorgestellter Algorithmus welcher anhand einer

18

Layout-Metrik Duplikate identifiziert, die aus der direkten Duplikation von Modellteilenresultieren, der von Deissenböck et. al. entwickelte ConQAT-Algorithmus [DHJ+08] undden graphbasierten gapprox-Algorithmus von Chen und Yan [CYZH07]. Zusätzlich zu derDuplikatserkennung stellen wir in dieser Arbeit ein Refactoringverfahren für Duplikate vor,welches Duplikate von Grad 0-2 zunächst generalisiert und konfigurierbar in einen Biblio-theksblock auslagert. Dabei werden Variationen in Duplikaten ersten und zweiten Gradeserkannt und innerhalb des resultierenden Bibliotheksblocks als Parameter definiert. Nacherfolgreicher Generalisierung können Duplikatsvorkommen dann mit einer ggf. konfigu-rierten Instanz dieses Bibliotheksblocks refactored werden. Um die Wiederverwendbarkeitdieses Blocks zu erhöhen besteht zusätzlich die Möglichkeit den erstellten Bibliotheksblockzu dokumentieren.

Der Rest dieser Arbeit ist wie folgt strukturiert. Abschnitt 2 beinhaltet eine Diskussionvon verwandten Arbeiten zur Duplikatserkennung und Refactoring für Matlab/SimulinkModelle. Anschließend wird in Abschnitt 3 das in dieser Arbeit umgesetzte Rahmenwerkzur Duplikatserkennung auf Basis von Layoutinformationen und die Duplikatsvereinigungbeschrieben. Abschnitt 4 beschreibt die Generalisierung und das Refactoring erkannterDuplikate durch Bibliotheksblöcke. Darauf folgt in Abschnitt 5 eine Diskussion über dieIntegration der beschriebenen Verfahren im artshop Modellrepository. Abschnitt 6 fasst dieInhalte dieser Arbeit zusammen und gibt einen Ausblick auf zukünftige Arbeiten.

2 Verwandte Arbeiten

Deissenböck et al. präsentieren in [DHJ+08] ein heuristisches graphbasiertes Duplikats-erkennungsverfahren für Matlab/Simulink-Modelle. Dazu wird das Modell zunächst übereine partielle Transformation in einen Graphen mit flacher Hierarchie umgewandelt, umauf diesem, über eine erweiterte Breitensuche und mit Hilfe einer Heuristik, isomorpheTeilgraphen zu identifizieren.

Dörr et. al. präsentieren in [DS13] einen rein heuristischen Ansatz welcher auf Basiseiner modifizierten Halstead-Metrik Duplikatskandidaten auf Subsystem Ebene in Mat-lab/Simulink-Modellen finden kann. Dabei werden für jedes Subsystem in Abhängigkeitder darin enthaltenen Blöcke nach der modifizierten Halstead-Metrik Komplexitätswerteberechnet. Subsysteme mit ähnlichen Komplexitätswerten dienen dann als Kandidatenfür mögliche Subsystemduplikate. Partielle Modellduplikate innerhalb eines Subsystemskönnen mit diesem Verfahren nicht erkannt werden. Die Autoren skizzieren ebenfalls einVorgehen zur Ersetzung von gefundenen Subsystem-Duplikaten für verschiedene Dupli-katsgrade. Genauere Hinweise zur Realisierung werden jedoch nicht gegeben.

Die Autoren aus [Cor13] verwenden eine angepasste Version von NiCad, ein Tool zurtextbasierten Code-Duplikatserkennung, um Duplikate in den Modelldateien von Mat-lab/Simulink-Modellen zu finden. Dabei werden Zeichenkettenvergleiche auf Dateiebenedurchgeführt, um übereinstimmende Modellteile zu identifizieren. Das vorgestellte Verfah-ren kann dabei Duplikate von Grad 0-3 identifizieren.

Um Duplikate nach der Erkennung aufzulösen wird von Tran et. al die Verwendung atomarer

19

Refactoringoperationen vorgeschlagen, welche in [TWD13] dazu verwendet werden, umModelltransformationen auf einem Matlab/Simulink-Modell vorzunehmen. Dazu zählenbeispielsweise die Neuanordnung von Ports oder das Vereinen von Subsystemen. EinAlgorithmus zum Refactoring von Duplikaten wird jedoch nicht vorgestellt.

3 Duplikatserkennung für Matlab-Simulink-Modelle

Die Duplikatserkennung des in dieser Arbeit vorgestellten Rahmenwerks setzt sich ausdrei Verfahren zusammen. Ein Algorithmus welcher anhand einer Layout-Metrik Duplikateidentifiziert welche aus der direkten Duplikation von Modellteilen resultieren, der vonDeissenböck et. al. entwickelte ConQAT-Algorithmus [DHJ+08] und den graphbasiertengapprox-Algorithmus von Chen und Yan [CYZH07]. Im Folgenden wird lediglich dasErkennungsverfahren auf Basis der Layoutmetrik beschrieben, für die anderen Verfahrensei auf die Beschreibung innerhalb der Literatur verwiesen.

3.1 Duplikatserkennung mithilfe von Layoutinformationen

Bedingt durch die graphische Benutzeroberfläche von Matlab/Simulink lassen sich perCopy & Paste sehr einfach exakte Modellduplikate erstellen. Solche Duplikate besitzendie Eigenschaft, dass das relative Layout des duplizierten Modellteils mit dem relativenLayout des Ursprungs übereinstimmt. Diese Eigenschaft wird im Rahmen dieser Arbeit zurEntwicklung eines Duplikatserkennungsverfahren auf Basis einer Layout-Metrik genutzt,welche die Positionierung von Blöcken zueinander zur Erkennung von Duplikaten nutzt. ImGegensatz zum Verfahren aus [DS13], welches eine Metrik für ganze Subsysteme berechnet,arbeitet dieses Verfahren auf Basis einzelner Blockpaare, welche nach der Berechnung derMetrik zur Expansion zu Duplikaten verwendet wird.

Die Layout-Metrik wird für jeden Block des Eingabegraphen in Abhängigkeit seinerPosition im Verhältnis zu allen adjazenten Blöcken berechnet. Dabei werden ausgehendvon jedem Block zwei Vektoren 𝑣1 und 𝑣2 für jeden adjazenten Block berechnet, wie inAbbildung 1 beispielhaft dargestellt ist. Somit werden sowohl Distanz zweier adjazenterBlöcke als auch deren Dimensionen in die Layout-Metrik miteinbezogen.

Abbildung 1: Berechnung von 𝑣1 und 𝑣2

20

Die sortierte Menge aller 𝑣1 und 𝑣2 bildet die Layout-Metrik eines Blocks.

Die Layout-Metrik kann genutzt werden, um zunächst Blockpaare im Eingabegraphen zuidentifizieren, deren Metrik übereinstimmt. Dazu werden Layout-Metriken zweier Blöckeverglichen. Diese sind gleich, wenn die Anzahl an Vektoren übereinstimmt und die Distanzder X- wie Y-Werte zweier Vektoren der Blöcke maximal um einen Schwellenwert 𝑇 abwei-chen. Dieser Distanzschwellenwert wird standardmäßig auf fünf festgelegt. Abweichungenkönnen beispielsweise durch geringfügige bzw. versehentliche Änderungen am Blocklayoutvon kopierten Modellteilen entstehen. Stimmt die Layout-Metrik zweier Blöcke überein,können auch jeweils adjazente Blöcke als Blockpaare erfasst werden, da nach Konstruktionder Metrik auch ihre Position übereinstimmt.

Im Eingabegraph identifizierte Blockpaare dienen im Folgenden als Basis für die Suche nachDuplikaten. Dabei wird für jedes Blockpaar eine Breitensuche innerhalb des Subsystemsdes jeweils gewählten Blockpaares durchgeführt, wobei gefundene Blöcke mit gleicherLayout-Metrik zum Duplikat hinzugefügt werden. Der Algorithmus betrachtet dabei jedesidentifizierte Blockpaar nur einmal. Duplikate, die aus weniger als einer konfigurierbarenAnzahl von Blockpaaren bestehen, werden verworfen, wobei als Standardwert fünf Blöckefestgelegt sind.

Nach Konstruktion der Metrik können mit diesem Verfahren hauptsächlich Duplikate iden-tifiziert werden, welche exakt von einem anderen Modellteil kopiert wurden. Duplikatedieser Art können zwar grundsätzlich ebenfalls von dem zusätzlich verwendeten ConQAT-und gapprox-Algorithmus entdeckt werden, jedoch sind diese nach Konstruktion als signifi-kant einzustufen, da Sie nur in seltenen Fällen nicht durch das explizite Duplizieren einesModellfragments entstehen.

3.2 Duplikatsvereinigung

Die simultane Verwendung mehrerer Algorithmen zur Duplikatserkennung macht es er-forderlich, die möglicherweise überlappenden Ergebnisse einzelner Verfahren geeignet zuvereinen, um sowohl einen redundanzfreien Überblick über vorhandene Duplikate zu präsen-tieren als auch der anschließenden Generalisierung möglichst vollständige Informationenzur Verfügung zu stellen. So kann es etwa durch Unterschiede in den von den Verfahrengenutzten Heuristiken, wie Beschriftungsfunktionen zur Bestimmung „gleicher“ Blöcke,passieren, dass ein Duplikat eines Verfahrens sich nur um einen einzelnen Block vomDuplikat eines anderen Algorithmus unterscheidet. Manche Verfahren wie die vorgestellteDuplikatserkennung mittels Layout-Metrik liefern konstruktionsbedingt nur Duplikatspaareund können nicht alle Vorkommen direkt bestimmen.

Zur Vereinigung werden alle Duplikate, aufgeteilt in ihre Komponenten Basis und ein odermehr Vorkommen, die jeweils als Blockmengen betrachtet werden, miteinander verglichen.Einzelne Blöcke können dabei über Konkatenation vom Namen des enthaltenden Modellsund der automatisch von Matlab/Simulink für jeden Block vergebenen Simulink Identifier(SID) eindeutig identifiziert werden. Ist eine Komponente eines Duplikats eine genaueÜbereinstimmung mit einer Komponente eines anderen, werden alle Komponenten beider

21

Duplikate zu einem neuen Duplikat vereint. Handelt es sich bei der Komponente einesDuplikats bloß um eine Teilmenge einer Komponente eines anderen, wird zusätzlich dieAnzahl an Vorkommen des kleineren Duplikats überprüft. Ist diese geringer oder gleich,wird das Duplikat als redundant verworfen. Ansonsten wird es als Teilduplikat dem größerenDuplikat zugeordnet.

Schließlich werden Duplikate, bei denen eine Komponente sich um maximal drei Blöcke zueiner Komponente eines anderen Duplikats unterscheidet, innerhalb von Duplikatsgruppenzusammen gruppiert. Dadurch gewinnt der Benutzer einen besseren Überblick über solcheDuplikate, die eine Vielzahl von Blöcken teilen.

4 Refactoring von Duplikaten in Matlab/Simulink-Modellen

Um die Qualität von duplikatsbehafteten Modellen zu erhöhen, sollten diese Duplikate auf-gelöst bzw refactored werden. Für die Realisierung eines solchen Mechanismus bieten sichvon Matlab/Simulink verwendete Modellbibliotheken an, in welchen wiederverwendbareBibliotheksblöcke erstellt werden können. Dadurch wird die mit Duplikaten verbundeneWartbarkeitsproblematik vermieden, da ein Bibliotheksblock zentral editiert werden kannund Änderungen automatisch in alle Modelle propagiert werden die den Bibliotheksblockenthalten. Gleichzeitig wirkt sich das Refactoring positiv auf die Modularität aus, da diezuvor duplizierte Funktionalität in einem Bibliotheksblock zur Verfügung steht, welcherdurch den Benutzer zusätzlich um Dokumentation ergänzt werden kann und für andere Nut-zer des Modells nutzbar und auffindbar ist. Ein semi-automatisches Verfahren wird bereitsin [DS13] diskutiert, jedoch beschränkt sich dieses auf die Extraktion von Subsystemenund unterstützt nur teilweise die Auflösung von Duplikatsvariationen. Das im Folgendenvorgestellte Verfahren besitzt diese Einschränkungen nicht und kann Duplikate von Grad0-2 in einen generalisierten Bibliotheksblock überführen, um diese anschließend mit einerentsprechend konfigurierten Instanz des erstellten Bibliotheksblocks zu refactorn.

4.1 Refactoringverfahren

Das Refactoringverfahren kann grob in drei Phasen aufgeteilt werden. Der initialen struk-turellen Erstellung des Bibliotheksblocks, der Identifikation von Differenzen zwischenDuplikatsbasis und deren Vorkommen und der Instanziierung und Parametrisierung deserstellten Bibliotheksblocks im Ursprungsmodell. Abbildung 2 zeigt das Verfahren beispiel-haft.

Erstellung des Bibliotheksblocks Um eine Duplikatsgruppe durch Instanzen eines ge-eigneten Bibliotheksblocks zu ersetzen, muss zunächst ein, das Duplikat wiederspiegelender,Bibliotheksblock in einer Blockbibliothek von Matlab/Simulink erstellt werden. Nach Er-stellung eines solchen Bibliotheksblocks werden zunächst die Blöcke und Linien aus derDuplikatsbasis in diesen übertragen. Für Linien die das Duplikat mit dem restlichen Modell

22

2

5

p InportOutport

Generic library block

Library blockp=2

Library blockp=5

Refactor

Abbildung 2: Beispiel zum Refactoring eines Duplikats

verbinden, werden entsprechende In- und Outports im Bibliotheksblock erstellt, welche dieSchnittstelle dieses Blocks zum restlichen Modell darstellt.

Bestimmung von Differenzen Für Duplikate ersten und zweiten Grades muss vor derInstanziierung des Bibliotheksblock bestimmt werden, an welchen Stellen sich die Dupli-katsvorkommen von der Basis unterscheiden. Dazu werden die Werte relevanter Parametervon Blöcken in der Basis mit den Werten für Blöcke in den Vorkommen der Duplikatsgrup-pe verglichen. Tabelle 1 zeigt einen Ausschnitt der verglichenen Parameter in Abhängigkeitvom Block-Typ. Dazu erforderlich ist eine injektive Abbildung 𝑚𝑖 : 𝑉Base ↦→ 𝑉𝑖, welchesfür das 𝑖. Vorkommen die Blöcke in der Basis (𝑉Base) denen des Vorkommens (𝑉𝑖) zuordnenkann. Diese Abbildungen werden bei der Durchführung der jeweiligen Erkennungsverfahrenund der Duplikatsvereinigung implizit bzw. explizit durch die Verfahren angelegt. Durch dasMapping ist es möglich, unterschiedliche Werte für Parameter zwischen einem Block 𝑏 inder Basis und Block 𝑚𝑗(𝑏) im Vorkommen 𝑗 zu erkennen. Für erkannte Unterschiede wirddabei neben den beteiligten Blöcken und dem Namen des Parameters jeweils der Wert in derBasis und der davon unterschiedliche Wert im Vorkommen abgespeichert. Schließlich wirdinnerhalb des Bibliotheksblocks ein Maskenparameter angelegt, welcher standardmäßigden Parameter-Wert des Basisblocks enthält. Dieser Maskenparameter wird abschließendmit dem entsprechenden Blockparameter des als unterschiedlich identifizierten Blocksinnerhalb des Bibliotheksblocks verknüpft. Dies ermöglicht während der Instanziierung desBibliotheksblocks eine entsprechende Parametrisierung. Zusätzlich dazu können während

Block Parameter Block ParameterMath Operator Constant ValueTrigonometry Operator Gain GainLogic Operator If ExpressionRelationalOperator Operator Sum InputsFcn Expr ManualSwitch CurrentSetting

Tabelle 1: Ausschnitt parametrierbarer Simulinkblöcke

23

des Refactoringprozesses Dokumentationen zu den Parametern des Blocks und zu derFunktionsweise des Bibliotheksblock hinzugefügt werden. Diese werden sowohl in derMaske des Bibliotheksblocks abgelegt oder können in Form eines Dokumentationsblocksinnerhalb des Bibliotheksblocks erstellt werden.

Nach der Erstellung und Generalisierung des Bibliotheksblocks können im letzten Schrittdes Verfahrens Duplikate mit Instanzen des Bibliotheksblocks refactored werden.

Instanziierung des Bibliotheksblock Um einen erstellten Bibliotheksblock zu instanzi-ieren wird zunächst eine Abbildung 𝑓𝑙 der Umgebung der Duplikate angelegt, sodass fürjeden Block des Duplikats, welcher eine ein- bzw. ausgehende Linie zu einem Block imModell besitzt, welcher nicht Teil des Duplikats ist, festgestellt werden kann, mit welchenBlöcken der Umgebung er verbunden ist. Anschließend werden alle Linien entfernt, dieals Ziel- oder Quellblock einen Block in der Basis oder einem der Vorkommen der Du-plikatsgruppe besitzen. Schließlich kann jeder Block in Basis wie Vorkommen gelöschtund jeweils eine Instanz des Bibliotheksblocks angelegt werden. Die Position des neuenBlocks wird dabei anhand der ehemaligen Position der Blöcke der Basis bzw. Vorkommenbestimmt. Schließlich muss jeder zuvor angelegte Bibliotheksblock mit den umliegendenBlöcken verbunden werden, um die Linien wiederherzustellen, die im ersten Schritt entferntwurden. Dies geschieht für die Duplikatsbasis über die zuvor angelegte Abbildung. Beider Verbindung der instanziierten Duplikatsvorkommen muss zuvor beachtet werden, wiedie Ports des neu erstellten Bibliotheksblocks auf die Blöcke innerhalb des Duplikatsvor-kommen abgebildet werden können, da die Ports des Bibliotheksblocks über die Strukturder Duplikatsbasis erstellt wurden. Dies geschieht über die in Abschnitt 4.1 definierteAbbildung 𝑚𝑖, indem, ausgehend von einem mit einem Port verbundenen Block der Basis,der korrespondierende Block innerhalb des aktuellen Duplikatsvorkommen identifiziertwird. Mit Hilfe der Abbildung 𝑓𝑙 können dann die entsprechenden Ports der instanziiertenBibliotheksblöcke mit ihrer Umgebung verbunden werden.

5 Tool-Support

Die vorgestellten Verfahren wurden in einer erweiterten Version des artshop Modellr-epositories aus [WGMK13] integriert. In diesem können Artefakte des modellbasiertenEntwicklungsprozesses in eine Datenbank importiert, analysiert und mit Metainformationenangereichert werden. Änderungen an den in der Datenbank gespeicherten Artefakten könnennachvollzogen und wieder zurück in die Ursprungsmodelle übertragen werden. Zu den vonartshop unterstützten Artefakten zählen beispielsweise Matlab-Simulink/Stateflow-Modelle,formale Module aus IBM Rational Doors und Variabilitätsmodelle aus pure::variants.Simulink-Modelle können von artshop aus Matlab/Simulink ausgelesen und verändertwerden. Die vorgestellten Verfahren beziehen eine Abstraktion des Simulink-Modells ausder Datenbank und führen auf diesem die Duplikatserkennung aus. Durch das Refacto-ringverfahren angelegte Bibliotheken und deren Inhalt können ebenfalls in der Datenbankabgelegt werden. Die Aktionen des Benutzers werden somit nachvollziehbar sowohl in den

24

Ursprungsmodellen als auch in den Artefakten der Datenbank nachgehalten. Die Umset-zung des Refactoringprozesses in Matlab/Simulink wurde dabei ähnlich konzipiert wie diein [TWD13] erwähnten Refactoringoperationen. Dazu wurden zunächst atomare Opera-tionen auf Simulink-Ebene identifiziert und durch Konkatenation zur Generalisierung derDuplikatsbasis und Instanziierung des erstellten Bibliotheksblock genutzt. Die so erstelltenOperationen werden über eine Schnittstelle zu Matlab/Simulink direkt auf den analysiertenModellen ausgeführt.

Die Verfahren wurden mit der vorliegenden Integration empirisch unter anderem aufeinem Reglermodell eines Tiltwing UAV angewendet. Dabei konnten mehrere Duplikateinnerhalb des Modells mittels des vorgestellten Refactoringverfahrens beseitigt werden.Der Refactoringvorgang pro Duplikat nimmt dabei nur wenige Sekunden in Anspruch. DerBenutzer wurde bei der Anwendung des Verfahrens mit mehreren Wizards durch die Stufen(Duplikatserkennung, Präsentation der Ergebnisse, Refactoring) des Prozesses geführt, wasdie Nutzbarkeit des Verfahrens erleichtert.

6 Fazit und Ausblick

In dieser Arbeit wurde zunächst ein Duplikatserkennungsverfahren auf Basis von Lay-outinformationen vorgestellt. Dieses ermöglicht die Identifikation von „Copy & Paste“Duplikaten, welche hinsichtlich ihres Layouts nicht weiter verändert wurden. Die Ergeb-nisse dieses Verfahrens werden mit den Ergebnissen anderer Verfahren aus der Literaturkombiniert [DHJ+08, CYZH07], sodass in der Resultatsmenge jedes Duplikat nur einmalenthalten ist. Dies geschieht über die Kategorisierung und das Aussortieren redundan-ter Duplikatsvorkommen. Dies ermöglicht die zu betrachtende Duplikatsmenge auf dasWesentliche zu reduzieren und erhöht gleichzeitig die Präzision des Gesamtverfahrens.Der Nachteil dieses Vorgehen liegt in der erhöhten Komplexität die mit diesem Vorgeheneinhergeht. Dies erhöht die Laufzeit, was jedoch bei der Integration des Verfahrens in einennächtlichen Erstellungs- bzw. Auditingprozess im Rahmen eines kontinuierlichen Integra-tionsprozesses nicht zu stark ins Gewicht fallen sollte. Über das Verfahren identifizierteDuplikate können durch das ebenfalls vorgestellte Generalisierungsverfahren in Biblio-theksblöcke überführt werden. Dieses assistiert bei der gezielten Auflösung von Duplikaten,kann jedoch auch zur gezielten Wiederverwendung von Modellteilen verwendet werden.Die konsequente Anwendung des Refactoringverfahrens bei Wiederverwendung von Mo-dellteilen führt so zu einer erhöhten Wartbarkeit, da die generalisierten Modellteile zentralin Bibliotheksblöcken verwaltet und editiert werden können. An dem Bibliotheksblockdurchgeführte Änderungen werden dabei automatisch in allen Modellen übernommen inwelchen dieser eingesetzt wurde. Ein weiterer Vorteil ist die Möglichkeit den erstelltenBibliotheksblock zusätzlich mit Metainformationen wie Dokumentationen anzureichern.

Ein weiteres Einsatzgebiet der Duplikatserkennung in Verbindung mit dem vorgestell-ten Refactoringverfahren stellt die gezielte Suche nach bisher noch nicht instanziiertenVorkommen bereits vorhandener Bibliotheksblöcke dar. Somit können bereits erstellteBibliotheksblöcke semi-automatisch auch in Modellen eingesetzt werden, die nicht Teilder initialen Duplikatsanalyse waren oder durch unabhängige Entwicklungsteams erstellt

25

wurden. Ein solches Verfahren würde ebenfalls die Wartbarkeit und Wiederverwendungvon Modellen erleichtern. Zusätzlich könnte das Generalisierungsverfahren ebenfalls aufDuplikate dritten Grades ausgeweitet werden. Dies könnte beispielsweise über die De-komposition der Duplikate in mehrere Duplikate 0-2 Grades geschehen oder über dieIntegration variabler Modellkomponenten innerhalb des Bibliotheksblocks, welche nachBedarf aktiviert oder deaktiviert werden können. Beide Verfahren erhöhen jedoch entwederdie Komplexität des resultierenden Modells oder des generalisierten Bibliotheksblocks, wasdie Wartbarkeit der Blockbibliotheken als auch der verwendeten Modelle unter Umständennegativ beeinflusst.

Literatur

[Cor13] James R Cordy. Submodel pattern extraction for Simulink models. In Proceedings ofthe 17th International Software Product Line Conference, Seiten 7–10. ACM, 2013.

[CYZH07] Chen Chen, Xifeng Yan, Feida Zhu und Jiawei Han. gapprox: Mining frequent approxi-mate patterns from a massive network. In Data Mining, 2007. ICDM 2007. SeventhIEEE International Conference on, Seiten 445–450. IEEE, 2007.

[DHJ+08] Florian Deissenboeck, Benjamin Hummel, Elmar Jürgens, Bernhard Schätz, StefanWagner, Jean-François Girard und Stefan Teuchert. Clone Detection in AutomotiveModel-based Development. In Proceedings of the 30th International Conference onSoftware Engineering, ICSE ’08, Seiten 603–612, New York, NY, USA, 2008. ACM.

[DS13] Heiko Dörr und Ingo Stürmer. JUST SIMPLIFY Heuristische Duplikaterkennung aufModellen. In Informatik 2013 - Informatik angepasst an Mensch, Organisation undUmwelt, Seiten 2430–2442, 2013.

[GKHB10] Nicolas Gold, Jens Krinke, Mark Harman und David Binkley. Issues in clone classifica-tion for dataflow languages. Proceedings of the 4th International Workshop on SoftwareClones - IWSC ’10, Seiten 83–84, 2010.

[ISO01] ISO/IEC. ISO/IEC 9126. Software engineering – Product quality. ISO/IEC, 2001.

[MAT14] MATLAB. Version 8.30.0 (R2014a). The MathWorks Inc., Natick, Massachusetts,2014.

[TWD13] Quang Minh Tran, Benjamin Wilmes und Christian Dziobek. Refactoring of Simu-link diagrams via composition of transformation steps. In ICSEA 2013, The EighthInternational Conference on Software Engineering Advances, Seiten 140–145, 2013.

[WGMK13] Norbert Wiechowski, Thomas Gerlitz, Daniel Merschen und Stefan Kowalewski. EinAnsatz zum merkmalsbasierten Konsistenzmanagement in der Produktlinienentwick-lung. In Matthias Horbach, Hrsg., INFORMATIK 2013 - Informatik angepasst anMensch, Organisation und Umwelt, Jgg. P-220 of Lecture Notes in Informatics (LNI),Seiten 2502–2516. Köllen Druck+Verlag GmbH, Bonn, 2013.

26

Reducing Re-Validation Efforts for Real-time Systems∗

Tayfun GezginOFFIS – Institute for Information Technology

26121 [email protected]

Stefan HenklerUniversity of Applied Sciences Dortmund


Achim RettbergUniversity of Oldenburg


Abstract: Computations of systems in domains like automotive are typically dis-tributed over several resources. Dependencies among functions and interferences onshared resources complicate the verification of deadlines and end-to-end latencies.During the design process, changes affecting the specification and the implementa-tion of a system occur, such that already performed analyses have to be repeated. Toaddress these problems, in previous works we worked out a state-based analysis ap-proach to validate end-to-end deadlines for distributed systems. To handle changes, wedefined an appropriate refinement relation between the state spaces of resources. Thisallows us to determine whether we need to perform re-validations. We use contractsto further reduce the re-validation effort with respect to the specification of resources.In this work we outline our previous results and discuss the benefit of abstractions ofresource interfaces to boost the minimization of re-validation efforts.

1 Introduction

In recent years the amount of functions realized by software heavily increased in the au-tomotive domain. This trend will continue as X-by-Wire systems and the increased in-terconnections of vehicles to their environments leading to co-operating traffic systemsare already becoming commonplace in the market. Nissan for example offers a car witha steer-by-wire system, in which the steering commands are transmitted electrically to acontrol unit and then to an actuator which actually performs the steering movement. Afterthe start of production they had to recall the vehicles due to some delays in the emergencyprogram. As recalls are quite expensive, it is desirable to perform analyses at early designsteps. Unfortunately, many changes occur during the design process, such that already per-formed analyses have to be repeated. Our approach targets these problems. In [GSHR13]we worked out a state-based approach for the analysis of timing properties combining an-

∗This work was partly supported by European Commission funding the Large-scale integrating project (IP)proposal under ICT Call 7 (FP7-ICT-2011-7) (DANSE) (No. 287716), and the Federal Ministry for Educationand Research (BMBF) under support code 01IS12005M (SPES XT).

27

alytic and model checking methods. In analogy to model checking methods, we considerthe full state space for the analysis, where all task interleavings are preserved. In order toalleviate the problem of state space explosion due to state unfolding, the state space of anarchitecture is constructed in an iterative manner, where abstraction methods are appliedto keep the interfaces between components as small as possible.

On top of this analysis we worked out an impact analysis approach to minimize re-vali-dation efforts of timing properties needed when the considered system is modified. Im-pact analysis in our context means to automatically determine the parts of the architecture,which were affected by a changes, and need to be re-validated. Adaptations of the architec-ture of an already existing and analyzed system could be for example the addition of newtasks that are allocated to the existing system. To minimize the effort of a re-validation, itis desirable to reuse the previous results of the analysis that did not change. We definedtwo abstraction levels which are affected through changes, that is the specification level,and the implementation level. On the specification level we introduced a virtual integra-tion checking technique through the concept of reachability analysis of timed automata.We exploit so called contracts for such specifications. This enables us to distinguish as-sumed behavior, which must be offered by the environment of the system, and guaranteedbehavior, for which the system itself is responsible. On the implementation level we de-fined an appropriate refinement relation between state transition systems on the interfacesof components. These two concepts are typically exploited in combination. Changing acomponent implicates the integration of this component into its context, and the valida-tion of its implementation to the new components local specification. In this work wewill discuss the benefit of applying abstractions of resource interfaces represented as statetransition systems for the refinement relation.

Related Work There are three relevant research topics for our work, i.e. the analyticaland the model-checking -based analysis approaches for timing properties, and the checkingof contract refinements. We will give only the most relevant works for our approach.

The analytical approach for timing analysis is a holistic one, as it was worked out by e.g.Tindell and Clark [TC94]. Local analysis is performed evaluating fixed-point equations.The analysis is very fast and is able to handle large systems evaluating performance char-acteristics like time and memory consumption. Unfortunately, it delivers very pessimisticresults when inter-ECU task dependencies exist. In [TCG+01] activation pattern for tasksare described by upper and lower arrival curves realizing a more compositional analysismethod. Based on this work a compositional scheduling analysis tool, called SymTA/S,was created by SymtaVision [HHJ+05]. The concept has been developed by Kai Richteret al. The main idea behind SymTa/S is to transform event streams whenever neededand to exploit classical scheduling algorithms for local analysis. CARTS is another toolfor compositional real-time scheduling analysis [PLE+11]. Schedulability is checked fortasks whose resource usage is bounded by periodic resource models developed by Lee etal. Composition is done on the resource model level resulting again in periodic resourcemodels by using abstractions.

The second approach is based on model checking, and has been illustrated for examplein [FPY02, DILS09]. Here, all entities like tasks, processors, and schedulers are modeled

28

o31

τ11

τ12 τC1

τC2

ECU 1

CAN Busi11

τ21

τ22

ECU 2

τ31

τ32

ECU 3

i12

i21

i22

o32

A: i12 occurs each 100ms

G: Whenever i12 occurs o31 occurs within [60,80]ms

iC1

iC2

G: Whenever iC1 occurs i31 occurs within 10ms

i31

i32

A: i12 occurs each 100ms with jitter 2ms

G: Whenever i12 occurs iC1 occurs within 20ms

G: Whenever i31 occurs o31 occurs within 10ms

System 1

A: i21 occurs each 100ms

G: Whenever i21 occurs o32 occurs within [50,60]ms

A: iC1 occurs each 100ms with jitter 30ms

A: i31 occurs each 100ms with jitter 50ms

C1 C2

C3

C4

C5

Figure 1: Example system architecture with its contract-based specification.

in terms of timed automata. The advantage of this approach is that one gets exact solu-tions with respect to the modeled scheduling problem. As the state space of the analyzedsystem is preserved, checking complex characteristics like safety properties is possible.Unfortunately, the state-based approaches are not scalable, as the state space of the wholearchitecture is generated in one single step.

Considering the refinement of contracts a tool called OCRA was presented in [CDT13].There, contracts are specified in a pattern based language called Othello which are latertranslated to a temporal logic. They use an SMT solver to check such relations. We usea timed automaton approach to integrate it with our scheduling analysis approach. Thetheoretical foundation and practical application of the contract-based specification methodwere elaborated in [BCF+08, DHJ+11]. In [PR97] the authors propose a basic calculus foradding and removing channels and components in a dataflow architecture. The calculusformally allows for refinement checking between two system architectures.

2 Considered Architectures

We consider system architectures consisting of sets of processing units (ECU) and bussystems, on which a set of tasks is allocated. For tasks the best- and worst-case executiontimes with respect to the resource the task is allocated to are known. Each task has a fixedpriority. Independent tasks are triggered by events of a corresponding event stream (ES).An event stream ES = (p, j) is characterized by a period p and a jitter j with p, j ∈ N≥0.Such streams can be characterized by upper and lower occurrence curves as introduced inthe real-time calculus [TCN00], and timed automata. We restrict to event streams wherethe jitter is less than the period. We further assume that dependent tasks are connected,like e.g. in Figure 1 where τC1 depends on τ12.

We specify event streams, local task deadlines and deadlines for chains of tasks (globaldeadlines) by contracts. Contracts are pairs consisting of an assumption (A) and a guar-antee (G). The assumption specifies how the context of the component, i.e. the environ-ment from the point of view of the component, should behave. Only if the assumptionholds, then the component will behave as guaranteed. We use a pattern language called

29

requirement specification language (in short RSL) [RSRH11] to specify contracts. Theassumption part of a contract specifies an event stream. For the analysis, the text patternsare transformed to timed automata [GHSR14].

We consider both complete specifications which fully describe the interface between allcomponents, and incomplete specifications where the interface description of only a sub-set of components is given. In a design process incomplete specifications are quite typicalas some properties of parts of a systems may be obtained in later design steps. A com-plete interface specification is given for e.g. the task chain τ12, τC1, τ31 (see Figure 1):The assumptions of the contracts of ECU1, CAN Bus, and ECU3 describe the activationbehavior of the corresponding tasks τ12, τC1, and τ31. That is, the local contracts C3, C4

and C5 can be verified locally without considering any behavior of the systems from theirenvironment. An example for an incomplete specification is the task chain τ21, τC2, τ32for which only an end-to-end latency is specified. For such cases, a state-based analysis isuseful. For distributed systems analytical methods tend to yield pessimistic results due toabstractions needed to characterize the interfaces between the individual system resources.This typically leads to systems with much more resources used than really needed.

3 State-based Timing Analysis

Our aim is to construct the state spaces - i.e. the symbolic transition systems (STS) - ofeach resource of the considered system architecture in an iterative manner. For this, we as-sume cycle free systems. If we would have cyclic dependencies, we would need to performthe analysis in a holistic fashion. A state consists of a discrete location vector encodingthe states of all tasks, and an in-equation system (called zone) containing clock valuationsand differences between clocks. Clocks are needed to capture the timing behavior of tasks.For each task two types of clocks are needed. The first one traces the periodical activationof each task. Secondly, we have to trace the time frame from releasing a task (or a taskchain) up to the finish of computation. Besides a location vector and a zone, a state furtherincludes the information, which task is currently running, is interrupted, or in the readyqueue. Our timing analysis proceeds as follows: To build the STS of a resource, we haveto determine its input behavior, which defines the activation times of all allocated tasks.When the input is determined, the next step is to build the STS of the resource itself. Forthis, the input STS, the scheduling policy, and the execution times and priorities of theallocated tasks are taken into account. The computed STS of a resource is then used as aninput for dependent resources, i.e. for resources on which dependent tasks are allocated.To keep the interfaces between the resources as small as possible, parts of the STSs that arenot relevant for the input behavior of the dependent resources are abstracted. The detailsfor our approach can be found in [GSHR13].

4 Impact Analysis Methodology

On the specification level, we apply a virtual integration checking technique through theconcept of reachability analysis of timed automata. If our system specification is completethis technique allows us to determine the impact of changes which may occur during thedevelopment process of a system without the consideration of any implementation detail.

30

The more relevant part for this work is when the specification is incomplete, or whenchanges on the implementation level of a component occur. For this, an appropriate refine-ment relation between state transition systems has been defined. This refinement basicallyis a simulation relation between the states of the corresponding STSs: A state s simulatesstate s′, if its zone refines the zone of s′ (i.e. has tighter constraints) and s′ can (at least)react on all events on which s can react. The details for the impact analysis approach canbe found in [GHSR14].

5 Abstractions on Resource Interfaces

An impact analysis is useful in combination with analysis techniques that involve abstrac-tions. This is a typical scenario for analytic techniques such as in [RRR03]. These tech-niques are based on the assumption that every interface behavior can be characterized byevent streams. To obtain event streams for the outputs of a resource, the actual task behav-ior is generally over-approximated. Hence changes in the behavior of a particular resourcemight indeed have an impact on the already computed exact state-space representing itsoutput behavior, but might not have an impact on the over-approximated output behav-ior of the resource. This can be exploited by our impact analysis. Though our analysisapproach is an exact analysis in general, it can be combined with abstraction techniquesin order to reduce the state space of the interface transition systems. Such an abstractionindeed might affect the schedulability of a depending resource, and hence may cause falsenegative results. On the other hand, suitable abstraction techniques may pave the way toomit re-validations.

We consider event streams as the maximal abstraction of the timing behavior of a task,as these only contain information about best- and worst-case response-times, without anyinformation, in which cases the corresponding response times occurs. For example a taskcould have a large response time when it is interrupted by a high priority task which isallocated on the same resource, and an small response time, when no interrupts occur.

Currently, we are working on an abstraction technique which preserves such interferenceinformation between tasks. For this, we determine the set of states which are bi-simulationequivalent with respect to the untimed discrete behavior, i.e. without considering theirzones. Then, we remove all states from this equivalence set, for which holds that thevaluations of clocks representing execution times differ more than an user defined valueν ∈ N. All states remaining in this set are then merged. The effect of this abstraction is thatall response times only differ at a max of ν from the exact response times, while obtaininga smaller state space. In future work, we will determine the effects of this abstraction onend-to-end latencies.

6 Conclusion and Outlook

We sketched our impact analysis approach which operates on two different levels of asystem design, i.e. on the specification level and on the implementation level. These twoconcepts are typically exploited in combination. Currently, we investigate new abstractiontechniques which will yield more accurate results than the classical analysis techniques and

31

will boost the scalability of our approach. We illustrated the idea of such an abstractiontechnique in this work. The refinement check of the impact analysis approach benefitsfrom such abstractions, as more STSs can be found which are in a simulation relation.

References

[BCF+08] A. Benveniste, B. Caillaud, A. Ferrari, L. Mangeruca, R. Passerone, and C. Sofronis.Multiple Viewpoint Contract-Based Specification and Design. In Formal Methods forComponents and Objects, volume 5382, pages 200–225. Springer, 2008.

[CDT13] Alessandro Cimatti, Michele Dorigatti, and Stefano Tonetta. OCRA: A Tool for Check-ing the Refinement of Temporal Contracts. In ASE IEEE, pages 702–705, 2013.

[DHJ+11] W. Damm, H. Hungar, B. Josko, T. Peikenkamp, and I. Stierand. Using contract-basedcomponent specifications for virtual integration testing and architecture design. In De-sign, Automation Test in Europe Conference Exhibition (DATE), pages 1–6, march 2011.

[DILS09] Alexandre David, Jacob Illum, Kim G. Larsen, and Arne Skou. Model-Based Frame-work for Schedulability Analysis Using UPPAAL 4.1. In G. Nicolescu and P.J. Moster-man, editors, Model-Based Design for Emb. Systems, pages 93–119, 2009.

[FPY02] E. Fersman, P. Pettersson, and W. Yi. Timed automata with asynchronous processes:schedulability and decidability. In Proceedings of TACAS. Springer, 2002.

[GHSR14] T. Gezgin, S. Henkler, I. Stierand, and A. Rettberg. Impact Analysis for Timing Re-quirements on Real-Time Systems. In IEEE International Conference on Embeddedand Real-Time Computing Systems and Applications (RTCSA2014), 2014.

[GSHR13] T. Gezgin, I. Stierand, S. Henkler, and A. Rettberg. State-based scheduling analysis fordistributed real-time systems. Design Automation for Emb. Systems, pages 1–18, 2013.

[HHJ+05] R. Henia, A. Hamann, M. Jersak, R. Racu, K. Richter, and R. Ernst. System levelperformance analysis - the SymTA/S approach. Computers and Digital Techniques, IEEProceedings, 152:148–166, 2005.

[PLE+11] L.T.X. Phan, J. Lee, A. Easwaran, V. Ramaswamy, S. Chen, I. Lee, and O. Sokol-sky. CARTS: A Tool for Compositional Analysis of Real-time Systems. SIGBED Rev.,8(1):62–63, March 2011.

[PR97] Jan Philipps and Bernhard Rumpe. Refinement of Information Flow Architectures.In Proceedings of the 1st International Conference on Formal Engineering Methods,ICFEM ’97, pages 203–, Washington, DC, USA, 1997. IEEE Computer Society.

[RRR03] K. Richter, R. Racu, and R.Ernst. Scheduling Analysis Integration for HeterogeneousMultiprocessor SoC. In Proc. RTSS, 2003.

[RSRH11] P. Reinkemeier, I. Stierand, P. Rehkop, and S. Henkler. A pattern-based requirementspecification language: Mapping automotive specific timing requirements. In SoftwareEngineering, LNI. GI, 2011.

[TC94] Ken Tindell and John Clark. Holistic schedulability analysis for distributed hard real-time systems. Microprocess. Microprogram., 40:117–134, April 1994.

[TCG+01] L. Thiele, S. Chakraborty, M. Gries, A. Maxiaguine, and J. Greutert. Embedded Soft-ware in Network Processors - Models and Algorithms. In Proc. of the First InternationalWorkshop on Embedded Software, EMSOFT, pages 416–434, London, 2001.

[TCN00] L. Thiele, S. Chakraborty, and M. Naedele. Real-time calculus for scheduling hardreal-time systems. In IEEE International Symposium on Circuits and Systems (ISCAS),volume 4, pages 101 –104 vol.4, 2000.

32

Integration von Virtueller Inbetriebnahme und

Variantenmanagement

Johannes H. Möck, Jens Weiland

Reutlinger Research Institute

Hochschule Reutlingen

Alteburgstraße 150

72762 Reutlingen

[email protected]

jens.weiland@ reutlingen-university.de

Abstract: Im Maschinen- und Anlagenbau wird im Kontext der Virtuellen

Inbetriebnahme (VIBN) ein reales Produkt anhand virtueller Modelle abgebildet

und simuliert. Durch die Simulation dieser Modelle kann vor der tatsächlichen

Fertigstellung des realen Produktes die benötigte Steuerungssoftware entwickelt

und gegen die virtuellen Modelle getestet werden. Die VIBN resultiert somit neben

einer beschleunigten Produkteinführungszeit auch in einer qualitativ ausgereifteren

Steuerungssoftware. Bei der Betrachtung von variantenreichen Maschinen oder

Anlagen entsteht je nach Simulationsumfang, -fokus und/oder -domäne eine Reihe

von Modellen, welche sich in verschiedenen Simulationswerkzeugen

wiederfinden. Dabei gilt es die unterschiedlichen Simulationsmodelle, wie auch

die dazu passende Steuerungssoftware inhaltlich konsistent auf die gewünschte

Variante zu konfigurieren, damit nach der Konfiguration ein reibungsloses

Zusammenspiel zwischen Steuerungssoftware und Simulationsmodellen

gewährleistet werden kann. Im Rahmen dieses Artikels werden Konzepte

aufgezeigt, wie variantenreiche Simulationsmodelle und die dazu gehörige

Steuerungssoftware hinsichtlich einer konkreten Variante konsistent konfiguriert

werden können. Die hierfür notwendige Varianteninfrastruktur, in welcher die

unterschiedlichen Werkzeuge interagieren, wird beschrieben und eine mögliche

Umsetzung aufgezeigt.

1 Einführung

Die Wettbewerbsfähigkeit im Maschinen- und Anlagenbau basiert zu entscheidenden

Teilen auf der Fähigkeit des Systemherstellers zeitnah eine kundenspezifische, qualitativ

hochwertige aber dennoch kostengünstige Lösung anbieten zu können. Diese Prämissen

lassen sich im Entwicklungsprozess der Maschine oder Anlage aber nur begrenzt

gemeinsam maximieren und stehen sich ab einem bestimmten Zeitpunkt zwangsläufig

als konkurrierende Charakteristika gegenüber. So liegt es beispielsweise im Ermessen

des Systemherstellers wieviel Zeit und somit Kosten er in die Änderbarkeit und

Übertragbarkeit seines Produktes investiert. Werden nur die vereinbarten

Funktionalitäten entwickelt, oder wird bereits an dieser Stelle das Produkt im Hinblick

auf zukünftige Erweiterungen bzw. die Wiederverwendung einzelner Komponenten

33

vorbereitet? Die hier notwendigen Entscheidungen müssen zumeist individuell getroffen

werden, da diese durch die unterschiedlichen Anforderungen, Voraussetzungen und

Gegebenheiten des jeweiligen Auftrages beeinflusst werden.

Angesichts dieser Zusammenhänge stellt die Virtuelle Inbetriebnahme (VIBN) im

Maschinen- und Anlagenbau eine immer größere Bedeutung dar. Verspricht sie doch

qualitativ bessere Steuerungssoftware, eine kürzere „Time-to-Market“ und ein

kostengünstigeres Vorgehen gegenüber dem klassischen Entwicklungsprozess.

Abbildung 1: Grundidee der VIBN [Wu07]

Das Konzept der VIBN ist in Abbildung 1 dargestellt. Es sieht das Vorwegnehmen von

simulierbaren Aufgaben aus der Inbetriebnahme vor. Im Maschinen- und Anlagenbau

wird die Inbetriebnahme als die erstmalige bestimmungsgemäße Verwendung der

Maschine oder Anlage beschrieben. [EG06] Für die VIBN wird ein virtuelles Modell

erstellt, welches die reale Maschine oder Anlage abbildet und im Entwicklungsprozess

mit der Simulation schon frühzeitig Verwendung findet. Parallel zur

Maschinenentwicklung (Konstruktion und Montage) der realen Maschine oder Anlage

können anhand des virtuellen Modells viele Arbeitsschritte und Optimierungen aus der

Inbetriebnahme vorweg genommen werden. Die in der Inbetriebnahme umfangreichste

Aufgabe ist das Anpassen und Testen der für den Betrieb der Maschine oder Anlage

benötigten Steuerungssoftware. Da die Phase der Inbetriebnahme selbst bis zu einem

Viertel der gesamten Projektlaufzeit ausmachen kann, bietet sich hier erhebliches

Einsparungspotenzial. Die VIBN resultiert also in einer zeitlichen Verkürzung der

Inbetriebnahme und somit in einer früheren finalen Abnahme des Produktes. Die

Steuerungssoftware lässt sich durch die VIBN früher gegen das virtuelle Modell

entwickeln und testen. Dadurch kann der Reifegrad der Steuerungssoftware in

erheblichem Umfang gesteigert werden. Auch kann der bei der Simulation des virtuellen

Modells gewonnene Wissensgewinn direkt in die Konstruktion der Maschine bzw.

Anlage einfließen.

Ein Grund, warum die Simulationsmodelle noch nicht industrieweit Verwendung finden

ist der Aufwand zur Anpassung der Modelle an die jeweilige Maschinenvariante. Bei

einer steigenden Anzahl von zu entwickelnden Maschinen oder Anlagen entsteht für den

34

Entwickler, bzw. Produktverantwortlichen die Anforderung, sich sinnvoll mit der schnell

steigenden Anzahl an möglichen Varianten seiner Maschinen oder Anlage

auseinanderzusetzen. Eine systematische Wiederverwendung ist hierbei die

entscheidende Grundlage für eine kundenindividuelle Entwicklung von

Produktvarianten. Eine möglichst hohe Wiederverwendung bereits erstellter Software-

und Modellelemente senkt die entstehenden Aufwände und Kosten. Zusätzlich wird

durch die bereits vorhandenen und damit schon ausgereifteren Elemente die

Produktqualität gesteigert und der zeitliche Umfang der Entwicklung reduziert.

Der Fokus dieses Artikels liegt auf der Präsentation einer Infrastruktur für die

Handhabung von Variabilität - und der darin vorhandenen Variantenschnittstelle - im

Kontext der VIBN im Maschinen- und Anlagenbau. Im Abschnitt 2 werden zunächst

grundlegende Informationen über das Abbilden von Variabilität mittels

Merkmalsmodellen beschrieben. Anschließend werden die für diese Arbeit notwendigen

Konzepte aufgeführt. Schließlich wird im Abschnitt 3 ein Konzept vorgestellt wie eine

Varianteninfrastruktur und deren Variantenschnittstelle umgesetzt werden können. Das

vorgestellte Konzept wird schließlich in Kapitel 4 anhand eines Beispiels validiert.

Abschnitt 5 fasst den Artikel zusammen.

2 Modellierung und Darstellung von Variabilität

Eine Möglichkeit um die Variabilität in einem System abstrakt darzustellen, ist die

Modellierung von Merkmalmodellen. Mit Hilfe dieser Merkmalmodelle kann

anschließend eine gültige Variante des Systems konfiguriert werden. Für die

Entwicklung von Merkmalmodellen werden die variablen Elemente eines Systems in

Form von Merkmalen in einer Baumstruktur abgebildet und miteinander in Beziehung

gesetzt. Dies kann durch eine Zuordnung innerhalb der Hierarchie im Merkmalbaum

geschehen und/oder durch das Festlegen des Variabilitätstyps der einzelnen Merkmale.

Hierbei werden vier Variabilitätstypen unterschieden. Bekommt ein Merkmal den

„Pflicht“- Variabilitätstypen, so bedeutet dies, dass die Merkmalspezifikation nur gültig

ist, wenn dieses Merkmal Teil diese Spezifikation ist. Ein „optionaler“-Variabilitätstyp

dagegen legt die Entscheidung frei, ob das Merkmal Teil der Merkmalspezifikation ist

oder nicht. Die Verknüpfung zweier oder mehr Merkmale mit dem „alternativen“-

Variabilitätstyp bedeutet, dass nur genau eines dieser Merkmale Teil einer

Merkmalspezifikation sein darf. Schließlich gibt es noch den „oder“-Variabilitätstyp,

welcher auf zwei oder mehr Merkmale angewendet werden kann. Er besagt, dass

mindestens eins aber auch mehrere Merkmale für eine gültige Merkmalspezifikation

ausgewählt werden kann. [ES04]

Um im Maschinen- und Anlagenbau einen möglichst modularen Aufbau aus bereits

vorhandenen und getesteten Teilmodulen zu ermöglichen muss zuerst zwischen den

gemeinsamen und variantenspezifischen Komponenten der Steuerungssoftware

unterschieden werden. Hierfür eignet sich das Konzept des Engineering von

Softwareproduktlinien, welches mit der Zielsetzung einer systematischen

Wiederverwendung den Fokus auf das Unterscheiden von gemeinsamen und variablen

Artefakten legt. [CN01][GS04] Das Engineering von Softwareproduktlinien geht an

35

dieser Stelle allerdings nicht auf die Vorgehensweise ein, wie eine Systemvariante

„gebaut“ werden kann. Dies liefert das Konzept der Generativen Softwareentwicklung,

welche eine automatische Generierung von Systemvarianten beschreibt. [CE00] Dabei

wird zwischen der Abstraktion der Variabilität mittels Merkmalmodellen auf der einen

Seite, der konkreten Implementierung der Variabilität in der Software auf der anderen

Seite und dem Konfigurationswissen welches Abhängigkeiten zwischen beiden Seiten

beschreibt, unterschieden.

Im Rahmen des Engineering von Softwareproduktlinien wird zwischen den variablen

und den gemeinsamen Komponenten einer Software unterschieden. Um die variablen

Elemente einer Software abzubilden werden Variationspunkte (VP) in der Software

benötigt. Diese VP erlauben es, dass die Software hinsichtlich einer Variante

konfiguriert werden kann. Für die Implementierung wird ein eindeutiger Kennzeichner

benötigt, welcher den VP für die automatisierte oder manuelle Bearbeitung eindeutig

erkennbar macht. Zusätzlich benötigt der VP einen Mechanismus, welcher für die

konkrete Umsetzung der Konfiguration verantwortlich ist. Je nach Implementierung

werden in dem VP direkt die unterschiedlichen Varianten oder die für ihre Konfiguration

notwendigen Informationen gespeichert.

Derzeit bieten überhaupt nur wenige Simulationswerkzeuge wie beispielsweise

Matlab/Simulink von MathWorks Methoden an um mit Variabilität im

Simulationsmodell umzugehen [CM12][HKM13]. Die meisten Simulationswerkzeuge

bieten kein explizites Variantenhandling an. Es muss eine generische Schnittstelle

gefunden werden, wie das jeweilige Simulationsmodell in den Werkzeugen

angesprochen und die darin befindlichen Variationspunkte konfiguriert werden können.

Dazu bedarf es je nach vorhandener Werkzeugschnittstelle unterschiedlicher Lösungen.

Aktuell existiert keine generische Variantenschnittstelle, welche ein Konzept bietet,

automatisiert auf unterschiedliche Simulationswerkzeuge und die darin sich befindenden

Simulationsmodelle zuzugreifen und diese gemeinsam hinsichtlich einer Variante zu

konfigurieren.

3 Konzepte für eine Varianteninfrastruktur

Um im Kontext der VIBN eine automatisierte sowie werkzeugübergreifende

Konfiguration über mehrere variantenreiche Simulationsmodelle und der dazugehörigen

Steuerungssoftware zu ermöglichen, bedarf es einer funktionsfähigen Varianten-

infrastruktur. Die hier skizzierte Varianteninfrastruktur wird für das Konfigurieren des

Systems vor der darauf folgenden Simulationsphase verwendet. Die Varianten-

infrastruktur besteht dabei aus einem oder mehreren Simulationswerkzeugen, welche

jeweils ein oder mehrere variantenreiche Simulationsmodelle simulieren können. Die

Steuerungssoftware muss hierbei mit ihrer Variabilität und Konfiguration zwingend

konsistent zu den Simulationsmodellen sein. Ferner wird eine Konfigurationssoftware

benötigt, welche auf der einen Seite dem Anwender der Varianteninfrastruktur die im

System vorhandene Variabilität abstrakt darstellt und es ihm auf der anderen Seite

erlaubt das variantenreiche System hinsichtlich seiner Vorgaben zu konfigurieren. Um

den für die Konfiguration notwendigen Datenaustausch zu gewährleisten und dabei die

36

zwischen den einzelnen Werkzeugen vorhandenen Schnittstellen zu implementieren,

bedarf es einer Variantenschnittstelle. Diese Variantenschnittstelle fungiert als

Bindeglied zwischen den einzelnen Werkzeugen der Varianteninfrastruktur, ermöglicht

es neue Werkzeuge auf einfache Weise in die Varianteninfrastruktur zu integrieren und

sorgt für das konsistente Zusammenspiel sowie die Synchronisierung aller Teilnehmer.

Abbildung2: Varianteninfrastruktur Überblick

In Abbildung 2 wird ein Überblick über das Konzept der Varianteninfrastruktur anhand

eines Simulationswerkzeuges und einer Steuerungssoftware skizziert. Auf Basis der

Variantenschnittstelle kann die Varianteninfrastruktur selbst um eine beliebige Anzahl

weiterer Simulationswerkzeuge und Simulationsmodelle erweitert werden. Ob die nach

der Konfiguration auszuführenden Simulationen in Form einer Co-Simulation oder

individuell ausgeführt werden, wird durch die Varianteninfrastruktur nicht vorgegeben.

Für eine möglichst einfache Integration der Werkzeuge in die Varianteninfrastruktur ist

ein wesentliches Ziel der Variantenschnittstelle den Informationsaustausch zwischen den

Werkzeugen über gängige Schnittstellentechnologien durchzuführen. Hierzu gehören

z.B. das Functional Mock-up Interface (FMI) oder die Component Object Model

(COM)-Schnittstelle. Daneben gibt es eine Reihe weiterer Anforderungen an die

Variantenschnittstelle. So muss neben dem reinen Informationstransport innerhalb der

Varianteninfrastruktur für die Synchronisation aller Infrastrukturteilnehmer auch

sichergestellt werden, welches Werkzeug aktuell in die Infrastruktur eingebunden ist und

dass die aktuellen Zustände dieser Modelle auch auslesbar sind. Weitere Werkzeuge und

Modelle sollten sich mit nur minimalem Aufwand in die Infrastruktur integrieren lassen,

ohne dass diese dafür speziell angepasst werden müssen. Die Funktionalität der

Varianteninfrastruktur lässt sich auf verschiedene Aufgabenbereiche unterteilen: Für das

An- oder Abmelden von Werkzeugen oder Modellen an der Varianteninfrastruktur sind

administrative Funktionen notwendig. Zu den administrativen Funktionen lassen sich

auch Funktionen der Synchronisation der Varianteninfrastruktur und ggf. der

Netzwerkadministration zählen. Als weiterer wesentlicher Bestandteil der

Varianteninfrastruktur sind die Funktionen für das Variantenhandling, welche

beispielsweise für die Darstellung der Variabilität, oder das Konfigurieren einer

spezifischen Steuerungssoftware-/Modellvariante in den einzelnen Werkzeugen

verantwortlich sind. Daneben existieren eine Reihe weiterer Funktionen, welche die

Funktionalität der Varianteninfrastruktur auf unterschiedliche Art erweitern.

Beispielsweise können hier Analysefunktionen aufgeführt werden, welche sich die

Varianteninfrastruktur zu Nutze machen.

37

Die prinzipielle Arbeitsweise der Varianteninfrastruktur soll anhand des Use Cases zur

Konfiguration einer Variante von Steuerungssoftware und Simulationsmodellen über

verschiedene Werkzeuge hinweg aufgezeigt werden. Abbildung 3 zeigt den strukturellen

Aufbau. Der Ablauf dieses Use Cases beginnt damit, dass der Anwender sich in der

Konfigurationssoftware mittels eines Merkmalsmodelles eine gültige Merkmalauswahl

zusammenstellt.

Abbildung 3: Komponenten der Varianteninfrastruktur für die Ausführung einer Konfiguration

In der Konfigurationssoftware wird die die Merkmalauswahl des Anwenders mit dem

Wissen über die einzelnen Variationspunkte in den Simulationsmodellen und der

Steuerungssoftware abgeglichen. In Abbildung 3 ist dies durch die zwei Pfeile mit der

Kennzeichnung A dargestellt. Dabei entsteht die konkrete Konfiguration aller für diese

Variante involvierten Variationspunkte innerhalb der Varianteninfrastruktur. Diese

Informationen werden in Form einer Varianteninfrastruktur-Nachricht (VI-Nachricht)

verpackt und an die Variantenschnittstelle übermittelt. Dies findet sich in Abbildung 3

an durch den Pfeil an der Position B wieder.

Die wesentlichen Daten, welche an dieser Stelle übermittelt werden müssen, lassen sich

in zwei Teilbereiche untergliedern. Der erste Bereich bestimmt alle Metadaten dieser VI-

Nachricht. Insbesondere von wem die VI-Nachricht kommt, an welches Ziel

(Kombination aus Simulationswerkzeug und Modell, bzw. Steuerungssoftware und

Steuerung) sie gerichtet ist und welche Funktion mit ihr ausgeführt werden soll.

Zusätzlich gehören zu den Metadaten diejenigen Daten, welche für das Nachverfolgen

und Handling der einzelnen VI-Nachrichten notwendig sind. Neben den aufgeführten

Metadaten besteht der zweite Teilbereich der VI-Nachricht aus den Nutzdaten, welche

im vorliegenden Use Case die Konfigurationen der einzelnen Variationspunkte sind.

Falls eine andere Funktion der Varianteninfrastruktur ausgeführt werden sollte, so

können diese Nutzdaten entsprechend der gewählten Funktion verwendet werden.

38

Die Varianteninfrastruktur – bestehend aus einem Werkzeug zur Merkmalmodellierung,

einem Werkzeug zur Modellierung der Steuerungssoftware und verschiedenen

Werkzeugen zur Entwicklung der Simulationsmodelle – kann zentral auf einem Rechner

realisiert sein. In der industriellen Anwendung werden diese Werkzeuge voraussichtlich

in einem Rechnernetz verteilt sein. Ein sog. Variantenmanager, der die Software der

Varaintenschnittstelle implementiert ist verantwortlich für den konsistenten Austausch

von VI-Nachrichten im Rechnernetz. Je nach Verteilung der Werkzeuge ist der

Variantenmanager zentral als einzelne Softwarekomponente oder in Form von

dezentralen Komponenten auf den Netzknoten realisiert.

Beim Versand der VI-Nachrichten untersucht der Variantenmanager zunächst anhand er

Metadaten, ob für das angesprochene Werkzeug die notwendigen Funktionsmodule

geladen sind. Ein Funktionsmodul ist ein Set von Funktionen für das Variantenhandling,

welches für ein konkretes Werkzeug in seiner unterstützten Schnittstellentechnologie

(siehe oben) implementiert ist. Im vorgestellten Use Case ist das passende

Funktionsmodul im Speicher des Variantenmanagers geladen und kann auf die

spezifizierten Werkzeuge angewendet werden. In Abbildung 3 wird dies anhand der

zwei roten Pfeile mit der Markierung C dargestellt. Wird die Funktion erfolgreich

ausgeführt, so generiert der Variantenmanager anschließend eine positive Rückmeldung.

Falls der Variantenmanager kein passendes Funktionsmodul findet oder ein Fehler beim

Ausführen der Funktion auftritt, so wird dies rückgemeldet.

4 Einsatz der Varianteninfrastruktur

Um das dargelegte Konzept einer Varianteninfrastruktur zu validieren wurde eine

prototypische Implementierung aufgesetzt und anhand eines des in Kapitel 3

beschriebenen Use Cases ausgeführt. Dabei wurden zwei unterschiedliche

Simulationswerkzeuge exemplarisch verwendet. SimulationX von der Firma ITI GmbH

und RecurDyn von der Firma FunctionBay Inc. Für die Steuerungssoftware wurde

CODESYS von 3S-Smart Software Solutions verwendet. Als Konfigurationssoftware

wurde pure::variants von der Firma pure-systems GmbH in die Infrastruktur integriert.

Aktuell stehen weitere Werkzeuge zu Validierungszwecken in Planung. Als

abzubildendes Modell wurde die Automatisierungslösung SpeedPicker der Firma Manz

AG verwendet.

Der hier skizzierte Use Case sieht vor, dass sich in den beiden Simulationswerkzeugen je

ein Simulationsmodell des variantenreichen SpeedPickers befindet. In RecurDyn soll ein

kinematisches Modell für die Kollisionsberechnung simuliert werden. In SimulationX

wird dagegen ein Verhaltensmodell des SpeedPickers abgebildet. Die gleiche

Variabilität wie in den beiden Simulationsmodellen befindet sich auch in der CODESYS

Steuerung. Abgebildet wird diese Variabilität in pure::variants mittels eines

Merkmalmodells.

39

Abbildung 4: Skizzierter Aufbau einer prototypischen Implementierung der Varianteninfrastruktur

mit einer dezentralen Variantenschnittstelle

Wie in Abbildung 4 beispielhaft dargestellt befinden sich die einzelnen Werkzeuge

innerhalb eines Netzwerkes auf unterschiedlichen Rechnern. Exemplarisch wurden die

einzelnen Werkzeuge der Varianteninfrastruktur auf drei Rechnern verteilt. Dabei wird

pure::variants auf Rechner A gesetzt, SimulationX und CODESYS befinden sich dagegen

zusammen auf dem Rechner B. Auf dem Rechner C befindet sich RecurDyn. Eine lokale

Instanz des Variantenmanagers wird auf jedem der drei Rechner ausgeführt. Die

Variantenschnittstelle wird mit einem dezentralen Aufbau des Variantenmanager

implementiert. In pure::variants wird eine gültige Konfiguration des SpeedPickers

bestimmt. Die Varianteninfrastruktur soll diese Variante in den Simulationsmodellen

und der Steuerung umsetzen. Als Nachrichtenformat für den Datenaustausch innerhalb

der Varianteninfrastruktur wurde eine XML-basierte Datenstruktur spezifiziert.

Abbildung 5: Skizzierter Aufbau des „Variantenmanagers“

40

Sobald alle Infrastrukturteilnehmer gestartet sind, werden sie über die

Benutzeroberfläche des Variantenmanagers angemeldet. Dieses sich so aufbauende

Netzwerkwissen über die Varianteninfrastruktur wird aus der Kombination aus Sobald

alle Infrastrukturteilnehmer gestartet sind, werden sie über die Benutzeroberfläche des

Variantenmanagers angemeldet. Dieses sich so aufbauende Netzwerkwissen über die

Varianteninfrastruktur wird aus der Kombination aus Variantenmanager,

Simulationswerkzeugen (bzw. Steuerungssoftware) und Simulationsmodellen (bzw.

Steuerung) in einer internen Datenbank gespeichert. In Abbildung 5 ist dies durch eine

Baumstruktur skizziert. Ausgehend von der Konfiguration, welche in pure::variants

mittels eines Merkmalmodells des SpeedPickers erzeugt wurde, wird eine VI-Nachricht

generiert und an den lokalen Variantenmanager auf Rechner A gesendet. Dieser

verarbeitet die Nachricht und sendet sie je nach Zieladresse an den lokalen

Variantenmanager auf Rechner B und/oder C weiter. Hierbei wird von dem

Variantenmanager jeweils die passende Schnittstellentechnologie aus seinen internen

Funktionsmodulen werkzeugspezifisch gesucht. Der Variantenmanager auf Rechner B

verwendet für das Ansprechen der Steuerungssoftware CODESYS ein Python Skript in

Kombination mit der FMI-Schnittstelle, welche die gewünschten Konfigurationen in den

Variationspunkten innerhalb der SpeedPicker-Steuerung vornehmen. Für das

Ansprechen des SpeedPicker-Verhaltensmodells in SimulationX verwendet der

Variantenmanager ein Visual Basic Skript, welches über eine COM-Schnittstelle die

gewünschten Konfigurationen ausführen kann. Auf Rechner C verwendet der

Variantenmanager die Microsofts .Net – Technologie und den Import einer .dll um das

SpeedPicker-Kollisionsmodell in RecurDyn zu konfigurieren. Die Simulationsmodelle in

SimulationX und RecurDyn, sowie die dazu gehörige Steuerung in CODESYS sind nun

konsistent auf eine Variante konfiguriert und können gemeinsam simuliert werden.

5 Zusammenfassung

Damit im Maschinen- und Anlagenbau die VIBN an variantenreichen Systemen

wirtschaftlich durchgeführt werden kann, wird eine systematische Wiederverwendung

von Steuerungssoftware und Simulationsmodellen benötigt. Das Engineering von

Softwareproduktlinien stellt Konzepte bereit für eine systematische Wiederverwendung

von Softwarekomponenten. Der Schwerpunkt liegt hierbei auf der Betrachtung von

gemeinsamen und variablen Artefakten eines Systems. Das Konzept der Generativen

Softwareentwicklung beschreibt hierzu, wie eine automatische Generierung von

Systemvarianten erstellt werden kann. Es gibt im Rahmen der VIBN eine Reihe von

Werkzeugen zur Entwicklung von Simulationsmodellen und Steuerungssoftware. Um

das Engineering von Softwareproduktlinien auf die VIBN anwenden zu können braucht

man zum einen Möglichkeiten zur Realisierung von Variabilität in den Werkzeugen und

zum andern ist zwingend eine Infrastruktur erforderlich, in welcher diese

Softwareentwicklungswerkzeuge integriert werden können. In diesem Artikel wurde

eine Varianteninfrastruktur vorgestellt, die es ermöglicht unterschiedlichste Werkzeuge

zur Entwicklung von Simulationsmodellen und Steuerungssoftware zu erstellen. Ein

wesentliches Augenmerk liegt hierbei auf der Schnittstelle, mit denen diese Werkzeuge

in die Infrastruktur integriert werden können.

41

Acknowledgement

Die vorgestellten Forschungsarbeiten wurden im Rahmen des Förderprojekts Virtuelle

Inbetriebnahme Variantenreicher Systeme (VivaSys) erarbeitet. VivaSys wird mit

Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) unter dem

Förderkennzeichen „03FH085PX2“ gefördert. Die Verantwortung für den Inhalt dieser

Veröffentlichung liegt beim Autor.

Literaturverzeichnis

[CE00] Czarnecki, K.; Eisenecker, U.W.: Generative Programming – Methods, Tools,

and Applications. Addison-Wesley, 2000.

[CM12] Mengi, C.: Automotive Software – Prozesse, Modelle und Variabilität, Shaker Verlag,

Aachen 2012

[Cz05] Czarnecki, K.: Overview of Generative Software Development. In: J.-P. Banâtre

et.al. (Edit.): Unconventional Programming Paradigms (UPP) 2004, Mont SaintMichel,

France, LNCS 3566, 2005.

[CN01] Clements, P.C.; Northrop, L.: Software Product Lines – Practices and Patterns. SEI

Series in Software Engineering, Addison-Wesley, 2001.

[EG06] Richtlinie 2006/42/EG des Europäischen Parlaments und des Rates vom 17. Mai 2006

über Maschinen

[ES04] Eisenecker, U.W.; Schilling, R.: Merkmalmodellierung – Konzepte, Notationen

und Einsatzmöglichkeiten. In: Adelsberg, A.A.; Eicker, S.; Krcmar, H.; Palowski,

J.M.; Pohl, K.; Rombach, D.; Wulf, V. (Hrsg.): Multikonferenz Wirtschaftsinformatik

(MKWI) Band 1: E-Learning: Modelle, Instrumente und Erfahrungen,

Software-Produktlinien, Communities in E-Business. Universität Duisburg-Essen,

Akademische Verlagsanstalt Aka GmbH, 2004.

[GS04] Greenfield, J.; Short, K.: Software Factories – Assembling Applications with Patterns,

Models, Frameworks, and Tools. John Wiley & Sons, 2004.

[HKM13]Arne Haber, Carsten Kolassa, Peter Manhart, Pedram Mir Seyed Nazari, Bernhard

Rumpe and Ina Schaefer.: First-Class Variability Modeling in Matlab / Simulink. In

Proceedings of the Seventh International Workshop on Variability Modelling of

Software-intensive Systems, New York, NY, USA, 2013. ACM

[JW08] J. Weiland: Variantenkonfiguration eingebetter Automotive Software mit Simulink,

Dissertation, Wirtschaftswissenschaftliche Fakultät, Universität Leipzig, Juli 2008

[Wu07] G. Wünsch: Methoden für die virtuelle Inbetriebnahme automatisierter

Produktionssysteme. Herbert Utz Verlag, 2008

42

Re-Engineering Automation Systems asDynamic Software Product Lines∗

Sascha Litya, Johannes Burdekb, Malte Lochaub,Markus Berensc, Andy Schurrb, and Ina Schaeferd

aInstitute for Programming and Reactive Systems, TU BraunschweigbReal-Time Systems Lab, TU Darmstadt

cEckelmann AGdInstitute of Software Engineering and Automotive Informatics, TU Braunschweig

Abstract: Software engineering is an important development task in the automationdomain due to the increasing number of embedded systems applied for controlling var-ious system functions. In general, those automation systems are highly configurable,but share common functionality and engineering artifacts. If the knowledge aboutcommonality and variability is not taken into account, this would result in a separatedevelopment process for each new system without reusing engineering artifacts. Soft-ware product line engineering is a promising approach for the development of highlyconfigurable automation systems explicitly exploiting the knowledge about common-ality and variability. In addition to the specification of the problem space, i.e., allpossible system configurations derivable from a feature model, reusable engineeringartifacts are defined in the solution space by incorporating variability mechanisms. Inthis paper, we describe the re-engineering of an existing family of automation systems,a medical device for a novel radiotherapy, i.e., as a software product line. Accordingto the concepts of software product line engineering, we describe (1) how we createda corresponding feature model for the problem space specification, and (2) how weintegrated variability modeling into existing engineering artifacts. We provide detailsabout our real-world case study and further explain the adaptation of its re-engineeredversion as dynamic software product line allowing for re-configuration at runtime.

1 Introduction

Nowadays automation systems comprise increasing functionality controlled by softwareto fulfill their purposes. Thus, software engineering is an important task in the design anddevelopment process of automation systems [Vya13]. In addition, the complexity of thecorresponding software system, as well as the number of potential application domains isconstantly growing, resulting in highly configurable automation systems. Those systemsusually comprise a common core functionality and differ in predefined features offeringmany potentials for engineering artifacts reuse. However, automation systems are often

∗This work was partially supported by the DFG (German Research Foundation) under the Priority ProgrammeSPP1593: Design For Future – Managed Software Evolution.

43

developed one-by-one, without systematic exploitation of reuse potentials leading to inef-ficient development practices.

Software product line engineering (SPLE) [PBL05] is a promising approach to cope withthis deficiency. A software product line (SPL) represents a family of similar softwarevariants with explicit specification of common and variable parts by means of featurescorresponding to customer-visible system properties. In this regard, features (1) are con-figuration parameters from the problem space, and (2) refer to sets of reusable engineeringartifacts within the solution space to derive implementation variants for a respective sys-tem configuration [CE00]. Concerning the problem space, feature modeling [KCH+90] isfrequently used to graphically define the set of supported features of the SPL together withtheir dependencies in a tree-like structure. Each feature selection satisfying the featuremodel constraints constitutes a valid configuration corresponding to a specific implemen-tation variant. Concerning the solution space, various variability modeling techniques havebeen proposed to specify reusable engineering artifacts parameterized over features at dif-ferent levels of abstraction [SRC+12]. However, until now only few experience reportsexist, describing the application of SPLE techniques to the automation domain.

In this paper, we present the re-engineering of a real-world case study from the automationdomain provided by our industrial partner Eckelmann AG1 as (dynamic) SPL, i.e., anSPL which is reconfigurable at runtime. The case study comprises a medical device for anovel radiotherapy and we provide details about (1) how we conducted domain analysis toderive a feature model, and (2) how we enhanced the domain-specific modeling languageused for solution space modeling with variability information. During re-engineering,we further identified certain system properties adaptable at runtime, constituting systemre-configuration characteristics leading to a dynamic SPL (DSPL) [HHPS08]. We usethe re-engineered case study for the evaluation of our existing model-based SPL testingstrategies, e.g., for family-based product-line test-suite generation [LBL+14], as well asfor our newly developed techniques w.r.t. scalability and gains in efficiency in the future.

The paper is structured as follows. Sect. 2 describes our real-world case study. The re-engineering process is presented in Sect. 3. In Sect. 4, related work on the application ofSPLE techniques to the automation domain is discussed, and Sect. 5 concludes the paper.

2 Automation Engineering Case Study: Device Control Unit

Our case study comprises an embedded software system constituting the control softwarefor a complex automation system for a novel radiotherapy as part of the Heidelberg Ion-Beam Therapy Center 2 (HIT), designed and developed by Eckelmann AG. In contrastto conventional radiotherapy with gamma rays, the HIT provides an alternative treatmentby irradiating tumors with heavy ion beams allowing for a more precise beam position-ing and irradiation of deeply positioned tumors. An overview of the HIT architecture isshown in Figure 1(a) comprising (1) an area for ion beam creation including a synchrotron

1http://www.eckelmann.de/en2http://www.klinikum.uni-heidelberg.de/index.php?id=113005&L=1

44

Area 2: Therapy Area 1: Beam Accelerator

Ion Sources

Synchrotron

DCU

DCU DCU

DCU

DCU

DCU

DCU

DCU

Treatment Room

Treatment Room

Treatment Room

(Gantry)

…

(a) HIT Architecture

…

… DCU1 DCU2 DCUn

Timing

Master Master

Control

Device Device Device

(b) Beam Accelerator Software Architecture

Figure 1: Overview HIT and DCU Case Study [BLL+14]

and ion sources, and (2) an area for the therapy of patients containing different kinds oftreatment rooms. For ion beam creation, i.e., for automatic beam acceleration and beammeasurement, magnets and several E/E devices are required. In the case study, we focuson the embedded software system responsible for controlling those devices placed aroundthe synchrotron (cf. Figure 1(a)), called Device Control Units (DCU). Depending on itscontrolled device, a DCU has a specific type resulting in eight different DCU types respon-sible, e.g., for controlling the angle position and intensity of a magnet adjusting the ionbeam. An overview of the beam accelerator software architecture is shown in Figure 1(b).All DCUs around the synchrotron are installed in a master-slave architecture controlled byanother embedded system, i.e., a master control, and a DCU representing the timing masterfor synchronization. For beam creation, the master control initiates a control cycle, whereeach DCU receives the set of its type-specific parameters, the set of beam creation-specificparameters, e.g., the angle and intensity of a controlled magnet, and the current systemoperation mode. This DCU parameterization is, up to a certain extent, adaptable for everysubsequent control cycle throughout the entire DCU life-cycle. During a control cycle, aDCU updates the parameters of its controlled device, and supervises its ongoing opera-tion. The runtime behavior of a DCU is determined on its operation mode. For instance,in the manual mode, a DCU is fully maintainable, e.g., for calibration purposes, whereasin the experiment mode only a subset of (re-)configurable parameters are adaptable. Thecurrent operation mode may restrict parameter changes during runtime for safety reasons.For instance, in the therapy mode, where a DCU executes a predefined procedure for beamcreation, changing a parameter can result in harmful effects for a patient.

Summarizing, the DCU case study represents a family of similar software systems in-corporating common functionality and well-defined differences based on their applicationtypes and further parameters for a fine-grained DCU configuration.

3 Re-Engineering the DCU Case Study as Software Product Line

In order to exploit the commonality and variability among similar variants of a familyof software systems, such as the different DCU types, SPLE fosters a systematic reuseof engineering artifacts to reduce development time and costs of complex software sys-

45

tems [PBL05]. Hence, we use established techniques of SPLE to re-engineer the DCUas SPL and take advantage of reusing engineering artifacts among system variants. SPLEconsists of two phases, namely the domain engineering and the application engineering.Domain engineering comprises the domain analysis, i.e., the identification of features andtheir dependencies, as well as the development of reusable engineering artifacts withinthe solution space. During application engineering, engineering artifacts are assembledto derive a software system variant according to the selection of desired features within aproduct configuration. In the following, we describe the results of both phases carried outfor the DCU case study.

For re-engineering the DCU, we applied the extractive SPLE approach, i.e., we inte-grated all members of the existing family of similar DCU variants into a newly createdSPL [PBL05]. Therefore, we start with the domain analysis of the existing DCU systemin order to derive relevant configuration parameters constituting features to capture the in-herent commonality and variability within DCU variants. On this basis, the set of existingengineering artifacts is investigated to identify reusable artifacts. As some DCU variantsare capable to re-configure at runtime, we further categorized the overall set of featuresinto statically configurable and dynamically re-configurable features. For the latter, wefurther identified re-configuration restrictions to specify the valid re-configuration behav-ior of the DCU. We present the specification of the problem space, and the solution spacein the next paragraphs. In addition, our extension of the DCU SPL as DSPL is explained.

Specification of the Problem Space: For the domain analysis of the DCU case study, wemade use of different sources of information provided by our industrial partner. We use thesystem documentation as well as existing engineering artifacts, i.e., the source code anddesign models by means of state charts. In order to validate our analysis, we established afeedback loop by interviewing the responsible developers at Eckelmann AG.

Based on the set of relevant configuration parameters identified during domain analysis,we specified the problem space of the DCU SPL case study using extended feature mod-els [PBN+11]. Originally, a feature model [KCH+90] organizes boolean features togetherwith their dependencies in a graphical, tree-like structure as shown in Figure 2. Extendedfeature models [PBN+11] enrich feature models by non-boolean feature attributes cor-responding to advanced measurable properties of features such as integer values. Thisextension of feature models was required for the DCU case study in order to representnon-boolean configuration choices such as timeout values.

In Figure 2, an extract of the DCU feature model is shown comprising 47 features and5 requires- and excludes-constraints. Each DCU has an obligatory type represented by amandatory feature. The set of possible operation types is collected in an alternative group,thus, ensuring the selection of a definite type for each feature, e.g., type Z denotes thetiming master DCU. According to the DCU type, also the available DCU operation modesat runtime are organized in an alternative group. For adding fine-grained variable imple-mentation parameters into the feature model, e.g., the DCU master parameters and typeparameters, corresponding sub features were introduced. In particular, boolean implemen-tation parameters correspond to optional features, e.g., ErrorMonEn which is responsiblefor enabling the error monitoring at runtime. For non-boolean implementation parameters,we use features with attributes for configuring their parameter values. In order to keep the

46

Device Control Unit

SD

Device Controller Manual

Quality Assurance

Therapy

Standby

Idle

Version

Checksum

Timing Master Parameter

EnableSyncSupplyFrequence

EnableGenRTBMasterClock

Device Control Parameter

EnableSwitchOn

EnableShutdown

BeamRequestTakeOverRefValues

DelayTimeActivate

delay: [0,100]

DelayTimeFeedback

delay: [0,100]

TimeoutFeedback

timeout: [0,100]

RefValueTHoldMax

delay [0,100] AddRtbDelayTime

delay : [0,100]

ErrorMonEn

LowCurrentTimer

timer: [0, 100]

Mode 0

Mode 1

Mode 2

Mode 3

Mode 4

DCU Type Parameter

DCU Master Parameter

Type

b b b

b b

MeasuringMode

RtbTimingEn

Keys

Mandatory

Optional

Alternative

Name

Z

T

TS

R

RB

b

RK b

Ramped

P

b Operation Mode

<req>

Experiment

Adjustment

<req>

b Device Control

<req>

<req>

<excl>

<req>

<excl>

Figure 2: Extract of DCU Feature Model [BLL+14]

size of the resulting configuration space graspable, we limited the possible attribute valuesto a predefined range according to the DCU documentation. For instance, the attributedelay (in ms) of the feature DelayTimeActivate specifies a delay for the activation of thecontrolled device and is, therefore, limited to integer values between 0 − 100 . To guar-antee type-specific parameters to be configured only for the respective types, we furtheradded require edges, e.g., the selection of Z requires the configuration of its correspondingtiming master parameters and vice versa.

Table 1: Statistics of DCU Feature Modeling#Features #Non-Boolean Features #Constraints #Products

DCU (extract) 47 6 5 ca. 80, 000DCU (full) 321 220 40 >> 100, 000

In Table 1, we summarize statistics of the DCU feature modeling. The full DCU fea-ture model comprises 321 features, where 220 features are non-boolean features with at-tributes. The model further comprises 40 cross-tree constraints in order to avoid invalidDCU variants. Unfortunately, current off-the-shelf feature model analysis tools, such asFeatureIDE3, are not able to deliver the precise number of valid product configurationsfor feature models of that size. The presented DCU feature model extract comprising 47features comprises of an approximately number of 80, 000 valid DCU variants. However,only a small subset of those possible variants actually occurs for beam creation at the HIT,thus, indicating further potentials for refining the feature model.

3http://wwwiti.cs.uni-magdeburg.de/iti_db/research/featureide/

47

Specification of the Solution Space: For the specification of reusable development arti-facts within the solution space, the set of existing DCU implementation artifacts has beenconsidered. Therefore, respective features identified within the problem space during do-main analysis are mapped onto composable design and implementation artifacts withinthe solution space. Based on this tracing between problem space features and solutionspace artifacts, an automated derivation of DCU variants for each valid feature selection isachievable by assembling the respective engineering artifacts. Recent variability modelingconcepts for the solution space are classified as follows [SRC+12]:

• Annotative – All model variants are captured in one superimposed model, whoseelements are annotated by propositional formulae over feature variables to associateproduct configurations with solution space artifacts.• Transformational – All model variants are derived from a predefined core model

based on basic transformation operations, i.e., additions/removals of model ele-ments, e.g., the delta modeling approach.• Compositional – All model variants are derived by composing modular model frag-

ments, each being related to (sets of) features.

Annotative techniques focus on the commonality between variants supporting family-based analyses, e.g., for efficient model-based SPL test suite generation [LBL+14]. Incontrast, transformational techniques make explicit the differences, thus, supporting in-cremental SPL analysis approaches inspired by change impact analysis, such as regressiontesting [LLL+14]. Compositional techniques make use of modularization concepts interms of separation of feature concerns [AK09].

As mentioned in Sect. 1, our research focuses on model-based SPL testing strategies, e.g.,on family-based product-line test-suite generation [LBL+14], where a required test cover-age of all variants of an SPL can be achieved efficiently, without considering every particu-lar variant. In order to apply this technique also to the DCU case study, we pursued the an-notative variability modeling approach for the creation of a so-called 150%-representationincorporating all DCU variants. As the DCU software has been originally implementedusing a model-based development approach, we built our 150%-representation using thedomain-specific behavioral modeling language, sequential function tables (SFT), providedby the Eckelmann AG. SFT constitutes a rich UML-like state chart dialect visualizing la-beled state-transition graphs in a tabular representation. In an SFT model, columns referto states and rows contain transitions between states labeled with complex [C]/A-rules,i.e., conditions ([C]) defining transition guards and actions (A) denoting transition effectswhen triggered. For applying SFTs as an annotative variability-modeling language, states,transitions, as well as entire SFTs are enriched with annotations by means of propositionalformulae over feature parameters, denoting presence conditions of the respective modelelement. During domain analysis, we first examined similarities between the existingtype-specific SFT model variants in order to identify the high-level common and variablebehaviors of the control software among the eight DCU types. As next step, we comparedthe set of transition sequences of the different SFT variants w.r.t. their defined transitionsequences in detail in order to merge common behaviors on a fine-grained level.

As a result, we obtained a superimposed 150%-SFT model and further identified sevencoherent sub-parts shared by every DCU type as illustrated in Figure 3. Amongst others,

48

Type P

Type R

Type RB

Type RK Type SD

Type T

Type TS

TypeZ

150% SFT

Figure 3: Re-engineering of SFT Models as 150% SFT Model

each DCU SFT defines a sub-machine dedicated to error handling, a sub-machine forDCU calibration in the manual service mode, as well as a sub-machine for beam cyclehandling executing a predefined control procedure. The overall 150%-SFT comprises 65states, 96 guards, and 643 transitions. In contrast, the eight type-specific SFTs contain onaverage 40 states, 54 transition guards, and 295 transitions (cf. Table 2). As can be seen, asignificant amount of reuse of state-machine fragments among the different SFT variantshas been obtained by merging similar sub-parts. Each original type-specific SFT modelis projectable from the 150%-SFT by removing those elements whose annotated presenceconditions do not satisfy the respective feature configuration of that type.

Table 2: Statistics of SFT Modeling#States (Column) #Guards (Row) #Transitions

Type-specific SFT ∅40 ∅54 ∅295150% SFT 65 96 643

DCU as a Dynamic Software Product Line: Additionally, we identified two further cru-cial characteristics of the DCU SPL, (1) certain features have to be selected in a pre-defined order, and (2) the feature selection may change at runtime. In order to addressthese characteristics, we specified a staged-configuration process imposing a step-wise(re-)configuration of features [CHU04]. Features are assigned to configuration stages, forwhich a total order is defined which is enforced during the configuration process. Eachstage corresponds to a so-called binding time denoting a particular point in time duringapplication engineering. We further distinguish between stages related to static featuresand those related to dynamic features. Static features constitute (pre-)configuration deci-sions and are immutable after being configured, such as the type of a DCU. In contrast,dynamic features are (re-)configurable, e.g., to allow for runtime adaptation, such as theoperation mode switches. Figure 4(a) shows the four configuration stages which we iden-tified for the DCU staged configuration. Pre-Configuration Time and Installation Timedenote static binding times, therefore, their ordering is fixed. In contrast, Activation Time

49

Pre-Configuration

Time

Installation

Time

Static Binding Times

Dynamic Binding Times

Activation

Time

Runtime

(a) DCU Binding Times

Checksum

Version

DCU Type Parameter

Timing Master Parameter

EnableSyncSupplyFrequence

EnableGenRTBMasterClock

EnableSwitchOn

EnableShutdown

BeamRequestTakeOverRefValues

DelayTimeActivate

delay: [0,100]

DelayTimeFeedback

delay: [0,100] Device Control Parameter

TimeoutFeedback

timeout: [0,100]

RefValueTHoldMax

delay [0,100]

Name

…

{Activation Time}

{Activation Time}

{Installation Time}

{Activation Time}

{Installation Time}

{Activation Time,

Runtime} {Activation Time,

Runtime}

{Activation Time,

Runtime}

{Activation Time,

Runtime}

{Activation Time,

Runtime}

{Activation Time,

Runtime}

{Activation Time,

Runtime}

{Activation Time,

Runtime}

{Activation Time,

Runtime}

{Activation Time,

Runtime}

{Activation Time,

Runtime}

{Activation Time,

Runtime}

{Activation Time,

Runtime}

(b) DCU Feature Model with Binding Time Annotations

Figure 4: Definition and Integration of Binding Times [BLL+14]

and Runtime are dynamic binding times, thus, they maybe arbitrary re-entered for adaptingfeature selections, e.g., for changing the operation mode. In the following, we show howwe represent configuration stages and binding times as part of the problem and solutionspace specification for the DCU DSPL.

Concerning the problem space, recent feature modeling approaches do not incorporatebinding time information. Thus, we extended feature models by adding binding timeannotations to features and attributes [BLL+14]. An extract of the DCU feature modelenriched with binding time annotations is shown in Figure 4(b). For instance, Checksum is(re-)configurable during Activation Time, whereas TimeoutFeedback may be (re-)configur-ed at Activation Time and Runtime. The latter example illustrates that our extension is alsocapable of handling multiple binding times for features and attributes as this case fre-quently occurs in the DCU case study. In this regard, Name may be even (re-)configuredat any stage, indicated by the absence of binding time annotations.

Besides constraints on features, such as requires- and excludes-constraints, we identifieda new class of constraints required by the staged-configuration process, so called com-plex binding time constraints. These constraints restrict staged configuration in order toexpress dependencies between features, attributes, and/or binding times. For instance,(DelayT imeFeedback.bt = AT )⇔ (TimeoutFeedback.bt = AT ) indicates that con-figuring DelayTimeFeedback at Activation Time (AT) requires the configuration of Time-outFeedback in the same stage and vice versa to ensure that both are configured duringActivation Time. In order to express such constraints, we developed a complex constraintlanguage in previous work [BLL+14].

Finally, we introduced the concept of a reconfiguration automaton controlling the re-configuration behavior of the DSPL by means of valid configuration changes throughoutthe DCU life-cycle. For instance, switching from one mode to another, e.g., from Exper-iment mode to Therapy mode, always requires an intermediate mode switch into the Idle

50

mode. The reconfiguration automaton ensures a correct (re-)configuration considering re-configuration behavior that is aware of binding times and binding time constraints.

Discussion: One of the major challenges during the re-engineering process has been thederivation of the 150% model by manually merging existing model variants. For the ex-tractive SPLE approach become feasible in practice, this task requires tool support, e.g.,by means of a semi-automatic n-way merge tool, that takes the feature model constraintsinto account. Such an automated 150%-model construction would be very beneficial forour industrial partner as it allows for applying SPL technologies also to existing familiesof similar systems, e.g., efficient SPL-testing strategies [LBL+14].

4 Related Work

We discuss related work w.r.t. the application of SPLE techniques to the automation do-main. In [FDG08], Froschauer et al. propose the application of variability models for themanagement of the automation system life-cycle. They apply DOPLER, i.e., a decision-oriented variability modeling approach, for the definition of reusable artifacts and their(re-)configuration. In contrast to DOPLER, we applied feature-oriented variability mod-eling for the DCU re-engineering. Maga and Jazdi [MJ10] give an overview of variabilitymodeling in the automation domain. In addition, they propose a variability modeling ap-proach on the basis of SySML. In [KPIT14], Kowal et al. present a multi-perspectivemodeling approach for evolving automation systems. Based on delta modeling, the vari-ability as well as the evolution of the different perspectives and their models is captured bythe same approach resulting in an integrated development approach. In contrast to that, weapplied annotative variability modeling and further focus on SFT as modeling language.Holthusen et al. [HWL+14] propose family mining for function block diagrams. By com-paring all variant-specific diagrams to each other, the commonality and variability betweenthe diagrams are determined resulting in a corresponding family model, i.e., a 150% func-tion block diagram. The definition of the family model is done semi-automatic, whereasour 150%-SFT was created manually and again we focus on SFT as modeling language.

5 Conclusion

In this paper, we presented the re-engineering of the DCU case study provided by ourindustrial partner as (D)SPL. We used an extractive SPL development approach, and ex-tended existing SPL modeling techniques to meet the special requirements of the DCUcase study, such as the explicit representation of binding times and complex binding timeconstraints. The result is a guidance, how to re-engineer complex software systems fromthe automation domain as (D)SPL showing respective characteristics. However, as the re-engineering was done manually, tool support, e.g., for automated n-way model merging,is much needed in order to be more practically applicable in industry. We use the re-en-gineered case study for the evaluation of our existing and newly developed model-based

51

SPL testing techniques w.r.t. scalability and gains in efficiency in the future.

References

[AK09] S. Apel and C. Kastner. An Overview of Feature-Oriented Software Development.Journal of Object Technology, 8(5):49–84, 2009.

[BLL+14] J. Burdek, S. Lity, M. Lochau, M. Berens, U. Goltz, and A. Schurr. Staged Configura-tion of Dynamic Software Product Lines with Complex Binding Time Constraints. InVaMoS ’14, pages 16:1–16:8. ACM, 2014.

[CE00] K. Czarnecki and U. W. Eisenecker. Generative Programming: Methods, Tools, andApplications. ACM Press/Addison-Wesley Publishing Co., 2000.

[CHU04] Krzysztof Czarnecki, Simon Helsen, and Eisenecker Ulrich. Staged Configuration Us-ing Feature Models. In SPLC’04, pages 266–283, 2004.

[FDG08] R. Froschauer, D. Dhungana, and P. Grunbacher. Managing the Life-cycle of IndustrialAutomation Systems with Product Line Variability Models. In EUROMICRO, 2008.

[HHPS08] S. Hallsteinsen, M. Hinchey, Sooyong Park, and K. Schmid. Dynamic Software ProductLines. Computer, 41:93–95, 2008.

[HWL+14] S. Holthusen, D. Wille, C. Legat, S. Beddig, I. Schaefer, and B. Vogel-Heuser. FamilyModel Mining for Function Block Diagrams in Automation Software. In SPLC ’14,pages 36–43. ACM, 2014.

[KCH+90] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Feature-OrientedDomain Analysis (FODA) Feasibility Study. Technical report, CMU - SEI, 1990.

[KPIT14] M. Kowal, C. Prehofer, I.Schaefer, and M. Tribastone. Model-based Development andPerformance Analysis for Evolving Manufacturing Systems. at - Automatisierungstech-nik, 62(11):794–802, 2014.

[LBL+14] M. Lochau, J. Burdek, S. Lity, M. Hagner, C. Legat, U. Goltz, and A. Schurr. ApplyingModel-based Software Product Line Testing Approaches to the Automation Engineer-ing Domain. at - Automatisierungstechnik, 62(11):771–780, 2014.

[LLL+14] M. Lochau, S. Lity, R. Lachmann, I. Schaefer, and U. Goltz. Delta-oriented Model-based Integration Testing of Large-scale Systems. in JSS, 91(0):63 – 84, 2014.

[MJ10] C. Maga and N. Jazdi. An Approach for Modeling Variants of Industrial AutomationSystems. In AQTR, pages 1 – 6, 2010.

[PBL05] K. Pohl, G. Bockle, and F. J. van der Linden. Software Product Line Engineering:Foundations, Principles and Techniques. Springer, 2005.

[PBN+11] L.Teixeira Passos, T. Berger, M. Novakovic, K. Czarnecki, Y. Xiong, and A. Wasowski.A Study of Non-Boolean Constraints in Variability Models of an Embedded OperatingSystem. In SPLC’11, pages 21–28, 2011.

[SRC+12] I. Schaefer, R. Rabiser, D. Clarke, L. Bettini, D. Benavides, G. Botterweck, A. Pathak,S. Trujillo, and K. Villela. Software Diversity: State of the Art and Perspectives. Inter-national Journal on Software Tools for Technology Transfer, 14(5):477–495, 2012.

[Vya13] V. Vyatkin. Software Engineering in Factory and Energy Automation: State of the ArtReview. IEEE Transactions on Industrial Informatics, 2013.

52

A Methodology for Hierarchical MultidisciplinaryModeling and Analysis of Mechatronic Systems

Benjamin Mensing and Ina Schaefer

TU Braunschweig38106 Braunschweig

[email protected]@tu-braunschweig.de

Abstract: Mechatronic systems as a combination of the disciplines mechanical engi-neering, electrical engineering, and software engineering offer extensive new capabil-ities for systems design. However, this class of systems also introduces massive com-plexity due to size and heterogeneity. Existing development approaches either onlyhandle this complexity for single disciplines such that they lack support for cross-discipline properties, or require the involved disciplines to utilize completely newmodeling formalisms ignoring widely accepted formalisms and tools within this dis-cipline. In this work, we propose a methodology to enable analyses of non-functionalcross-discipline properties. Therefore, existing discipline-specific models and meth-ods are reused by interfacing them to different abstract models of the system, depend-ing on the type of property to be examined. These abstractions of domain-specificmodels are integrated into a holistic development process, both reducing complexityand enabling overall analyses of cross-discipline properties.

1 Introduction

Interdisciplinary development is crucial both in research and industry since most devel-opment projects span across several participating disciplines. Mechatronic systems as acombination of the disciplines mechanical engineering, electrical engineering, and soft-ware engineering [Bis06] constitute a class of systems which requires interdisciplinarydevelopment. Though mechatronic systems offer extensive new capabilities for systemsdesign, they also introduce complexity which cannot be handled using single-disciplinedevelopment approaches. The interdisciplinary character of mechatronic systems presentsnew challenges due to diverse discipline-specific knowledge, methods, and understand-ing. Subsystems are developed using discipline-specific methods and validated againsttheir requirements. However, especially regarding non-functional properties like time, en-ergy consumption etc., the complete system does not necessarily meet the overall systemrequirements, as no overall analyses across disciplines are conducted. Regarding opti-mizations on system level, the same problem exists since optimizing subsystems does nottake discipline interdependencies into account. In order to develop a consistent system sat-isfying the top-level requirements, an integrated cross-disciplinary approach is necessaryfor models and analyses covering the whole system over the complete design process.

53

To achieve this goal, existing approaches are not sufficient since they are either too in-formal for expressive analyses or introduce completely new formalisms which hamperwide acceptance. Thus, in this work, we propose a novel hierarchical approach integratingexisting discipline-specific formalisms into a more abstract overall model. A consistentabstract model for mechatronic systems with defined interfaces to domain-specific for-malisms enables holistic modeling, analyzing, and optimizing early in the developmentprocess. Requirements are integrated with the system models to enable traceability. Thisfacilitates validation of properties using the models such that compliance to non-functionalrequirements can be checked early and optimization potential can be identified.

In our methodology, we define three layers of models which are interconnected by definedrelations. The most abstract layer, the High-Level Model (HLM), captures the require-ments and their refinement to validable units. Contrary to the other two layers, the HLMcovers the problem domain. For the solution domain, the Abstract-Level Model (ALM)and the Detail-Level Model (DLM) represent the system on two different levels of abstrac-tion, connected by well-defined interfaces. In the DLM, established discipline-specificmodels are used to model the system on a detailed level. For validation of system-levelproperties, the discipline-specific models are abstracted and combined to an abstract modelfor checking overall properties. The abstraction is parameterized in two ways. First, theabstract model’s formalism depends on the type of property to be checked. Second, tohandle the system’s complexity, data irrelevant for the examined property is eliminated.

The remainder of this paper is organized as follows: In Section 2, we give a brief overviewof relevant related work. A new methodology for modeling both the problem and solutiondomain of mechatronic systems is presented in Section 3. Section 4 shows how thesemodels are used to examine non-functional requirements on a cross-discipline level. Anapplication of the presented methodology in a case study is presented in Section 5. Aconclusion and an outlook on future research directions are given in Section 6.

2 Related Work

Existing approaches for mechatronic systems, e.g. [BTG04] and work collected in [E+07],bring together the disciplines by proposing new modeling languages. Since each domainalready developed its own discipline-specific methods and tools, a new language alwaysintroduces the obstacle of introducing it into an existing environment. Another class ofapproaches uses the Systems Modeling Language (OMG SysML) [OMG06] as an over-all model of the system. Using specific profiles, the information of each participatingdiscipline can be captured in respective SysML diagrams, enabling different discipline-specific views on the system. Bassi et al. [BSBF11] present a SysML-based approach andintroduce different hierarchical levels. Their relation, however, is not formally defined.Similarly, Barbieri et al. [BFB14] propose an approach which integrates discipline-specificmodels into a SysML model including analyses. However, this approach lacks a systematicprocedure for the integration of discipline-specific models. Kernschmidt et al. [KVH13]enrich SysML models such that components from different disciplines can be connectedusing typed ports and connectors.

54

3 Hierarchical Model for Mechatronic Systems

To cope with both complexity and discipline boundaries in mechatronic systems, wepresent an approach to model and analyze systems in a hierarchical manner. In this section,the different layers of our approach are introduced as well as their constituent parts andrelations. A visualization of the general idea of our approach is depicted in Figure 1. Thescheme is sectioned into one model for requirements on the left-hand side (High-LevelModel, HLM) and two models for different system artefacts on the right-hand side, theAbstract-Level Model (ALM) and the Detail-Level Model (DLM). The requirements arerefined from general requirements at top to detailed and validable requirements furtherdown. The system models in the right division of the figure are further sectioned hori-zontally and vertically. The horizontal separation divides the ALM and DLM accordingto their different level of detail. The vertical separation distinguishes models for behaviorand structure. The arrows indicate interfaces between the levels, which is discussed indetail in Section 4.

Figure 1: Overview of the approach

As a first step in the design process, requirements have to be captured to cover the prob-lem domain, which is done using the High-Level Model. Beside the system’s functionality,the non-functional properties, e.g., timing constraints, performance, energy consumption,or reliability, are an essential aspect for a product’s quality [CdPL09]. These have to beclassified and represented in an organized structure, e.g., in a model-based manner. TheUnified Modeling Language (UML) [UML11] as a widespread modeling formalism pro-vides – among other diagram types – Use Case Diagrams to model requirements. How-ever, Use Case Diagrams are an informal representation of requirements and not suitableto model non-functional requirements. This gap is closed by SysML Requirement Dia-grams [OMG06], which can be used to capture non-functional requirements in a semi-formal representation.

For the HLM, we adapted the SysML Requirement Model Metamodel to integrate it withour approach (see Figure 2). A Requirement Diagram here essentially consists of a setof requirements, traces between diagram elements and test cases. The model element forrequirements is extended such that at first, a distinction is made whether a requirementis functional or non-functional. For non-functional requirements, we extend the classical

55

Figure 2: Metamodel for Requirement Diagram

SysML metamodel such that value and unit are assigned to requirements to indicate athreshold for when the requirement is fulfilled. Moreover, we further split non-functionalrequirements based on the class of property they represent, i.e. time, energy, and reliability.This can easily be extended to other property types in the future.

A trace basically connects two model elements in SysML diagrams. For our approach,three types of traces are appropriate: A Satisfy-relationship indicates that an element froma model of the solution domain fulfills the requirement it is attached to. These traceabilityrelationships are added later in the development process as soon as system models are cre-ated and indicate allocations of requirements to disciplines. Based on these relationships,different analyses can be performed. Since requirements are abstract at the beginning ofthe development process, a derivation is necessary to obtain validable requirements. Forthe validation, the requirements are refined until they can be allocated to one distinct prop-erty class, e.g., a timing property. For a structured notation, the DeriveReqt-relationshipis used. Using this relation, a graph structure is constructed while refining requirements.So far, this is done manually, but for a systematic refinement of non-functional require-ments, work like [MCN92] can be used. The Verifiy-trace attaches test cases to require-ment to indicate how a requirement can be checked. Constraints can be expressed by theConstraint-relationship.

After requirements are refined, discipline-specific models for the Detail-Level Model arecreated for each physical component of the system. For this task, experts in the individ-ual disciplines build their models using established modeling formalisms. Thus, existingknow-how can be used for this approach as well as widely used tools for analyses or codegeneration. Moreover, this enables the reuse of existing models for systems engineering.

Depending on the discipline and the component’s objective, a suitable modeling formal-ism is chosen for both the behavior and structure model. For the software discipline, wechose UML State Machines and Class Diagrams, though the approach is not limited tothese formalisms. In the mechanical discipline, Computer-Aided Design (CAD) is theprevalent modeling formalism. Thus, we use CAD on the discipline-specific level for

56

the mechanical view. For the electrical discipline, electronic schematics are employed tomodel electricity-related properties of the system. These design artefacts of the DLM arelinked to requirements of the HLM using the satisfy-relation for requirements traceability.

To analyze a mechatronic system on an abstract and cross-discipline level, the Abstract-Level Model is introduced. Generally, the ALM consists of models of different formalisms,each corresponding to the type of the property in focus. The ALM is consequently a setof different models, one for each property type to be checked. If, for example, a timeproperty shall be checked, the corresponding modeling formalism in the ALM are TimedAutomata [AD94]. If also energy properties shall be validated, the ALM contains a modelsuitable to analyze energy properties, in our case, Weighted Timed Automata [BFL+08].

The ALM, however, is not created manually, but abstracted from discipline-specific mod-els in the DLM. During this abstraction process, artefacts from the DLM are transformedto model elements in the ALM. Thus, two relations exist for model elements in the ALM:First, these can be related to elements in the DLM. Second, by transitivity, relations to re-quirements and test cases in the HLM exist. The relation among elements from the HLMand the ALM is essential for all further validation and optimization tasks, since it indicatesthe link between problem and solution domain.

4 Analysis-Workflow

An essential part of our approach is the dependency between abstract and detailed models,i.e., the abstraction of the discipline-specific models in the DLM to the cross-disciplinemodels in the ALM. The discipline-specific models exhibit precise realization details ofcomponents and are not directly suitable for holistic analyses on system level due to bothinconsistent formalisms and complexity. Thus, a translation between these formalisms isnecessary as well as an abstraction to cope with the system’s complexity. Previous to theanalysis of a property on the abstract model, four steps have to be done:

Step 1: Identify the leading discipline

Depending on the type of property to be validated, the adequate type of formalism of themodel in the ALM varies. To choose the right formalism, we utilize the observation thatfor each type of property, one discipline has a leading role. For timing properties, the sys-tem’s behavior is pivotal, thus, the software influences this type of properties essentially.Contrarily, for structure-related properties like manufacturing costs, the actual construc-tion and, therefore, the mechanical discipline affects the property. We call the respectivediscipline the leading discipline. It has to be identified only once for each property type.For types like timing or energy, the leading discipline is already appointed.

Step 2: Generate a frame for the abstract model

For each property type and its leading discipline, exactly one formalism in the ALM isused. Since the leading discipline has the main influence on the respective property, itis used to generate a frame which is later enriched with additional information collectedfrom the other disciplines’ models. To generate a frame for timing properties, the behavior

57

model of the software domain is taken as a basis. For timing behavior, we use UML StateMachines in the DLM and generate Timed Automata in the ALM using the technique byDamm and Olderog [DO02], which is essentially a semantics for State Machines expressedin Timed Automata. Generally, the formalisms in the ALM solely focus on the type ofproperty to be considered in order to represent a generic cross-discipline model.

Step 3: Minimize the abstract model

The frame generated in step 2 only depends on the leading discipline’s models, thus, theabstract model contains information irrelevant for the considered properties. Dependingon the formalism used for the abstract model, different techniques for minimization canbe taken into account. For Timed Automata, abstraction refinement [DKL07] can be used.The objective is to reduce the abstract model such that only those parts relevant for theproperty remain, e.g., by slicing control and clock dependencies.

Step 4: Annotate the abstract model

Thereafter, the abstract model only contains information from the leading discipline. Tointegrate the detailed discipline-specific models, we use so-called interface blocks to an-notate the abstract model with, e.g., time values. The basic idea rests upon the conceptof multi-pole theory, a mathematical characterization of energy conversion mainly in me-chanical parts [Web05]. These conversions usually relate effort and flow as physical pa-rameters, but are generalized in our approach to mathematically relate parameters of dif-ferent types. Since some disciplines are information-centric (e.g. software) while othersare energy-centric (e.g. mechanical engineering), a similar characterization of the con-version is used. A graphical representation of an interface block is depicted in Figure 3.Generally, an interface block is defined as a tuple 〈−→i1 ,

−→i2 ,−→o1,−→o2, f1, f2〉. The vectors −→i1

and −→o1 represent input, respectively output values of the abstract model. Analogously, −→i2and −→o2 represent inputs and outputs of the detailed model. In many cases, the detailedmodel only yields inputs while the abstract model only needs output, hence−→i1 and−→o2 maybe the zero vector. The core of an interface block are the functions f1 and f2, where f1defines how −→o1 is computed from the given inputs. For the output vector −→o2 , the same isdone by f2. Interface blocks are collected in a repository to conveniently use them for themanual connection of detailed and abstract models. For different physical components,interface blocks can be predefined in a generic manner such that they are reusable in dif-ferent development projects. Moreover, since our approach focuses on early developmentstages, interface blocks can also be defined with preliminary expert estimations and laterbe refined.

Figure 3: Cross-Disciplinary Interface Block

58

5 Case Study

To show the application of the presented approach, a small real-world case study is shown.For a fully automated coffee machine as an example for a simple mechatronic system, thecorresponding models both in the problem and solution domain are created. These modelsare subsequently analyzed regarding exemplary timing requirements. For this example,requirements for the Medion MD 42655 fully automated coffee machine were modeled.After that, the device was dismantled and each component was modeled using the appro-priate domain-specific formalism. Following the presented approach, an abstract model forthe validation of timing properties was constructed from the individual detailed models. Avalidation of selected timing properties was carried out using the captured requirements.

Figure 4: Example for Requirement Diagram

As a first step in the development process, the requirements diagram is created. An excerptwith an exemplary timing property is shown in Figure 4. From the top-level requirement,a non-functional requirement stating the maximum time to brew a cup of coffee is derived.At this place, the intended value of 90 seconds is captured. The requirement is furtherrefined to lower-level requirements for the individual steps necessary to produce a cup ofcoffee. For the purpose of validating the requirement, a test case is attached, including aformula in Timed Computation Tree Logic (TCTL) stating that the time between the buttonis pressed and the machine is ready again is less than 90 seconds. The test case is attachedto the higher-level requirements, as the validation is performed on the discipline-crossinglevel instead of checking requirements on the discipline-specific level.

The static structure of the system is then defined using a SysML Block Definition Diagram(Figure 5). All physical components of the system are modeled using blocks. Their con-nections regarding material, energy, or information flow are captured using connectors.Thus, the Block Definition Diagram shows their dependencies on an abstract level. For

59

Figure 5: SysML Block Definition Diagram for the coffee machine

each component, detailed models are assigned later in the development process. Depend-ing on the discipline, the appropriate types of detailed models are chosen. The Control-component contains the system’s software, thus on the Detail Level Model for this com-ponent UML Class Diagrams and State Machines are appropriate to model structure andbehavior. An excerpt of the State Machine for the Control-component’s behavior isdepicted in Figure 6. Transition labels are omitted here as well as deeper levels in hier-archical states. According to our requirements metamodel, a satisfy-relationship assignsrequirement 1.1 from Figure 4 to the hierarchical state Coffee, since it determines thenecessary behavior to fulfill the requirement.

Figure 6: Excerpt of the Statemachine for the Control Component

The Detail-Level Model is subsequently abstracted in order to check the non-functionalrequirement on an abstract cross-discipline model. For the time property in focus here,the software is identified as the leading discipline which yields the frame for the abstractmodel. Thus, the State Machine in Figure 6 is first transformed to a timed automaton,which is then minimized using techniques as stated in Section 4.

The minimized Timed Automaton constitutes the frame for the annotation of necessary in-formation from the Detail Level Models. Locations l2, l3, l4, and l5 in Figure 7 representthe steps Check, Grind, Heat, and Brew from the State Machine. The required valuesfor the variable u in the location’s invariant are obtained by employing interface blockswhich connect this abstract model to the detailed discipline-specific models. For l4’s in-variant, representing the maximum time to heat water, an interface block is necessary to

60

Figure 7: Timed Automaton to validate the given requirement

include details from the mechanical discipline, modeled using CAD. The interface blocknecessary here bases on the Formulas 1, both from the field of thermodynamics:

Q = m · c ·∆T , Q = k ·A ·∆T (1)

The first formula computes the thermal energy from the given mass of the water m, thespecific heat capacity c (both given by the CAD model), and the difference in temperature∆T . The second formula describes the heat conduction through the thermal conductivityk, the surface area A (both from the CAD model) and again ∆T . These formulas arecombined to a differential equation, constituing the function f1 for the interface block.Furthermore, from the formulas above, we have −→o1 = (t)T , −→i2 = (m, c,∆T, k,A)T , and−→i1 = −→o2 =

−→0 . By inserting the necessary values, we obtain t ≈ 30s as l4’s invariant.

For the other locations’ invariants, values are obtained similarly, using other interfaceblocks. The resulting Timed Automaton is depicted in Figure 7 and is checked againstthe TCLT formula from the test case using the UPPAAL model checker [LPY97]. It ischecked whether a path starting and ending in l0 can be completed within 90 seconds,which evaluates to true in this case.

6 Conclusion

In this paper, we presented an approach for hierarchical modeling and analyzis of complexmechatronic system. Precise interfaces between layers and relations among models enableextensive analyses on the models. Our layered concept unites both detailed discipline-specific models and analyzable representations of large-scale systems. Thus, we enable thereuse of existing knowledge and tools while at the same time facilitating cross-disciplineanalyses and optimizations.

For future work, we plan on examining further properties such as energy or reliability. Toachieve this, we will systematize the procedure to include new classes of properties intoour methodology. Therefore, the identification of the leading discipline has to be furtherstudied. Moreover, a more systematic design for interface blocks has to be developed toenable the application of this methodology to a wider range of systems. For both existingand new interface blocks, a general formalization of the concept is necessary. The appli-cability of our approach will also be evaluated using a both more complex and realisticreal-world case study including a prototype tool implementing the methodology.

61

References

[AD94] Rajeev Alur and David L Dill. A theory of timed automata. Theoretical computerscience, 126(2):183–235, 1994.

[BFB14] Giacomo Barbieri, Cesare Fantuzzi, and Roberto Borsari. A model-based designmethodology for the development of mechatronic systems. Mechatronics, 2014.

[BFL+08] Patricia Bouyer, Uli Fahrenberg, Kim G Larsen, Nicolas Markey, and Jirı Srba. Infi-nite runs in weighted timed automata with energy constraints. In Formal Modeling andAnalysis of Timed Systems, pages 33–47. Springer, 2008.

[Bis06] Robert H Bishop. The Mechatronics Handbook, 2 Volume Set. CRC Press, 2006.

[BSBF11] Luca Bassi, Cristian Secchi, Marcello Bonfe, and Cesare Fantuzzi. A sysml-basedmethodology for manufacturing machinery modeling and design. Mechatronics,IEEE/ASME Transactions on, 16(6):1049–1062, 2011.

[BTG04] Sven Burmester, Matthias Tichy, and Holger Giese. Modeling reconfigurable mecha-tronic systems with mechatronic UML. Proc. of Model Driven Architecture: Founda-tions and Applications (MDAFA 2004), Linkoping, Sweden, pages 155–169, 2004.

[CdPL09] Lawrence Chung and Julio Cesar Sampaio do Prado Leite. On non-functional require-ments in software engineering. In Conceptual modeling: Foundations and applications,pages 363–379. Springer, 2009.

[DKL07] Henning Dierks, Sebastian Kupferschmid, and Kim G Larsen. Automatic AbstractionRefinement for Timed Automata. Formal Modeling and Analysis of Timed Systems, page114, 2007.

[DO02] Werner Damm and Ernst-Rudiger Olderog, editors. Model checking timed UML statemachines and collaborations. Springer, 2002.

[E+07] Jeff A Estefan et al. Survey of model-based systems engineering (MBSE) methodolo-gies. Incose MBSE Focus Group, 25:1–70, 2007.

[KVH13] Konstantin Kernschmidt and Birgit Vogel-Heuser. An interdisciplinary SysML basedmodeling approach for analyzing change influences in production plants to support theengineering. In Automation Science and Engineering (CASE), 2013 IEEE InternationalConference on, pages 1113–1118. IEEE, 2013.

[LPY97] Kim G Larsen, Paul Pettersson, and Wang Yi. Uppaal in a Nutshell. InternationalJournal on Software Tools for Technology Transfer (STTT), 1(1):134–152, 1997.

[MCN92] John Mylopoulos, Lawrence Chung, and Brian Nixon. Representing and using non-functional requirements: A process-oriented approach. Software Engineering, IEEETransactions on, 18(6):483–497, 1992.

[OMG06] OMG. Systems Modeling Language (SysML) Specification. OMG document: ad/2006-03-01, 2006.

[UML11] OMG UML. 2.4.1 Superstructure specification. Technical report, documentformal/2011-08-06. Technical report, OMG, 2011.

[Web05] Christian Weber. Simulation Models of Machine Elements as Components of Mecha-tronic Systems. Micro-Specific Design for Tool-Based Micromachining, 2005.

62

Feature and Constraint Mapping for Configuration and

Evolution of Variable Manufacturing Automation Systems1

Yibo Wang, Matthias Riebisch

Department of Informatics, University of Hamburg

{wang|riebisch}@informatik.uni-hamburg.de

Abstract: Nowadays, in the domain of manufacturing automation systems, the

complexity of the design task demands for a comprehensive engineering approach.

Model-based approaches are in use for detecting or even preventing design errors

early to avoid costly rework later in the engineering process. Furthermore,

customizability is required to meet the individual needs of customers. Current

product line approaches do not cover the special challenges of the manufacturing

automation system domain with several disciplines and modeling languages.

This paper presents a product line approach to represent variability in the domain

of manufacturing automation systems using common data exchange languages

such as ReqIF and AutomationML. Firstly, we map feature model to domain

artefact models. Secondly, we map constraints between domain artefacts onto

constraints between features. The created feature mapping and constraint mapping

enable to forward consistency checks from product level to product line level.

Moreover, the mappings provide support for evolution of the feature model and the

constraints. The approach is implemented by a prototype and the feasibility is

evaluated in an industrial setting.

1 Introduction

Today, the design of manufacturing automation systems is a complex engineering

process, which integrates different disciplines such as manufacturing, mechanical,

electrical and automation engineering [SZ+13]. Model-based approaches are used for

detecting or even preventing design errors early to avoid costly rework later in the

engineering process. For manufacturing systems and for automation systems controlling

them, the ability of customization is essential. Therefore, variability should be enabled in

these systems. To manage the complexity of variable systems during development, the

product line metaphor has proven to be useful. Product lines enable variability by

configuring a system from variable components on a common platform. During

evolution of a product line, manifold models have to be maintained. The complexity of

this evolution task demands for an explicit modeling of dependencies and constraints

between the variable components. Existing modeling languages only partially fulfill

1 This research has been partly funded by the German Federal Ministry of Education and Research BMBF

under grant 01M3204C in the joint project “Design Methods for Automation Systems using Model Integration

and Automated Variant Evaluation”.

63

these demands; a development methodology and a comprehensive approach are still

missing.

In this paper, we address these challenges with a product line approach. Firstly, we

represent variability in feature models by using common data exchange languages such

as ReqIF2 and AutomationML

3and map features to their correspondent domain artefacts.

Secondly, we map constraints between domain artefacts to constraints between features

in order to provide tool support for consistency checks during configuration.

Furthermore, both mappings help to determine the impact of changes thus facilitating

evolution. Due to space restrictions, in this paper variability of automation systems is

considered only for manufacturing process and plant structure.

In order to illustrate our approach, we use the running example of a so-called flying saw:

A slide with the flying saw is synchronized with the material’s speed [Len10], as shown

in Fig. 1. Once the material is cut completely, it returns to the starting position as soon as

possible to get ready for the next processing iteration.

Fig. 1: Running example - Flying saw [Len10]

2 State-of-the-Art analysis

Modeling approaches for variability in product line engineering: There are two main

approaches to model variability in the domain of product line engineering: the

amalgamated and the separated approach [Jez12]. The amalgamated approach, as

described in [Cla01], extends the meta-model of an artefact model to express variability.

Thus, the variability information can be attached directly to the artefact model. It is a

simple solution but it overloads the artefact model with the variability information.

In contrast, in the separated approach as described in [CA05], variability is represented

in the separated variability models such as decision models, feature models or the

orthogonal variability models [CG+12]. It makes a clear separation between variability

and artefact modeling. However, it implies additional effort to create and maintain the

traceability links between the variability model and the domain artefact model.

Model consistency in product line engineering: Consistency of a model means it does

not contain any contradiction [Lev65]. In [Hei09], an overview over validation of

product line models by checking well-formedness of software product line models on

2 Requirements Interchange Format http://www.omg.org/spec/ReqIF/ 3 Data exchange format defined in IEC 62714 https://www.automationml.org/

64

syntactical level is given. Well-formedness is defined as conformance of a given model

including configurations with constraints of the underlying meta-model. In [CP06], the

well-formedness of feature-based model templates is verified by OCL-constraints. In the

domain of automation systems, the formal conformance of AutomationML data [Sch10]

can be checked by OCL constraints at syntactical and semantic level. But within these

approaches, model consistency can be checked only after the final product is derived,

because the constraints are defined only for the domain artefact model, but not for the

variability model.

Traceability for evolution in product line engineering: According to [AK+07],

traceability is the ability to trace software artefacts forward and backward along the

software lifecycle, with four orthogonal traceability dimensions in software product line

development: refinement, similarity, variability and versioning traceability. [PB+05]

refines the dimension variability into two types. The first type relates the variability

model to software artefacts specified in other models, i.e. the mapping between features

and domain artifacts in our approach. The second type links the application artefacts to

the corresponding domain artefacts. However, the traceability links between constraints

at product level and product line level are not considered by both approaches. Hence

they cannot support evolution of constraints between domain artifacts in a product line.

3 Mapping approach

3.1 Basic decisions

According to the State-of-the-Art analysis we made the following basic design decisions:

Separation of concerns: When regarding both product line modeling approaches the

separated one is preferred, because the design principle separation of concerns facilitates

managing the complexity of evolution. Thus, artefact model and variability model can

evolve separately. Furthermore, a separation between models of the disciplines

manufacturing, mechanical, electrical and automation engineering facilitates evolution.

For each of these disciplines, the previous one provides the requirements for the

subsequent one, similar to problem and solution. In this paper, we discuss the separation

between problem space and solution space instead of the one between the disciplines.

Modeling variability in the automation domain: As discussed before, variability is

modeled separately in our approach. We use the feature model [KC+90] as variability

modeling language, because it has the dedicated notations and symbols to express

variability and is discipline-independent. In addition, it is easy to understand and apply.

Moreover, it has a good tool support. In contrast to other approaches, the variability

model in our approach is connected to the artefact model by using discipline-

independent common data exchange languages, because we propose to support

variability for different disciplines. In the domain of automation systems,

AutomationML is used to describe real plant components and incorporate different

standards which cover the aspects of topology, geometry, kinematics and logic.

Analogous to AutomationML, the Requirement Interchange format (ReqIF) is the de-

facto standard exchange language for requirement engineering in this domain.

65

3.2 Product-line-based design process

In this section we present our mapping approach that makes the design of automation

systems more efficient. In the following, we concentrate on the extensions of the product

line approach, which enable consistency checking during configuration, as well as

evolution of feature model and constraints.

3.2.1 Structuring of the design models

Our approach separates the modeling of a problem from the modeling of its solution.

The former is referred to as Problem Space (PS) as a conceptual prospective of

automation systems, which describes the requirements and their properties, as well as the

relationships between them. The latter is referred to as Solution Space (SS), which

describes the realizations of the requirements. It specifies solution components, their

attributes, as well as their internal structures and behaviors. This separation is required to

check the consistency between a requirement and its realization.

Fig. 2 “Feature mapping” and “Constraint mapping”

Like in other product line approaches, reusable domain artefacts are modeled in the

domain artefact model. However, we separate the requirement artefact model from the

solution artefact model. Reusable requirements (such as “transport weight” and

“transport speed” of a flying saw) in the requirement artefact model are described by the

data exchange language ReqIF and reusable solution artefacts (such as “saw stroke”,

“conveyor” and “saw carriage”) in the solution artefact model are described by

AutomationML, as illustrated in Fig. 3 and 4. In addition, the variability model is also

divided into a feature model in problem space (representing the variability of

requirement artefacts) and a feature model in solution space (representing the variability

of solution artefacts). They are illustrated by the four quadrants in Fig. 2.

66

Fig. 3 Domain requirement artefacts

represented by ReqIF

Fig. 4 Domain solution artefacts

represented by AutomationML

3.2.2 Feature mapping

Variability is represented by variable features and the relationships between the features

in a feature model. Typically, a variable feature is a feature that can be selected or

deselected during configuration (Type 1 in Fig. 5). We refine this behavior and

complement the variable feature with an arbitrary number of parameterizable parameters

(Type 2). In addition, a variable link between two domain artefacts can also be

represented as a variable feature if we treat its source and target artefact as configurable

parameters (Type 3).

Fig. 5 Supported variability types

We create the feature model in the following steps:

1. Set the scope of the domain artefacts, which will be mapped to features. It is

typically a subtree in the domain artefact model (e.g. “Flying_Saw” in Fig. 4).

2. Select a domain artefact

3. Create a feature as representation of the domain artefact

o The feature has the same name as the domain artifact

o The feature takes the same place in the hierarchical structure as the domain

artefact

o The feature has the same attributes as the domain artifact

o A feature is mandatory by default. If it is selectable (type 1 in Fig. 5),

change it to an optional feature

67

4. Create a traceability link (Type � in Fig. 2) between the feature and the domain

artifact

5. Repeat step 1 to step 3, until all domain artifacts in the defined scope are mapped to

features.

The feature mapping connects the requirement and the solution artefact with the features

in problem and solution space respectively. This mapping facilitates consistency checks

during feature configuration. Furthermore, it is essential for derivation of the final

requirement and solution models according to the configuration.

3.2.3 Constraint mapping

Constraints in a model restrict the way in which different types of components can be

combined with each other [SW98]. In our approach, a consistency rule is regarded as a

formalized representation of a constraint. It defines which modeling elements under

which conditions are consistent or inconsistent, and optionally describes what needs to

be done to resolve the inconsistency. The consistency rules at product line level

formalize the consistency between features, and the consistency rules at product level

formalize the consistency between domain artefacts.

In our approach, domain experts have given the constraints between requirement

artefacts in ReqIF by using the user-defined relations “needs” and “excludes”. The

constraints between solution artefacts are given by using simple attribute constraints in

AutomationML or by defining complex consistency rules with OCL4. Moreover, the

constraints between requirement and solution artefacts are realized by “ReqIF-

Interfaces” in AutomationML. However, all the constraints are formalized only at

product level. Hence, they can be used to check the consistency of a design model, only

if the final design model is derived.

As discussed in section 3.3.2, features are mapped to their correspondent domain

artefacts and have the same attributes and hierarchical structure as them. Therefore it is

possible to transform the consistency rules between domain artefacts into the consistency

rules between features. A consistency rule C between domain artefacts can be

transformed into a consistency rule C’ between features, if and only if all the domain

artefacts affected by C are mapped to features. Analogous to the mapping of a feature to

a domain artefact, consistency rules C and C’ are also connected by a traceability link

(Type � in Fig. 2). With this extension for product line engineering, the consistency of a

design model can be checked directly at product line level. It means that design errors

can directly be identified during configuration, without prior generation of the

correspondent design model.

Table 1 illustrates some examples of constraint mappings between product level and

product line level. An automatic transformation of constraints is possible, only if the

variability modeling tool supports the same modeling concept for constraint definition as

the artefact modeling. For example, a “requires” constraint between a solution artefact

and a requirement artefact can be mapped automatically to a crosscutting relation

between features – the “requires” relation in a feature model.

4 Object Constraint Language http://www.omg.org/spec/OCL/

68

Table 1 Examples of constraint mappings

Types of

constraints

Formalization at

product level

Formalization at

product line level

Types of constraint

transformation

Between

requirements

“needs” and “excludes”

relationships realized by

customer relations in

ReqIF

Crosscutting feature

relationships:

“requires” and

“excludes”

Automatic

transformation

Between

solutions

Attribute constraints

and OCL-constraints in

AutomationML

Specific constraint

languages used in the

product line tool

Manual and

automatic

transformation

Between

requirements and

solutions

“requires”-relationship

realized by ReqIF-

interface in

AutomationML

Crosscutting feature

relationship:

“requires”

Automatic

transformation

3.2.4 Configuration based on consistency rules

When using the consistency rules defined at product line level, consistency of the design

model can be validated directly during configuration. In our approach, configuration is

started always from the problem space. Configuration in the problem space represents

the customization of requirements requested by a customer. Decisions (selection of

features and setting of parameters) in the problem space constraint the decisions in the

solution space by the consistency rules between problem and solution space. For

example, the selection of the feature “decentralized control” in the problem space

implies the existence of the feature “function block” in each part of the flying saw in the

solution space. If some decisions in solution space are still undecided after the

configuration in problem space, they should be made explicit in order to resolve

variability in all features.

3.2.5 Evolution of features and constraints

In the product line engineering, typical maintenance activities on the domain artefacts

(e.g. adding/renaming an attribute) result in frequent changes in the correspondent

feature model. In addition, the changes of a constraint between domain artefacts should

also be considered in the feature model. The dependencies between domain artefacts,

features and constraints are essential to support this change propagation.

In our approach, the dependencies are represented by the traceability links (type � and

type � in Fig. 2) of feature mapping and constraint mapping. Fig. 6 gives an overview

of the change propagation process. The changes scope defines which domain artefacts

and constraints have been changed. We implement a rule-based impact analysis based on

the previous work [LFR13]. It calculates the impact scope of the given changes

automatically according to the given change scope and predefined impact rules.

69

Fig. 6 Impact analysis for features and constraints

3.3 Implementation

For the modeling of variability and configurations, we use pure::variants5. The

traceability links are realized by the annotation with feature-IDs in the ReqIF and

AutomationML files, because the feature IDs remain unchanged after their initial

generation. The traceability links between consistency rules at product line and product

level are implemented analogously by the annotation with rule-IDs. Domain artefact

model and feature model are integrated by EMF6. By using EMF-Trace

7, changes in a

model can be propagated to the connected models. However, the changes in the impact

model should be done manually currently.

The constraint languages pvSCL and pvProlog are used to define consistency rules at

product line level. Currently the transformation of constraint rules is partly automated

(e.g. automatic transformation of attribute constraints in AutomationML into pvSCL

constraints). Our approach supports negative variability [BS12] to derive the final design

model using XSLT transformation. This means that the design model is created by

copying domain artefacts and filtering out the artefacts selectively, which are not

selected during configuration.

4 Example and Evaluation

4.1 Application example

As proof of concept, our approach has been used to support the product-line-based

design of a flying saw. Variability of the flying saw exists for example in its control

architecture (centralized or decentralized) and cutting methods (cutting process

controlled by preset length or by marks made on the material). Fig. 7 represents the

simplified feature diagram. We could map 106 attribute constraints and OCL constraints

onto the consistency rules in the feature model. During the configuration, consistency

checks were performed by pure::variants. Decisions in the problem space constrain the

decisions in the solution space, e.g. the feature “cutting controlled by mark” needs the

feature “mark sensor” (marked by the dotted line in Fig 7). The customized requirement

model in ReqIF and the solution model in AutomationML were generated according to

the configuration results.

5 A variant management tool http://www.pure-systems.com/ 6 Eclipse Modeling Framework http://eclipse.org/modeling/emf/ 7 A tool to integrate model and impact analysis http://sourceforge.net/projects/emftrace/

70

Fig. 7 Partial view in the feature model for “flying saw”

4.2 Evaluation and discussion

Our approach is a design-based research approach [MR11]. That means that we develop

our research approach in a continuous application and evaluation procedure. We

conducted a number of variability modeling and configuration workshops with industrial

project partners and received positive feedback. Using consistency rules in feature

models during configuration makes the design of automation system more efficient and

more flexible. The changes on domain artefacts and constraints could be propagated

using impact analysis. Thus the PL modelers got notified in order to make changes in the

feature model for keeping model consistency in the project. Although first results of our

approach are promising, there are also some limitations:

1) The approach needs to be evaluated by designing a more complex automation system,

which covers more disciplines and offers more variability. One could extend our

approach by using discipline-independent languages such as ReqIF and AutomationML.

2) It is generally difficult to convert a rule from one constraint language to another

programmatically. In particular, it is the case if two languages use different modeling

concepts. For example, iteration in OCL is not supported by pvSCL.

3) The generation of the final design model is currently based on negative variability

only. In contrast, positive variability approaches generate the final design model by

composing the selected design artefacts. The implementation would be possible by using

generators such as the AutomationML engine.

5 Conclusion and outlook

In this paper we proposed a product-line-based mapping approach for the design of

manufacturing automation systems. The contribution of this paper is the feature mapping

71

and the constraint mapping by using traceability links. These mappings are essential for

the configuration and generation of design models of automation systems. In addition,

the traceability links facilitate the evolution of feature models and constraints for product

lines.

Currently, we are working on a front-end tool that facilitates the mapping between

features and domain artefacts, as well as the mapping between constraints. Future works

include the implementation of positive variability approaches for the generation of

design models. In addition, we will extend our approach by the concept of views and

viewpoints to address different and even conflicting interests of stakeholders in the

product-line-based design process.

References

[AK+07] Anquetil, N.; Kulesza, U.; Mitschke, R.; Moreira, A.; Royer, J.-C.; Rummler, A.;

Sousa, A.: A model-driven traceability framework for software product lines. Software

& Systems Modeling, p. 427–451, 2007

[BS12] Buchmann, T.; Schwägerl, F.: Ensuring well-formedness of configured domain models

in model-driven product lines based on negative variability. FOSD '12, p.37-44, 2012

[CA05] Czarnecki, K.; Antkiewicz, M.: Mapping features to models: A template approach

based on superimposed variants. GPCE ’05, p.422–437, 2005

[CG+12] Czarnecki, K.; Grünbacher, P.; Rabiser, R.; Schmid, K.; Wąsowski, A.: Cool features

and tough decisions. VaMoS’12, p.173–182, 2012

[Cla01] Clauss, M.: Generic modeling using UML extensions for variability. OOPSLA’01,

2001

[CP06] Czarnecki, K.; Pietroszek, K.: Verifying feature-based model templates against well-

formedness OCL constraints. GPCE’06, p.211, 2006

[Hei09] Heidenreich, F.: Towards systematic ensuring well-formedness of software product

lines. FOSD’09, 2009

[Jez12] Jézéquel, J.-M.: Model-Driven Engineering for Software Product Lines. ISRN

Software Engineering, p. 1–24, 2012

[Len10] Manual Standardised Application L-force FlyingSaw. Lenze Automation GmbH, 2010

[Lev65] Levison, A. B.: Logic, Language, and Consistency in Tarski's Theory of Truth,

Philosophy and Phenomenological Research, p.384-392, 1965

[LFR13] Lehnert, S.; Farooq, Q.; Riebisch, M.: Rule-Based Impact Analysis for Heterogeneous

Software Artifacts. CSMR’13 p. 209–218, 2013

[KC+90] Kang, K.C.; Cohen, S.G.; Hess, J.A.; Novak, W.E.; Peterson, A.S.: Feature-oriented

domain analysis (FODA) feasibility study. SEI, Carnegie Mellon University, 1990

[MR11] McKenney, S.; Reeves, T.: Conducting Educational Design Research, Routledge, 2011

[PB+05] Pohl, K.; Böckle, G.; van der Linden, F.: Software Product Line Engineering –

Foundations, Principles, and Techniques. Springer Verlag, 2005

[Sch10] Schleipen, M.: A concept for conformance testing of AutomationML models by means

of formal proof using OCL. ETFA’10, p.1–5, 2010

[SW98] Sabin, D.; Weigel, R.: Product configuration frameworks – a survey. IEEE Intelligent

Systems 13 (4), 1998

[SZ+13] Schröck, S.; Zimmer, F.; Holm, T.; Fay, A.; Jager, T.: Principles, viewpoints and effect

links in the engineering of automated plants. IECON´13, 2013

72

Models for Adaptable Automation SoftwareAn Overview of Plug-and-Produce in Industrial Automation

Oliver Niggemann, Steffen Henning,inIT — Institut Industrial IT, HS OWL, Lemgo, Germany,Email: {oliver.niggemann, steffen.henning}@hs-owl.de

andSebastian Schriegel, Jens Otto,

Fraunhofer IOSB-INA, Lemgo, Germany,Email: {sebastian.schriegel, jens.otto}@iosb-ina.fraunhofer.de

andAnas Anis,

Heinz Nixdorf Institut, Universitat Paderborn, Paderborn, Germany,Email: [email protected]

Abstract: The modelling of distributed production systems has gained new attentiondue to research agendas such as Cyber-physical Production Systems (CPPSs), Indus-trial Internet or its German pendant “Industrie 4.0”. At heart of these agendas lies thegoal of adaptable production plants: Plant should adapt automatically to new productsand to changes in the production process. A large part of this solution must be imple-mented in the automation software which is now required to have self-configurationcapabilities—also called Plug-and-Produce. Plug-and-Produce solutions are based onadditional knowledge about products and processes, knowledge which is provided bymeans of models. But in the context of CPPSs, the types and the usage of models ischanging: The focus is moving towards product and process models and models areused in more phases of a plant’s life cycle. In this paper an overview of models usedfor Plug-and-Produce is given using several exemplary use cases.

1 Introduction

Cyber-physical Systems (CPS) combine computation with physical processes [Lee08]. Asubset of CPS are Cyber-physical Production Systems (CPPSs) whose main feature isadaptability. I.e. they have the ability to adapt to new production goals such as newproducts or product variants [ZBG+08, RKH+10]. Today, the bottleneck of such systemsis the automation system which still requires high manual engineering efforts during everyplant adaptation. Therefore, the research question is how the next generation of automationsystems can fulfill the promise of adaptability and Plug-and-Produce.

A key solution to this question is the introduction of new types of models: While tra-ditionally models describe the automation software itself and are only used during theengineering phase, CPPSs require models which describe further aspects such as the pro-duction process and the product. Therefore, this paper gives an overview of adaptable

73

automation software from a model point of view. Related overviews have been given in[Sch14, Vya13, NK14].

1.1 Classical vs. CPPS-enabled Automation Software Development

Classical automation has a long established development process: Normally informal de-scriptions – often provided verbally – of the product and the production process are thestarting point. The engineer then uses engineering tools to write software for the con-trollers, often for each controller separately. This software is written using classical pro-cedural languages such as IEC 61131-3.

CPPS-enabled automation software development works differently: the automation engi-neer no longer writes the automation software manually, but solely defines the automationgoal (models of products and production processes), with the result that the engineeringmodels no longer defines the ”how” but the ”what”. Production goals are product features,costs, throughput or the energy consumption. As, in contrast to the classical automation,these automation goals usually remain unchanged during system modifications (e.g. re-placement of a system module), the automation engineer is no longer continually involved.Moreover, it is easier to define the automation goal (e.g. in the form of a description ofthe final product) than the complete automation logic (i.e. the software). This results in areduction of the complexity as perceived by the automation engineer.

As a prerequisite for such adaptability, a transparent communication connection betweenthe production modules and their respective controllers has to be established, which isdone in the communication layer. This includes tasks such as physically connecting thehardware and software modules and specifying communication protocols. For this, ap-proaches for auto-configuration [RKH+10, DIT+13] and middleware solutions [CGT08,DCK+06, ZSH+07, Sch08] are researched. For this paper, we presume that the automa-tion platform and the communication layer provide these features and support thereforeadaptability.

Figure 1 now outlines the main steps of a CPPS-enabled automation software develop-ment: First, a model of the production process is computed, this process transforms theprovided raw materials into the required product. In a second step, a software architecturemodel is generated which automates this process. In a last step, this software model isparameterized. In the following these steps are explained in detail.

FormalProduct

Description Feeding

Maize PortionMaize

Energy

ProcessVDescription

SW3InterfaceFeeding

SW3InterfaceFilling

SW3InterfacePopcornVProd.

SW3ArchitectureProductVand

ProcessDescription

ProductVandProcess

Description

VAR_EXTERNALStart_StopV :VBOOL;ON_OFFV :VBOOL;

END_VARVARV

Automation3SW

1.VP

lan

nin

g

2.VO

rch

estr

atio

n

3.VP

aram

teri

zati

on

Energy

Figure 1: CPPS Automation Development Process.

74

Step 1: Computation of a production process model Ultimately, the final goal of allactivities is the product. Manufacturing engineering, automation, and mechanical engi-neering are all only means to this end. So as a vision, CPPS-enabled automation shouldstart from models, capturing the set of requirements: product and raw material descrip-tions. Planning and scheduling methods are then used to generate a suitable productionprocess [ASN14, BBB+11, LSH+11], these solutions use the product and raw materialdescriptions and also models of production ressources (robots, transportation systems, re-actors, etc. ) and compute an optimal sequence of production steps, i.e. the productionprocess model.

The reader may note that such a planning step requires that production steps can stillbe rearranged. Since the plant is, from a mechanical point of view, usually already in-stalled when the automation software is created, a corresponding dynamic plant layout isrequired—a prerequisite seldom true in real-world production.

Step 2: Orchestration of a software architecture Many research projects take such a pro-duction process as an input and compute a corresponding software architecture [LSH+11,PSB13]. Normally, this is done by combining pre-defined software components [WVH09,PSK11] whereat software components usually correspond to production modules. Thisstep is called software orchestration. In this step, models of the production process andsoftware interface models form the input while software architecture models are the out-put.

If software orchestration is used, the process description has to be somehow related tothe description of the software components. In most projects, this is done by creatingtwo taxonomies of process steps and of software components–often formally modeled asontologies. Elements of both taxonomies are than mapped onto each other, allowing foran automatic choice of software components for process steps. E.g. a production step“transportation” is mapped onto a software component “transporting”.

The reader may note that the behavior of software components and process steps are mod-eled as symbols/ontologies only and no dynamic system features are therefore captured,i.e. it is an open research question whether this type of modeling is sufficient for real-worldproduction plants.

Only few projects try to generate the software from the scratch instead of using pre-definedsoftware components [HO+14, OHN14].

Step 3: Parameterization of a software architecture The usage of software componentsin step 2 comes with a price: the automation software must be abstracted into reusableand capsulated software components. While in classical automation software is writtenfor each production scenario individually, such software components must be now appli-cable to a large set of scenarios. And this is only possible if software components can beadapted to individual scenarios by means of free parameters in the software. Examples forparameters are machine timing, controller parameters such as PID, physical dimensions ofproducts, sensitivity of diagnosis functions, etc.

These steps usually require either manual efforts or behavior models to predict and tooptimize the system behavior.

75

To show our development process, we use the Genesis PnP demonstrator (figure 2). Thisdemonstrator is a flexible processing and sorting system and deals with workpieces, whichare either ferrous or non-ferrous cubes. Three mechatronic modules are installed in thisdemonstrator: two containers - one for each kind of workpieces - and an induction sensor.An axis with a carriage and a gripper are installed on the top. A linear drive is used to setthe gripper in the right position to grip, move, and drop workpieces. The gripper transportseach workpiece to the induction sensor to check its magnetism. Finally, the gripper carriesthe piece to the appropriate container and drops it for storage.

Figure 2: Genesis PnP demonstrator, consisting of a gripper on an axis and four interchangeablemodules: a (product providing) stack, an induction sensor and two containers

2 Planning

Cyber Physical Production Systems (CPPS) require, among other requirements, self -adaptability [Lee08, OSL11]. The self-adaptability enables CPPSs to adapt autonomouslyin response to changes in the plant or to new customer needs [BBB+11, Los13]. This self-adaptability can be achieved by applying cognitive principles such as automated planningin CPPSs [BBB+11]. This requires a formal description of products, materials, and ma-chine operations as an input. Automated planning techniques take this input to generate asequence of production operators, i.e. the production process which produces the requiredproduct. A prerequisite of this is, of course, that the production plant offers this degree ofvariability—a requirement seldom true in reality.

The production process takes materials, energy and information and transforms them intothe final product; we call these entities state type S and formalize them according to thestandard VDI/VDE 3682 [VDI14]. VDI/VDE 3682 mainly models resources and products(states) as symbols. An operator type op ∈ OP,OP ⊆ P(S)×P(S) (P denotes the powerset), is also formalized using VDI/VDE 3682, then transforms a set of input state typesopin ⊆ S into an output set of state types opout ⊆ S. Each operator op is implemented bya resource rop ∈ R, i.e. a plant module such as a robot.

Definition 1. Input of Planning Step

76

So the input of the planning step is a tuple (S,OP,R) with OP ⊆ P(S) × P(S) and∀op ∈ OP : ∃rop ∈ R.

The output of the planning step is a production process. For the production process, we canapply each operator and each state for an arbitrary number of times. I.e. we presume thatresources (plant modules) can be used several times and that no limit exists for materialsand energy. For this, we differentiate between the set of states S and the state instances S∗

and, analogously, between the operators OP and the operator instances OP ∗.

The production process, being the output of the planning step, is then defined as follows:

Definition 2. Production Process, Output of Planning StepA production process P is a directed graph defined by the tuple (S′ ⊆ S∗, OP ′ ⊆ OP ∗,E, S′init ⊆ S′, sf ∈ S′) where S′ is a set of state instances used through production, OP ′

a set of operator instances, E ⊆ (S′×OP ′)∪ (OP ′×S′) the directed edges of the graphwhich connect state instances with operator instances, S′init the set of initial raw states(including materials, energy, and information) and s′f is the final product. Starting fromeach state in S′init , there must exist a path to s′f , i.e. all initial raw material must be used.

An example of a production process from the Genesis PnP demonstrator is given in figure3. In this example, the set S′ = {w, gw , fw ,nfw , sw , ca, e, i} is the set of state instances(materials, energy, or information) that flows through the production process. These statescorrespond to the inputs and outputs of the operators OP ′ = {grip, check magnetism,move}. The directed edges E are represented with solid arrows between states and op-erators. The initial states S′init = {w, ca, e, i} are the inputs for the different operators.Finally, s′f = sw is the final state in this production process that represents the requiredproduct.

For product modelling several modelling formats exist, like STEP, IGES and DXF. Thegoal of IGES and DXF was to enable a tool independent exchange of CAD data, whichwas a problem at that time. These two formats however, only support physical productaspects. STEP is defined in ISO 10303 and contains physical as well as functional aspectsfor the entire lifetime of a product, which makes it a versatile format. A general frame-work for the geometrical specification of products is defined in ISO 14638. Dependingon the application area, additional formats exists, like IFC for building parts. For func-tional aspects of products eCl@ss is widely used. Its data model is based on internationalstandards IEC 61360 and ISO 13584-42. In contrast to STEP it only focuses on func-tional aspects. In eCl@ss products are classified into product classes and a predefined setof attributes is specified for each class. In [HLS07] eCl@ss is compared to other struc-tural product description formats. The interpretation of product description in one of theprevious standards into an input for the planning step is still an open research question.

The resource, i.e. the technical asset can be modelled with some of the general purposemodels such as automata or Petri nets. Additionally UML component diagrams can beapplied. Also, formats of the product modelling like STEP or basically any 3D format canbe used as well for structural information of the asset. In IEC/TR 62794 a classificationof asset attributes is presented, distinguishing between five basic elements, which are:construction, function, location, performance and business.

77

e:&Electricity

Gripgw:&

Gripped&Workpiece

Check&Magnetism

fw:&Ferrous&Workpiece

nfw:&Non-ferrous&

Workpiece

Move

i:&Ferrous&U&Non-ferrous&

Container&Locations

Product&TPR

Information&TIR

Energy&TER

Flow

Usage

System&Limit&TSR

Technical&Resource&TTR

Process&Operator&TOR

ca:&Compressed&

Air

w:&Workpiece

Magnetic&Sensor

GripperPneumatic&

Motor

sw:&Sorted&Workpiece

Figure 3: An Example of a Production Process according to [VDI14].

Finally, all this information can be stored corresponding to the AutomationML standard.AutomationML is an independent data exchange format, which is specified in IEC 62714.

3 Orchestration and Software Synthesis

Based on this computed production process (see definition 2), a software architecture isthen computed which automates the production process. This is usually done by meansof software orchestration, i.e. by connecting existing software components COMP—these software components are normally instantiations of software component types. Asoftware component c ∈ COMP communicates to its environment by means of a setof ports port(c), where ports are usually typed by formally defined interfaces. Softwarecomponents are connected by connecting their ports.

In the field of automation, software components can be defined using OPC UA, which of-fers a standard for data exchange between software components and control environments.OPC UA is defined in IEC 62541 and also comprises an information model for any kindof process data.

Formally we can define a software architecture as follows:

Definition 3. Software Architecture, Output of Orchestration StepA software architecture A is a composition of software components defined by the tuple(COMP , X ⊆ PORTS × PORTS ) with PORTS =

⋃p∈ports(c),c∈COMP p. For each

(p1, p2) ∈ X , the interfaces of p1 must be compatible to p2.

78

To compute such a software architecture A = (COMP , X) based on a production processP = (S′, OP ′, S′init, sf ), several approaches exist. Often, a one-to-one matching fromprocess steps OP ′ to software components COMP is used. In this case, the ports, andthe respective interfaces, correspond to the states S′.

For example, to model the Genesis demonstrator, which is shown in figure 2, the inputmodel, i.e the production process, could look like the ones shown in figure 3. The resultingsoftware architecture of the orchestration step is shown in figure 4.

<<component>>

Check_Magnetism

<<component>>

Move_P1

<<component>>

Move_P2

<<component>>

Move_P3

Figure 4: Resulting Software Architecture.

4 Software Parameterization

So the usage of software orchestration and of software components raises a new key re-search question: How can we choose automatically optimal parameters of the automationsoftware for a specific production scenario? In detail, we need to optimize parameterscpara for a software component c ∈ COMP . Examples for parameters are timing config-urations of plant modules or control parameters. For this optimization step, a cost functionf is optimized, f usually models the energy consumption or the manufacturing time of aproduction plant.

So formally the input of the software parameterization step is defined as:

Definition 4. Input of Parameterization StepInput for this step is a cost function f(A,P ) where A is a software architecture and P aproduction process.

Output of the software parameterization step is then:

Definition 5. Output of Parameterization StepOutput for this step are values argmincpara,c∈COMP f(A,P ) where A = (COMP,E)is a software architecture and P a production process.

As outlined before, software parameterization is a key research question for CPPS-enabledautomation. In general, two types of software parameterization approaches can be differ-entiated: figure 5 shows the first type:

Based on product and process features, the software can be parameterized by means ofsimple rules. An example is a robot that is adapted to physical dimensions of the product

79

FormalProduct

Description Anlieferung

Mais

Energie

Process Description

Product andProcess

DescriptionProduct and

ProcessDescription

VAR_EXTERNAL Start_Stop : BOOL; ON_OFF : BOOL;

END_VAR VAR

Automation-SW

ParameterizationRules

Figure 5: Rule-based Software Pa-rameterization.

Product andProcess


ProcessDescription


END_VAR VAR

Automation-SWProcess Model

Virtual Plant

Assessment ofParameterization

Computation ofbetter parameters

FormalProduct

Description Anlieferung

Mais

Energie

Process Description

Product andProcess


ProcessDescription


END_VAR VAR

Automation-SW

Figure 6: Iteration-based SoftwareParameterization.

or a filling station that chooses the amount of liquid according to bottle sizes. One mightnotice that this approach only works (i) if the production machine can be adapted locallyand local parameters do not influence other parts of the production line and (ii) if the rulesare rather straightforward and simple.

If a rule-based approach does not work, an iterative approach as shown in figure 6 must beused: In an optimization loop, sets of parameters are analyzed virtually using a model ofboth the plant and the automation system. If a good set of parameter is identified virtually,this parameter set is used for the real world plant. Unlike the rule-based approach, thisapproach allows for a system-wide optimization of parameters. Example are dynamicparameters such as machine cycle times which must fit to the other cycle times and tobuffer sizes.

An example is given using the Genesis demonstrator (see figure 2). The gripper transportsblocks of metal or wood and has four positions (p1, p2, p3, p4) for each interchangeablemodule. To reach each position a speed (mm/s) and acceleration (mm/s2) informationis required. The automation software that controls the gripper must be parameterized withthese parameters. The iteration-based software parameterization is based on a simulation-based algorithm configuration approach [ON15]. This allows the parameterization of theautomation software, so that the transportation rate of blocks is high, without using moreenergy as needed.

5 Summary and Future Work

In this paper, an overview of a complete Plug-and-Produce or self-configuration approachfor Cyber Physical Production Systems has been given. In doing so, the focus has beenon the necessary models. Looking at the described models, some differences to classi-cal model-based solutions for industrial automation software can be stated: (i) The focusmoves from models describing the software to models describing products and processes.(ii) Models are often the input for algorithms from the area of intelligent systems or arti-

80

ficial intelligence such as planning, configuration or optimization algorithms. (iii) Modelsare more and more used during the operation phase, not only during the engineering phase.

These changes have a deep influence on the research for industrial automation: Moreknowledge concerning product development, machine construction and artificial intelli-gence is necessary. This type of knowledge is nowadays hardly existing in this field, i.e. adifferent education curriculum and different tool chains are needed.

References

[ASN14] Anas Anis, Wilhelm Schaefer, and Oliver Niggemann. A Comparison of ModelingApproaches for Planning in Cyber Physical Production Systems. In 19th IEEE In-ternational Conference on Emerging Technologies and Factory Automation (ETFA),Barcelona, Jun 2014.

[BBB+11] A. Bannat, T. Bautze, M. Beetz, J. Blume, K. Diepold, C. Ertelt, F. Geiger, T. Gmeiner,T. Gyger, A. Knoll, C. Lau, C. Lenz, M. Ostgathe, G. Reinhart, W. Roesel, T. Ruehr,A. Schuboe, K. Shea, I. Stork genannt Wersborg, S. Stork, W. Tekouo, F. Wallhoff,M. Wiesbeck, and M.F. Zaeh. Artificial Cognition in Production Systems. IEEE Trans-actions on Automation Science and Engineering, 8(1):148–174, 2011.

[CGT08] A. Cannata, M. Gerosa, and M. Taisch. SOCRADES: a Framework for DevelopingIntelligent Systems in Manufacturing. In IEEE International Conference on IndustrialEngineering and Engineering Management, pages 1904 – 1908, 2008.

[DCK+06] S. Deugd, R. Carroll, K. Kelly, B. Millett, and J. Ricker. SODA: Service-OrientedDevice Architecture. In IEEE Pervasive Computing, pages 94–96, 2006.

[DIT+13] Lars Durkop, Jahanzaib Imtiaz, Henning Trsek, Lukasz Wisniewski, and JurgenJasperneite. Using OPC-UA for the Autoconfiguration of Real-time Ethernet Systems.In 11th International IEEE Conference on Industrial Informatics, Bochum, Germany,Jul 2013.

[HLS07] Martin Hepp, Joerg Leukel, and Volker Schmitz. A quantitative analysis of productcategorization standards: content, coverage, and maintenance of eCl@ss, UNSPSC,eOTD, and the RosettaNet Technical Dictionary. Knowledge and Information Systems,13:77–114, 2007.

[HO+14] Steffen Henning, Jens Otto, , Oliver Niggemann, and Sebastian Schriegel. A DescriptiveEngineering Approach for Cyber-Physical Systems. In 19th IEEE International Con-ference on Emerging Technologies and Factory Automation (ETFA 2014), Barcelona,Spain, Sep 2014.

[Lee08] E.A. Lee. Cyber Physical Systems: Design Challenges. In Object Oriented Real-TimeDistributed Computing (ISORC), 2008 11th IEEE International Symposium on, pages363–369, 2008.

[Los13] Matthias Loskyll. Entwicklung einer Methodik zur dynamischen kontextbasiertenOrchestrierung semantischer Feldgeratefunktionalitaten. Phd-thesis, TUKaiserslautern, 5 2013. Bestellung nur direkt ueber den Autor moeglich:[email protected].

81

[LSH+11] Matthias Loskyll, Jochen Schlick, Stefan Hodek, Lisa Ollinger, Tobias Gerber, and Bog-dan Pirvu. Semantic service discovery and orchestration for manufacturing processes.In ETFA, pages 1–8, 2011.

[NK14] Oliver Niggemann and Bjoern Kroll. On the applicability of model based softwaredevelopment to cyber physical production systems. In 19th IEEE International Confer-ence on Emerging Technologies and Factory Automation (ETFA), Sep 2014.

[OHN14] Jens Otto, Steffen Henning, and Oliver Niggemann. Why cyber-physical productionsystems need a descriptive engineering approach - a case study in plug produce. In 2ndInternational Conference on System-integrated Intelligence (SysInt), Bremen, Germany,Jul 2014.

[ON15] Jens Otto and Oliver Niggemann. Automatic Parameterization of Automation Softwarefor Plug-and-Produce. In AAAI-15 Workshop on Algorithm Configuration (AlgoConf),2015.

[OSL11] Mauro Onori, Daniel Semere, and Bengt Lindberg. Evolvable systems: an approachto self-X production. International Journal of Computer Integrated Manufacturing,24(5):506–516, 2011.

[PSB13] Julius Pfrommer, Miriam Schleipen, and Jurgen Beyerer. PPRS: Production skills andtheir relation to product, process, and resource. In ETFA, pages 1–4, 2013.

[PSK11] N. Papakonstantinou, S. Sierla, and K. Koskinen. Object oriented extensions of IEC61131-3 as an enabling technology of software product lines. In Emerging TechnologiesFactory Automation (ETFA), 2011 IEEE 16th Conference on, Sept 2011.

[RKH+10] G. Reinhart, S. Krug, S. Huttner, Z. Mari, F. Riedelbauch, and M. Schlogel. Auto-matic configuration (Plug & Produce) of Industrial Ethernet networks. In 2010 9thIEEE/IAS International Conference on Industry Applications (INDUSCON), pages 1–6, Nov 2010.

[Sch08] M. Schleipen. OPC UA supporting the automated engineering of production monitoringand control systems. In IEEE International Conference on Emerging Technologies andFactory Automation (ETFA), pages 640–647, 2008.

[Sch14] B. Schatz. The Role of Models in Engineering of Cyber-Physical Systems - Challenegsand Possibilities. In CPS 20 Experts Workshop, CPSWeek, 2014.

[VDI14] VDI/VDE. VDI/VDE 3682 - Formalisierte Prozessbeschreibungen. Technical report,Verein Deutscher Ingenieure, Association of Engineers, April 2014.

[Vya13] Valeriy Vyatkin. Software engineering in industrial automation: State of the art review.IEEE Transactions on Industrial Informatics, 9(3):1234–1249, 2013.

[WVH09] D. Witsch and B. Vogel-Heuser. Close integration between UML and IEC 61131-3:New possibilities through object-oriented extensions. In IEEE Conference on EmergingTechnologies Factory Automation, 2009. ETFA 2009Vyatkin, Sept 2009.

[ZBG+08] Uwe E. Zimmermann, Rainer Bischoff, Gerhard Grunwald, Georg Plank, and DetlefReintsema. Communication, Configuration, Application - The Three Layer Concept forPlug-and-Produce. In ICINCO-RA (2), pages 255–262, 2008.

[ZSH+07] A. Zoitl, T. Strasser, K. Hall, R. Staron, C. Sunder, and B. Favre-Bulle. The Past,Present, and Future of IEC 61499. Holonic and Multi-Agent Systems for Manufacturing,4659:1–14, 2007.

82

Chancen und Herausforderungen bei der virtuellen Absicherung verteilter Body&Comfort-Funktionen

auf Basis von AUTOSAR

Dr. Thomas Ringler, Christian Dziobek, Dr. Florian Wohlgemuth

Daimler AG Entwicklung Elektrik/Elektronik

71059 Sindelfingen [email protected]

[email protected] [email protected]

Abstract: Die modellbasierte Funktionsentwicklung unter Anwendung des AUTOSAR-Standards [1] ist bei der Mercedes-Benz PKW Entwicklung seit eini-gen Jahren im Bereich Karosserie- und Innenraumfunktionen (Body&Comfort) etabliert. Damit ist es möglich, in immer kürzer werdenden Entwicklungszeiträu-men neue innovative Fahrzeugfunktionen in hoher Qualität zu realisieren. Auf-grund der zunehmenden Vernetzung und Verteilung von Fahrzeugfunktionen wird es immer wichtiger, bereits früh im Entwicklungsprozess das Zusammenspiel meh-rerer vernetzter und über Steuergeräte verteilte Funktionen durch Simulation ohne reale Hardware abzusichern.

Basierend auf der Technologie der modellbasierten Entwicklung unter AUTOSAR wird im vorliegenden Beitrag dargestellt, wie die geschilderten Herausforderungen bei der Mercedes-Benz PKW Entwicklung angegangen werden. Aus identifizierten Anwendungsfällen im Entwicklungsprozess werden Anforderungen an Methodik und Werkzeugrealisierungen abgeleitet. Anschließend werden die heutigen Gren-zen und zukünftige Herausforderungen bei der Modell-Erstellung und Simulation virtueller verteilter Systeme aufgezeigt, mit dem Ziel mögliche Lösungen mit der Fachwelt zu diskutieren.

1 Einführung

1.1 Entwicklung von Body&Comfort E/E-Systeme im Kraftfahrzeug

Das Bestreben den Fahrzeuginsassen ein Höchstmaß an Komfort und Sicherheit zu bie-ten führt zu kontinuierlichen innovativen Erweiterungen der Fahrzeug-Elektrik/Elektro-nik (E/E). Das Herzstück der Elektronik im Fahrzeug sind busvernetzte Steuergeräte – die so genannten ‚Electronic Control Units‘ kurz ‚ECUs‘. Ihre Softwareanteile steuern und regeln zusammen die Fahrzeugfunktionen im Verbund. Durch die steigende Anzahl von Fahrzeugfunktionen wächst folglich die Softwarekomplexität.

Karosserie und Innenraum E/E-Systeme (im Folgenden mit Body&Comfort-E/E-Systeme bezeichnet) sind charakterisiert durch stark verteilte und untereinander vernetz-

83

te Funktionen. Funktionsbestandteile eines typischen Body&Comfort-E/E-Systems, wie die des Innenlichtsystems (siehe Abbildung 1), sind auf bis zu 10 ECUs verteilt. Diese sind über mehrere, teilweise auch verschiedene serielle Bussysteme (CAN, LIN, FlexRay, zukünftig Ethernet) inkl. Gateways miteinander vernetzt.

Abbildung 1: Verteilung von E/E-Systemen

Diese verteilten Fahrzeugfunktionen werden, koordiniert vom Fahrzeughersteller, in Zusammenarbeit mit zahlreichen ECU-Lieferanten über einen Zeitraum von mehreren Jahren in einer verteilten Entwicklungsorganisation zur Serienreife entwickelt. Die Ent-wicklung dieser E/E-Systeme ist mit zahlreichen Herausforderungen verbunden (vergl. [3]). Das Bestreben nach kurzen Entwicklungszeiten und einer Reduktion von Erpro-bungsfahrzeugen erfordert eine ständige Effizienzsteigerung und führt daher zu einer kontinuierlichen Optimierung und Verbesserung der Entwicklungsmethodik und Werk-zeugunterstützung.

Die nachfolgend beschriebene Entwicklungsmethodik für eine modellbasierte E/E-Systementwicklung der Mercedes-Benz PKW-Entwicklung ist das Ergebnis einer seit vielen Jahren bestehenden Zusammenarbeit mit Werkzeugherstellern. Es werden die wesentlichen Evolutionsstufen dieser Entwicklung beschrieben, sowie die wichtigsten Anwendungsfälle der virtuellen Integration erläutert.

1.2 Modellbasierte Funktionsentwicklung

Seit der Einführung der modellbasierten Funktionsentwicklung im Jahre 2002 können Fahrzeugfunktionen frühzeitig parallel zur Lastenhefterstellung graphisch modelliert und als ausführbare Spezifikation durch Simulation validiert werden. Damit wird ein iterati-ves Vorgehen nach dem Prinzip ‚Build-a-little, Test-a-little‘ ermöglicht, welches früh die Funktion erlebbar macht und damit die Qualität der Lastenhefte steigert. Durch frühzei-tige Model-in-the-Loop (MIL) Tests der Funktionsmodelle und Software-in-the-Loop

CAN

LIN

Funktions-architektur

Vernetzungs-architektur

84

(SiL) Test auf Basis des daraus generierten Codes, kann schon früh die Qualität der generierten Funktionssoftware abgesichert werden. Die grafische Beschreibung erhöht die Verständlichkeit und erleichtert die Wartung und Weiterentwicklung der Funktionen. Durch eine strikte Vorgabe der Struktur der obersten Modellebenen gelingt es, die Funk-tionen in einer Vielzahl unterschiedlicher Fahrzeugbaureihen wiederzuverwenden und in immer kürzer werdenden Entwicklungszeiträumen neue innovative Fahrzeugfunktionen in hoher Qualität zu realisieren [3].

Die Funktionsanteile eines verteilten E/E-Systems, die auf einer ECU ausgeführt wer-den, werden jeweils als eigenständiges Simulink/TargetLink-Modell [4] [5] modelliert. Die Modelle werden anschließend zusammen mit den Lastenheften und weiteren Ent-wicklungsinformationen (wie Funktionsmodell-Schnittstellen und Konfigurationspara-meter) an die ECU-Lieferanten übergeben, die aus den Modellen Funktionssoftware generieren und zusammen mit der Basissoftware in die ECUs integrieren.

Mit der Verfügbarkeit der Funktionsmodelle entstand bereits früh der Wunsch, die auf den verschiedenen ECUs verteilte Funktionsbestandteile eines E/E-Systems gemeinsam ‚virtuell‘ zu integrieren und zu simulieren. Dies bietet die Chance, das Zusammenspiel frühzeitig zu erleben und durch Tests abzusichern [6], bereits bevor die Modelle an die verschiedenen ECU-Lieferanten übergeben werden. Der beschriebene Integrationsansatz wäre von Beginn an prinzipiell technisch möglich gewesen. Aufgrund von heterogenen Softwarearchitekturen und individueller Integrationsprozesse mit unterschiedlichen Beschreibungsformaten der Schnittstellen und Konfigurationsparameter bei den ver-schiedenen ECU-Lieferanten, wäre der Aufwand bei geringer Realitätsnähe der Simula-tionsergebnisse jedoch zu hoch gewesen.

Es folgte daraus die Erkenntnis, dass erst durch eine standardisierte Softwarearchitektur verbunden mit einheitlichen Beschreibungsformaten und durch einen standardisierten werkzeuggestützten Integrationsprozess die Voraussetzung für eine effiziente Nutzung der Methodik der virtuellen Integration im Rahmen eines Serienentwicklungsprozesses gegeben sind. Der hierfür verfolgte Ansatz wird im Folgenden aufgezeigt.

1.3 E/E-Systementwicklung unter AUTOSAR

Mit der Einführung des AUTOSAR-Standards bei der modellbasierten Funktionsent-wicklung [3] wurde eine eindeutige formale Beschreibung der Funktionsschnittstellen als Software-Components (SWC) nach dem AUTOSAR-ARXML-Austauschformat eingesetzt. Bei der anschließend fahrzeugweiten Einführung von AUTOSAR [7] wurde eine gleichartige, standardisierte Softwarearchitektur in allen ECUs der verschiedenen ECU-Lieferanten etabliert. Durch die Einführung eines systemorientierten Vernetzungs-prozess und Datenablage in einer zentralen Daimler-eignen Vernetzungsdatenbank XDIS wurde die Gesamtfahrzeug-Kommunikationsbeschreibung inkl. der Funktionszusam-menhänge in einem formalen Modell etabliert. Seither erfolgt der Datenaustausch mit den ECU-Lieferanten über das AUTOSAR-Format (dem ECU-Extract), in dem alle notwendigen Informationen (Funktionsmodell-Schnittstellen und Busvernetzungsinfor-mationen) einer ECU enthalten sind. Bei den ECU-Lieferanten erfolgt auf Basis dieses Austauschformats ein standardisierter werkzeuggestützter Integrationsprozess.

85

Über die Jahre wurde nach diesem Vorgehen der Umfang der Funktionsmodelle konse-quent ausgebaut, sodass heute ca. 60% der Body&Comfort-E/E-Systeme als AUTOSAR-Funktionsmodelle verfügbar sind. Schwerpunkt dieser in-house Modellie-rung sind die ‚Hauptfunktionalitäten‘ der jeweiligen E/E-Systeme, während ECU- und Sensor-/Aktor-nahe Funktionen überwiegend von den Lieferanten umgesetzt werden. Durch den beschriebenen AUTOSAR-Prozess ist die notwendige standardisierte Basis für eine effiziente virtuelle Integration verteilter Fahrzeugfunktionen gelegt.

Die nachfolgenden Abschnitte vertiefen verschiedene Aspekte der virtuellen Integration. Zunächst werden verschiedene Anwendungsfälle identifiziert sowie Anforderungen an Methodik und Werkzeugrealisierungen abgeleitet. Es folgt eine Darstellung der aktuellen Werkzeugkette. Anschließend werden auf Basis der Anwendungserfahrung die heutigen Grenzen und zukünftige Herausforderungen diskutiert.

2 Virtuelle Integration von Fahrzeugfunktionen

Die virtuelle Integration von Fahrzeugfunktionen beschreibt eine Methode, die es er-möglicht, ein Netzwerk von Softwarefunktionen, die auf unterschiedlichen ECUs eines Fahrzeugs verteilt sind, und die ihre Informationen über unterschiedliche Bussysteme miteinander austauschen, durch Simulation erleben und absichern zu können, in dem sie ohne eine vorhandene Zielhardware auf einer leistungsfähigen Hardware so realitätsnah wie nötig bzw. möglich simuliert werden. Die nachfolgenden Abschnitte vertiefen die verschiedenen Aspekte: beginnend mit Anwendungsfällen und Absicherungsmethoden wird auf den betrachteten Modellierungsumfang der AUTOSAR-Architektur eingegan-gen und daraus Anforderungen an eine Werkzeugunterstützung abgeleitet.

2.1 Anwendungsfälle

2.1.1 Funktionsentwicklung und Absicherung Die virtuelle Integration greift die beschriebenen Vorteile der modellbasierten Entwick-lung auf und erweitert sie um die Betrachtung von verteilten Funktionen, speziell in folgenden Anwendungsfällen: • Frühzeitige Konkretisierung der Spezifikation eines verteilten E/E-Systems.

Durch die frühe Modellierung und Simulation verteilter Funktionen werden neue Konzepte früh erlebbar. Damit kann frühzeitig das Verständnis der Funktion erhöht und durch das Feedback die Qualität der Spezifikation gesteigert werden.

• Feinabstimmung der verteilten Funktion während der Funktionsentwicklung als Fortsetzung der Idee ‚Build-a-little, Test-a-little‘ für vernetzte Funktionsmodelle. Im Laufe der Funktionsentwicklung können so die grundlegenden Design-Konzepte des verteilten E/E-Systems auf Basis der vorhandenen Modelle ohne reale ECU-Hardware integriert und abgesichert werden.

• Prozessbegleitende Absicherung der Modelle/Implementierung: Durchführung einer kontinuierlichen Qualitätssicherung (Continuous Virtual Integration mit Night-ly Build) im Entwicklungsprozess. So kann fortwährend die Integrationsfähigkeit

86

von Funktionsmodellen – auch verschiedener Funktionsmodellierer – abgesichert werden. Dies ist insbesondere dann vorteilhaft, wenn die einzelnen Modelle an-schließend an verschiedene ECU-Lieferanten übergeben werden.

2.1.2 HiL – Hardware in the Loop Neben der Funktionsentwicklung profitiert auch das ECU-Testing am Hardware-in-the-Loop (HiL) Testsystem von virtuellen Integrationsmodellen. Sie ermöglichen einen Zeitgewinn im Entwicklungsprozess, speziell in folgenden Anwendungsfällen: • Vorentwicklung von HiL-Tests: Bevor die reale Hardware verfügbar ist, können die

Tests bereits ‚gegen‘ die virtuelle ECUs entwickelt und erprobt werden. • Durchführung von systematischen Tests unter Anwendung umfangreicher HiL-

Testbibliotheken an virtuellen ECUs, bevor die realen ECUs verfügbar sind. • ‚Mischbetrieb‘ von virtuellen und realen ECUs: Nicht rechtzeitig angelieferte reale

ECUs werden durch virtuelle ECUs ersetzt, um den HiL-Testbetrieb insgesamt auf-recht zu erhalten.

2.2 Absicherungsmethoden

Bei der virtuellen Integration kommen verschiedene Methoden zur Absicherung zur Anwendung: • Zum einen bietet das interaktive Prüfen der Funktionen den Vorteil, schon früh die

verteilte Funktion graphisch und interaktiv erleben zu können (als Art ‚virtueller Prüf- und Messplatz‘). Dieser Anwendungsfall wird in der Spezifikationsphase zur Analyse des Systemverhaltens und während der Entwicklungsphase zur Fehlersuche eingesetzt.

• Zum anderen liefert das systematische Testen einen sehr wichtigen Beitrag für die Qualitätssicherung der verteilten Funktionen. Hierbei werden die schon vorgestellten Testmethoden auch bei der virtuellen Absicherung weiter angewandt. Dieser An-wendungsfall wird vorrangig während der Entwicklungsphase zur präventiven Quali-tätsabsicherung eingesetzt, um mögliche Implementierungsfehler in den Funktions-modellen zu vermeiden.

2.3 Modellierungsumfang der AUTOSAR-Architektur

Bei der virtuellen Absicherung steht die Betrachtung des Zusammenspiels von (Teil-) Funktionen, unter Berücksichtigung des Verhaltens der zugrundeliegenden AUTOSAR-Architektur, im Vordergrund. Hierbei sind mehrere Abstraktionsebenen relevant: • In frühen Phasen entsteht als erstes die Funktionsvernetzung der Software-

Komponenten inklusive der Modelle als sog. AUTOSAR-Composition. Das Funkti-onsverhalten kann dann auf Basis der AUTOSAR-Architektur auf dem sehr abstrak-tem Niveau des AUTOSAR Virtual Functional Bus (VFB) dargestellt und simuliert werden. Damit sind generelle funktionale Zusammenhänge erlebbar, ohne eine Be-achtung der Einflüsse, die sich durch eine Funktionsverteilung auf ECU’s ergeben.

• Bei Verfügbarkeit der AUTOSAR-ECU-Extracts können die Funktionsmodelle in ihrem jeweiligen ECU-Kontext integriert werden, wodurch zusätzlich auch die Be-

87

rücksichtigung der Buskommunikation möglich ist. Auf dieser Basis können grund-legende Aspekte des Zeitverhaltens der verteilten Funktion in die Simulation mit ein-bezogen werden, wie z.B. Sendearten, Zykluszeiten der Nachrichten, Latenzen durch die Busprotokolle wie LIN oder CAN. Der Schwerpunkt liegt hierbei auf dem mak-roskopischen Zeitverhalten des E/E-Systems; von den realen Ausführungszeiten der Zielhardware wird abstrahiert. Die Funktionsreaktion beim Einstreuen von Netz-werkfehlern, wie beispielweise der Ausfall von Nachrichten, kann beobachtet wer-den.

• Zusätzlich kann bei Verfügbarkeit der AUTOSAR-ECU-Extracts das Funktionsver-halten bezüglich der Basissoftware-Services betrachtet werden (wie z.B. die Anbin-dung an Statemanager, NVRAM, Diagnose etc.). Damit sind auch Startup/Shutdown-Vorgänge darstellbar und simulierbar. Auf diese Weise können wichtige Elemente der Systemkonfiguration einer ECU überprüft werden.

2.4 Anforderungen an die Werkzeugunterstützung

Die Anwendungsfälle der virtuellen Integration stellen sehr konträre Anforderungen an die Methodik und zu schaffenden Werkzeugunterstützung. Abbildung 2 versucht das entstehende Spannungsfeld zu verdeutlichen:

Detailgenauigkeit/Skalierbarkeit: Für belastbare Simulationsergebnisse ist eine hohe Detailgenauigkeit derjenigen Aspekte notwendig, die virtuell abgesichert werden sollen. • Es hat sich gezeigt, dass insbesondere das Modell der Basissoftware bzgl. Kommuni-

kation und Buskommunikation möglichst exakt dem realen Verhalten entsprechen muss. Besonders wichtig ist das Sendeverhalten von Nachrichten wie Zykluszeiten, Mindest-Sendeabstände, etc. Um bei der Fehlersuche und bei der Systemvalidierung ‚Phantomfehler‘ in der Basissoftware weitgehend auszuschließen, sollte hierfür eine validierte Basissoftware eingesetzt werden. Wenn möglich, sollten wesentliche An-teile der ‚echten‘ Seriensoftware und ihre Konfigurationswerkzeuge verwendet wer-den.

• Zur Unterstützung verschiedener Entwicklungsphasen und der Genauigkeitsanforde-rungen an die virtuelle Umgebung wird eine Art ‚Stellschraube zur Wahl der Abs-traktion‘ benötigt, mit der die Genauigkeit und Tiefe der Modellierung eingestellt werden kann, ohne dass das Werkzeugkonzept gewechselt werden muss.

• Um sich bei der Absicherung von Funktionen auf die jeweilige Problemstellung konzentrieren zu können, ist es notwendig die Systeme, flexibel skalieren bzw. frei-schneiden zu können und so die Aufwände für die Inbetriebnahme auf das absolut notwendige zu beschränken.

• Neben der Simulation auf dem PC (ggf. auch schneller als Echtzeit) ist auch die Möglichkeit zur Verbindung mit realen Steuergeräten über einen realen Busanschluss notwendig, um während der Produktentwicklungsphase einen Mischbetrieb von vir-tuellen und realen ECUs zu ermöglichen. Hieraus ergeben sich entsprechende Echt-zeit-Eigenschaften für die virtuelle Plattform.

Aufwand (Easy-to-Use): Die Werkzeuge zur Erstellung der Integrationsmodelle und zur Simulationsdurchführung müssen durch Entwicklungsingenieure bedienbar sein, die

88

während der Spezifikations- und Produktentwicklungsphase viele weitere Aufgaben gleichzeitig wahrnehmen müssen. • Die Methode muss für den Anwenderkreis der Systementwickler ohne tiefes Exper-

tenwissen bzgl. der AUTOSAR-Basissoftware anwendbar sein. • Um die Akzeptanzschwelle zu verringern, sollte auf Bedienkonzepte bekannter

Werkzeuge zurückgegriffen werden. • Die Simulationsmodell-Erstellung sollte so weit wie möglich mit den Artefakten des

Automobilherstellers auskommen. Die Verwendung von ECU-Zulieferer-Artefakten ist grundsätzlich möglich, würde aber große Abhängigkeiten im Prozess erzeugen und damit Verzögerungen verursachen. Fehlende – für die Absicherung notwendige Funktionsanteile – sollten durch die Werkzeugumgebung generiert werden können.

Reaktionszeit: Die Methode muss sich in den sehr engen zeitlichen Entwicklungsablauf der Serienentwicklung einfügen. • Nach einer initialen Erstellungsphase muss ein Integrationsmodell innerhalb weniger

Stunden erstellt werden können, damit die gewonnen Erkenntnisse während des ak-tuellen Entwicklungszyklus dazu beitragen können, mögliche Fehlfunktionen abzu-stellen. Eine vollständige Automatisierung aller Konfigurationsaufgaben ist damit zwingend notwendig.

Abbildung 2: Spannungsfeld virtuelle Integration

3 Werkzeugumgebung und Simulationsmodell

3.1 Werkzeugumgebung

Auf Basis der genannten Anforderungen wurde in den letzten Jahren eine erste Werk-zeugumgebung für die virtuelle Integration zusammen mit Toolherstellern entwickelt [8]. Die Zielsetzungen ist hierbei, das genannte Spannungsfeld für die genannten An-wendungsfälle auszupendeln: Einstellbare Detailgenauigkeit bei geringem Konfigurati-onsaufwand und vollständiger Automatisierung. Die Werkzeugkette besteht aus vier wesentlichen Bestandteilen (siehe Abbildung 3):

Aufwand

Detailgenauigkeit

Reaktionszeit

Spannungsfeld virtuelle

Integration

89

Die Datenbereitstellung erfolgt durch die Werkzeuge des Serien-Entwicklungs-prozesses der modellbasierten Entwicklung. Das Daimler Vernetzungswerkzeug XDIS stellt die AUTOSAR-ECU-Extracts bereit; von MATLAB-Simulink/TargetLink stam-men die Funktionsmodelle. Eine vorgeschaltete Web-Applikation ermöglicht es den Serienanwendern, einfach definierte Konfigurationen aus ECU-Extract und Funktions-modell-Ständen zusammenzustellen, und so definierte virtuelle ECU-Releases zu konfi-gurieren. Mit einem selbst entwickelten kommandobasierten AUTOSAR-Werkzeug (sog. ARXML-Wizard) werden fehlende Artefakte im ECU-Extract ergänzt. Das Werk-zeug bietet darüber hinaus die Flexibilität, Konstrukte im ARXML so anzupassen und zu erweitern, dass sie vom nachfolgenden Integrationswerkzeug verarbeitet werden können.

Ein kommerzielles AUTOSAR-Werkzeug zur virtuellen Integration (vVIRTUALtar-get [9]) übernimmt die Erstellung der virtuellen ECUs auf Basis der bereitgestellten Ausgangsdaten (erweiterte ECU-Extract und SWC-Code). Optional können die Runnab-le-Ablauf-Reihenfolge und das Service-Mapping zusätzlich vorgegeben werden. Diese Informationen sind ausreichend, um damit vollständig automatisiert – unter Zuhilfenah-me der Serienwerkzeuge zur Konfiguration des BSW-Stacks – virtuelle ECUs zu gene-rieren. Einmal in Betrieb genommen und konfiguriert, wird der gesamte Build-Ablauf vollständig automatisiert durchlaufen. Im Falle einer Änderung der Ausgangsdaten wird stets der gesamte Build-Ablauf neu durchlaufen, da Änderungen komplexer zu behan-deln wären als Neugenerierungen.

Abbildung 3: Werkzeugumgebung

Als Simulationswerkzeug, Prüf- und Debugg-Umgebung kommt das seit langem für die Entwicklung busvernetzter Steuergeräte etablierte Werkzeug CANoe [10] zum Ein-satz. Die erstellten virtuellen ECUs fügen sich als Simulationsknoten in eine CANoe-Simulationsumgebung ein. Sie enthalten neben dem Funktionscode reale AUTOSAR-Basissoftwareanteile. Die bereits aus der bisherigen Anwendung der ‚Restbussimulation‘ bekannten Programmierschnittstellen können auch für virtuelle ECUs eingesetzt werden. Die Simulationsausführung kann angehalten und der Funktionscode untersucht und kor-rigiert werden. Umgebungsmodelle können direkt als CAPL-Programme oder unter

90

Verwendung des Simulink-CANoe-Blockset eingebunden werden. Über die bekannten Hardwareschnittstellen ist eine Verbindung zu realen Steuergeräten gegeben, womit ein Mischbetrieb zwischen virtuellen und realen ECUs ermöglicht wird.

Zusätzlich ist eine Anbindung an etablierte Testwerkzeuge realisiert. Durch die Anbin-dung des Werkzeugs TPT [11] ist die Voraussetzung für eine Verwendung der virtuellen Integration im Modellierungsumfeld geschaffen. Mit der Anbindung des Werkzeugs PROVEtech:TA [12] wird die Durchgängigkeit bzgl. der Verwendung bei HiL-Tests ermöglicht.

3.2 Integrationsmodell eines verteilten E/E-Systems

In Abbildung 4 ist beispielhaft ein virtuelles Integrationsmodell eines verteilten E/E-System skizziert. Es besteht aus einer Menge virtueller ECUs, die auch über virtuelle Gateways verbunden sein können. Neben den Basissoftware-Modulen enthalten die ECUs eine Auswahl relevanter SWCs (Funktionsmodelle), die das ‚System under Test’ definieren. Andere SWCs auf den ECUs sind bewusst entfernt, um unnötige Komplexität und Abhängigkeiten im Bereitstellungsprozess zu reduzieren. Umfänge die die ECU-Lieferanten im Serienprozess selbst übernehmen, werden entweder nach einem vorgege-ben Schema vereinfacht generiert oder bewusst weggelassen. So wird die Anbindung an das Ecu- und Com-Statemanagement, sowie das NVRAM-Veralten als Applikations-SWC nachgebildet. Das Runnable-Task-Mapping beruht zunächst auf Annahmen und wird im laufenden Entwicklungsprozess durch die konkrete Konfiguration der ECU-Lieferanten präzisiert. Auf die Anbindung an Aktoren/Sensoren oder die Diagnosesoft-ware wird aktuell bewusst verzichtet. Stattdessen stehen für die Funktionsstimulation und Beobachtung offene SWC-Ports als Bedien- und Testschnittstellen zur Verfügung.

Abbildung 4: virtuelles Integrationsmodell eines verteilen E/E-Systems mit Bedienschnittstelle

4 Praxiserfahrungen

Die Methode der virtuellen Integration wurde in den letzten Jahren intensiv entwickelt und eingesetzt. Viele der Erfahrungen sind dabei bereits in die Definition der Anwen-

91

dungsfälle und in die Werkzeugumgebung eingeflossen (vergl. vorhergehende Abschnit-te). Nachfolgend sind weitere Praxiserfahrungen und offene Punkte aufgeführt.

Anwendung an Pilotprojekten: Die Methode wurde in den letzten Jahren erfolgreich bei der Entwicklung eines neuartigen Innenlichtsystems angewandt. Hierbei konnte die Praxistauglichkeit der frühzeitigen, kontinuierlichen und prozessbegleitende Integration und Absicherung verteilter Fahrzeugfunktionen unter Beweis gestellt werden. So wurden schon frühzeitig grundlegende funktionale Zusammenhänge modelliert und simuliert. Dabei konnte das Systemverständnis in dieser frühen Entwicklungsphase substanziell erhöht werden. Nach einer längeren Inbetriebnahmephase konnten durch die automati-sierte Integration sehr kurze Absicherungszyklen (mehrere Integrationen und Testdurch-läufe pro Tag) realisiert werden.

AUTOSAR-Standard: AUTOSAR stellt eine geeignete Infrastruktur für eine effiziente Integration und Absicherung von verteilten Funktionen bereit. Der eingesetzte Standard in der Version 3.2 bietet umfangreiche Unterstützung, deckt aber in Randbereichen nicht alle erforderlichen Aspekte ab. Der fehlende Umfang in diesen Randbereichen verur-sacht aktuell den Hauptaufwand bzgl. der vollständigen Automatisierung der virtuellen Integration. Fehlende Funktionalitäten wurden in die AUTOSAR 4.2-Spezifikation ein-gespeist, mit dem Ziel, zukünftig die Funktionsintegration zu 100% AUTOSAR-konform darstellen zu können und damit die Integration sowohl im realen Serienprozess, als auch bei der virtuellen Integration, weiter zu vereinfachen. Eingebrachte Verbesse-rungen finden sich insbesondere im Bereich der NVRAM- und Diagnose-Anbindung.

Prozess-Anforderungen: Die Methode basiert darauf, bereits früh im Entwicklungspro-zess formale Modelle zu erstellen. Sie erfordert deshalb hohe Disziplin und formales Vorgehen bereits in frühen Entwicklungsphasen. Dazu ist es notwendig, virtuelle ECU-Releases im zeitlichen Entwicklungsablauf explizit einzuplanen. Hierbei sind entspre-chende Zeitpunkte vorzusehen, zu denen AUTOSAR-Beschreibungen, Modelle und Parametersätze zueinander konsistent bereitgestellt werden. Zusätzlich muss der Ent-wicklungsprozess so gestaltet werden, dass bei einer virtuellen Validierung gefundene Modellfehler noch vor der Übergabe der Modelle an die ECU-Lieferanten eingearbeitet werden können, um so die bisher typische Fehlerabstellung – erst beim nächsten folgen-den Entwicklungszyklus – zu vermeiden.

Inbetriebnahme: Eine neue Integrationsebene erfordert auch neue Erfahrung mit ihrer Handhabung bei der Konfiguration, Simulation und Testdurchführung. Die Modellerstel-lung ist automatisiert; die Inbetriebnahme der verteilten E/E-Systeme in der Simulation gestaltet sich teilweise noch aufwändig. Gründe hierfür liegen darin, dass einerseits die Simulationsumgebung für die Systemexperten/Entwicklungsingenieure noch komplex ist und andererseits die Werkzeugexperten relativ wenig Systemverständnis besitzen. Diese Lücke muss zukünftig weiter geschlossen werden, in dem die Simulationsumgebung so anwenderfreundlich ausgestaltet wird, dass sie von Systemexperten mit wenig Einarbei-tungsaufwand beherrscht werden kann.

Werkzeugunterstützung: Der Umgang mit Änderungen im gesamten Werkzeugkon-zept, wie schrittweise Erweiterung des ‚Systems-unter-Tests-Umfangs’ gestaltet sich

92

insgesamt noch aufwändig. Hierzu müssen an einigen Stellen konsistent Veränderungen vorgenommen werden (Zuschnitt der ARXML, Umgebungsmodell, Testmodelle etc.). Hier sind weitere Optimierungen und ein integrierter Werkzeugansatz notwendig, wel-cher die Abhängigkeiten zwischen einzelnen Artefakten berücksichtigt und schnelle Änderungszyklen ermöglicht. Dazu zählt auch, dass neben der virtuellen Integration auf C-Code Basis, eine virtuelle Funktionsintegration direkt in der eingesetzten Funktions-modellierungsumgebung (wie z. B. Simulink und Stateflow) ermöglicht wird. Die aktu-ell vorhandenen Beschreibungs- und Simulationsmöglichkeiten sind dazu noch grundle-gend im Hinblick auf eine verteilte AUTOSAR-Architektur zu erweitern.

5 Zusammenfassung und Ausblick

Die virtuelle Integration erweitert die modellbasierte Funktionsentwicklung um eine Methode der frühen prozessbegleitenden Absicherung verteilter Funktionen unter An-wendung des AUTOSAR-Standards. Die Methode wird aktuell an mehreren E/E-Systemen während der Serienentwicklung angewandt, mit dem Ziel weitere Erfahrung bei der Anwendung im Serienbetrieb zu erlangen und die Prozessintegration weiter vo-ranzutreiben. Für eine breitflächigere Etablierung der Methode ist aus den bisherigen Erfahrungen insbesondere ein weiterer Ausbau der Werkzeugumgebungen hin zu einem integrierten Gesamtansatz für die virtuelle Integration und Absicherung notwendig, der von der Tool-Komplexität abstrahiert und den Blick das Wesentliche – auf das verteilte E/E-Systemverhalten – freimacht.


[1] AUTOSAR GbR: http://www.autosar.org [2] C. Dziobek, Th. Ringler, F. Wohlgemuth: Herausforderungen bei der modellbasierten Ent-

wicklung verteilter Fahrzeugfunktionen in einer verteilten Entwicklungsorganisation, Ta-gungsband Dagstuhl-Workshop MBEES Modellbasierte Entwicklung eingebetteter Systeme, Februar 2012

[3] F. Wohlgemuth, C. Dziobek, Th. Ringler: Erfahrungen bei der Einführung der modellbasier-ten AUTOSAR-Funktionsentwicklung, Modellierung Berlin, März 2008

[4] http://www.mathworks.de/products/simulink/ [5] http://www.dspace.de [6] Th. Ringler, Modeling and Simulation of Distributed Automotive Systems with Simulink®,

IAC 2006, The MathWorks International Automotive Conference, May 16-17, 2006, Stuttgart

[7] S. Schmerler et. al.: Mit AUTOSAR zu einem integrierten und durchgängigen Entwick-lungsprozess, 15. Internationaler Kongress Elektronik im Kfz, Baden-Baden, Okt. 2011

[8] Th. Ringler: Virtual Integration and Test of AUTOSAR Systems at Daimler – Body & Com-fort Domain, Vector Congress, November 2014

[9] R. Marktl: Virtuelle Integration und Test von AUTOSAR Systemen – Der Lösungsansatz von Vector: vVIRTUALtarget, Vector Congress, November 2014

[10] http://www.vector.com [11] PikeTec GmbH: TPT – Time Partition Testing, www.piketec.com [12] MBtech Group, PROVEtech:TA: http://www.mbtech-group.com

93

http://www.dspace.de/

http://www.dspace.de/

http://www.piketec.com/

http://www.mbtech-group.com/

Problemstellungen bei der Entwicklung von Ladegeräten

für Elektro- und Hybridfahrzeuge

Markus Cordero, Ulrich Nickel

Software Engineering Department

Delta Energy Systems GmbH

Coesterweg 45

59494 Soest

[email protected]

[email protected]

Abstract: Obwohl die Absatzzahlen für Elektro- und Hybridfahrzeuge weiterhin

stark hinter den Erwartungen zurückbleiben, zeigt sich jedoch, dass die

Grundtendenz aus Sicht der Automobilindustrie weiterhin in diese Richtung geht.

Im Fokus stehen hier aktuell sogenannte Plug-In Hybridfahrzeuge (PHEV) und

reine Elektrofahrzeuge (BEV). Beiden Fahrzeugtypen ist gemein, dass sie über

eine Hochvoltbatterie verfügen, welche über das Stromnetz aufgeladen werden

kann. Hierfür sind die Fahrzeuge mit einem entsprechenden Ladegerät - einem On-

Board Charger (OBC) - ausgestattet. Das vorliegende Papier soll den Aufbau und

die Funktionsweise eines solchen Ladegerätes erläutern und dabei auf wichtige

Problemstellungen bei der Entwicklung eingehen. Ziel ist es, das System

"Ladegerät" als eine mögliche Fallstudie für zukünftige Forschungsarbeiten

vorzustellen.

1 Einleitung und Motivation

Plug-In Hybridfahrzeuge und Elektrofahrzeuge zeichnen sich dadurch aus, dass sie über

eine Hochvoltbatterie verfügen, welche über einen Hochvolt-Bus den Elektromotor oder

auch die Klimaanlage versorgt. Damit ein Aufladen am heimischen Stromnetz oder auch

einer Ladesäule möglich wird, ist in den Fahrzeugen ein AC/DC-Ladegerät (Onboard

Charger, OBC) verbaut, welches eine 100-250V Eingangsspannung in eine 400V

gleichgerichtete Ausgangsspannung transformiert. Alternativ gibt es auch Lader welche

das DC/DC-Laden unterstützen. Darauf soll hier aber nicht weiter eingegangen werden.

Abbildung 1 zeigt das grundsätzliche Prinzip, nach dem Elektrofahrzeuge (Electrical

Vehicles, EV) an die Infrastruktur (Electrical Vehicle Supply Equipment, EVSE)

angeschlossen werden. Danach ist es einerseits möglich das EV mittels üblicher

Einphasen- oder Dreiphasensteckdosen über ein (spezielles) Ladekabel zu laden.

Weiterhin ist der Anschluss an spezielle Ladesäulen möglich. In der IEC 61851

[IEC10] sind unterschiedliche Lademodi spezifiziert, welche den maximal möglichen

Ladestrom und die Interaktion zwischen EVSE und EV definieren. So wird zur

94

Steckererkennung als auch der Bestimmung der Belastbarkeit des Kabels das sogenannte

Proximity Signal definiert. Weiterhin kann über das Control Pilot Signal (CP) dem

Ladegerät vom EVSE der verfügbare Ladestrom übermittelt werden. Hierzu ist ein

entsprechender Generator notwendig, welcher ein PWM Signal erzeugt. Weitergehende

Konzepte sehen vor, dass über Powerline Kommunikation Plug- and Charge Dienste

realisiert werden.

Abbildung 1 Anschluss eines EV (nach IEC61851)

Im den folgenden Kapiteln wird der interne Aufbau eines AC/DC-Laders, im weiteren

Verlauf als Onboard Charger (OBC) bezeichnet, näher erläutert. Hierbei handelt es sich

um ein System, welches aus mehreren Mikrocontrollern besteht. Diese realisieren die

Steuerung des Gesamtverhaltens und die Kommunikation zur Infrastruktur bzw. zum

Fahrzeug (CAN). Weiterhin wird die Leistungselektronik des hier betrachtete OBC voll

digital geregelt. Das bedeutet, dass diese Funktion ebenfalls von Mikrocontrollern

(DSPs) realisiert wird. Dadurch entstehen komplexe Abhängigkeiten zwischen der

Software, der digital geregelten Leistungselektronik und dem Gesamtsystem, in die das

Ladegerät eingebettet ist.

Der Schwerpunkt wird auf Schwierigkeit der Diagnose von Fehlerzuständen gelegt. Die

Komplexität begründet sich einerseits durch Anzahl der möglichen Fehlerzustände,

welche teilweise voneinander abhängen. Andererseits müssen Probleme durch

Laufzeitabhängigkeiten berücksichtigt werden, welche durch die Verteilung der

Funktionalität auf mehrere Mikrocontroller noch begünstigt werden.

95

2 Aufbau eines Ladegerätes für Elektro- und Hybridfahrzeuge

Innerhalb eines Onboard Chargers (OBC) gibt es unterschiedliche Spannungspotentiale:

das AC Potential zur Netzseite, das DC Potential zur Hochvoltbatterie und das LV

Potenzial zum 12V Fahrzeug-Bordnetz. Diese müssen voneinander galvanisch getrennt

sein. Die Systemarchitektur ist hierbei so gewählt, dass auf jedem Potential mindestens

ein Controller zur Messdatenerfassung und zur Ansteuerung der jeweiligen Aktuatoren

verwendet wird. Abbildung 2 zeigt den schematischen Aufbau als Blockschaltbild.

Abbildung 2: Systemarchitektur OBC

Auf dem AC Spannungspotential befinden sich Messkreise zur Erfassung von

(Eingangs-)Strom und Spannung, ein Gleichrichtermodul, ein Leistungsschaltermodul

zur Blindleistungsreduktion (Power Factor Correction, PFC) und eine

Zwischenkreiskapazität (Bulk Capacity). Das Gleichrichtermodul und das

Leistungsschaltermodul werden durch den AC Controller (DSP) digital geregelt.

Auf dem DC Spannungspotential befinden sich Messkreise zur Erfassung von Strom und

Spannung, ein Leistungsschaltermodul zur Transformation der Zwischenkreisspannung

des AC Potentials in eine strom- und spannungsgeregelte Gleichspannung auf DC

Potential, welche den Bus zur Hochvolt-Batterie versorgt. Die DC/DC-Vollbrücke wird

hier vom DC Controller (DSP) geregelt.

96

Auf dem Spannungspotential des Fahrzeuges befinden sich der sogenannte Com

Controller und der Wakeup Controller, sowie Messkreise zur Erfassung von

Ladeinfrastruktursignalen und Aktuatoren.

Der Com Controller bildet das Fahrzeuginterface. Zu den Aufgaben gehören die

Anbindung an die Fahrzeugkommunikation über CAN, die Anbindung an die

Kundendiagnose und die Überwachung der Signale der Lade-Infrastruktur (EVSE).

Dazu gehört das Control Pilot Signal (CP), über welches die Ladestation über ein PWM

Signal per Duty Cycle den maximalen Ladestrom der Infrastruktur vorgibt. Außerdem

das bereits erwähnte Proximity Signal, das dem OBC die Strombelastbarkeit des

Anschlusskabels vorgibt und ggf. eine Powerline Kommunikation zum erweiterten

Datenaustausch zwischen Fahrzeug und Ladeinfrastruktur. Weiterhin übernimmt der

Com Controller die Ansteuerung der Verriegelung der Fahrzeug Steckdosenklappe, die

Verriegelung des AC Steckers und die Ansteuerung einer optischen LED

Betriebszustandsanzeige. Schlussendlich übernimmt der Com Controller auch die

übergeordnete Ladesteuerung. Hierzu wertet er über den Fahrzeug-CAN empfangene

Betriebszustandsvorgaben, als auch diverse gemessene interne und externe

Temperaturen, sowie die Signale/Vorgaben der Ladeinfrastruktur aus und ermittelt

daraus die Leistungsvorgaben für die digitale Regelung. Diese werden dem AC

Controller und dem DC Controller über die interne Kommunikation (UART) übermittelt.

Der AC Controller steuert die Vorladefunktion der internen Zwischenkreiskapazität

(Bulk Capacity) und erzeugt mittels Regelung des AC Leistungspfades eine

Phasengleichheit von Spannung und Strom. Mittels der Leistungsvorgaben des Com

Controllers wird der aufgenommene AC Strom auf einen maximalen Wert begrenzt.

Hierfür wird die Leistungsbereitstellung in den Zwischenkreis reduziert und zum

anderen die Leistungsvorgabe für den DC Controller reduziert. Weiterhin erfüllt der AC

Controller Überwachungsfunktionen seiner Sensoren und Aktuatoren, sowie die

Datenerfassung von Strom, Spannung, Frequenz und Temperatur und deren Weitergabe

über die interne Kommunikationsschnittstelle an den Com Controller.

Der DC Controller regelt die Ausgangsspannung und den Ausgangsstrom aufgrund der

Leistungsvorgabe des AC Controllers und der Vorgaben des Com Controllers.

Außerdem erfüllt der DC Controller Überwachungsfunktionen der hochvoltseitigen

Sensoren und Aktuatoren, sowie die Datenerfassung von Strom, Spannung und

Temperatur und deren Weitergabe über die interne Kommunikationsschnittstelle an den

Com Controller.

Der Wakeup Controller ist notwendig um die Ruhestromanforderungen im Automotive

Umfeld zu erfüllen. Im Ruhestrombetrieb des OBC sind der Com Controller, der AC

Controller und der DC Controller nicht mit Spannung versorgt. Der Wakeup Controller

übernimmt die Aufgabe, die Signale der Infrastruktur auf Änderung zu überwachen und

ggf. den Com Controller zu starten.

97

3 Diagnose von Steuergeräten

Der im vorherigen Kapitel beschriebene Aufbau eines OBC verdeutlicht, dass es sich

hierbei um ein komplexes System handelt. Für die Entwicklungsphase und später auch

den Fahrzeugservice kommt daher der Diagnose von Fehlfunktionen zur Laufzeit eine

besondere Bedeutung zu. Die sogenannte Onboard Diagnose soll die sichere Erkennung

und Beseitigung von Fehlern ermöglichen. Daher stellt diese auch ein zentrales Element

von Steuergeräten im Automobilbereich dar.

Das Auftreten einer Fehlfunktion wird der Diagnosefunktionalität des OBC mittels eines

„Diagnostic Trouble Codes“ (DTC) gemeldet. Die Diagnosefunktion des OBC verlangt

die eindeutige Zuordnung der Fehlerquelle (DTCs), damit eine sichere Analyse und auch

die eindeutige Definition von Reparaturmaßnahmen möglich werden. Dies bedeutet

auch, dass weitere Fehlermeldungen durch direkte Folgefehler vermieden werden

müssen. Zu jedem DTC müssen eine eindeutige Setzbedingung und ebenfalls eine

eindeutige Rücksetzbedingung (falls der Fehler nicht mehr anliegt) definiert werden.

Grundlage für das Ableiten von DTCs kann eine durchgeführte FMEA, als auch die

Betrachtung der vorhandenen internen und externen Sensoren und Aktuatoren sein. Die

DTCs werden anhand der Schnittstellenbeschreibungen, Sensoren und Aktuatoren

zumeist textuell beschrieben. Hierbei wird für jeden Sensor eine Menge von DTCs

angelegt (z. B. Kurzschluss nach Plus, Kurzschluss nach Masse, Open Load).

Die systemischen Abhängigkeiten der Sensoren untereinander sind hierbei nicht immer

offensichtlich und werden erst während der Testphase erkannt. Dies führt häufig zu

späten Konzeptänderungen. Beispielhaft sei hier erwähnt, dass ein OBC bis zu 400

DTCs besitzen kann. Je nach OBC Variante und Kundenvorgaben können diese in der

Anzahl und Komplexität variieren. Späte Änderungen führen damit zu einem hohen

zusätzlichen Entwicklungsaufwand, da viele Abhängigkeiten betrachtet werden müssen.

Dies soll nachfolgend anhand eines Beispiels verdeutlicht werden.

In dem Beispiel gehen wir davon aus, dass seitens der EVSE die AC Spannung ausfällt.

Wenn dies geschieht, dann muss in unserem OBC der AC Controller den Fehler (DTC)

„AC Intermittent“ erkennen. Da der AC Controller auf dem AC Potential liegt, kann er

diesen Ausfall schnell genug erkennen und ist somit in der Lage eine Abschaltung der

AC Leistungsstufe einzuleiten. Prüfvoraussetzung ist, dass der AC Controller aktiv ist.

Die sofortige Abschaltung der AC Leistungsstufe führt dazu, dass der AC Leistungspfad

keine Energie mehr in den OBC internen Zwischenkreis liefert. Die DC Leistungsstufe

entnimmt weiterhin Energie aus dem Zwischenkreis. Sobald die Spannung im

Zwischenkreis unterhalb eines Schwellwertes abfällt, wird aber der AC Controller einen

weiteren DTC „Bulk Undervoltage“ erkennen und ggf. setzen.

Durch das Absinken der Zwischenkreisspannung steigt der Strom innerhalb der DC

Ausgangsleistungsstufe an, um die Ausgangsleistung stabil zu halten. Sobald der Strom

einen unzulässig hohen Grenzwert überschreitet, muss der DC Controller den DTC „DC

Rail Overcurrent“ erkennen und setzen.

98

Des Weiteren führt der Ausfall der AC Spannung dazu, dass der CP Frequenzgenerator

innerhalb der EVSE nach einer nicht definierten Zeit ebenfalls ausfällt (der CP

Generator wird nicht mehr versorgt). Da das CP Signal auf Bordnetzpotential liegt, muss

die Erkennung auf dem Com Controller erfolgen. Der Com Controller muss den DTC

„CP Intermittent“ setzen.

Dieses Beispiel zeigt zunächst, dass der Ausfall der AC Versorgungsspannung neben

dem ursächlichen Fehler (AC Intermittend) eine Reihe von unerlaubter Folgefehler

auslöst (Bulk Undervoltage, DTC Rail Overcurrent, CP Intermittent). Dies gilt es im

Vorfeld durch eine Analyse zu erkennen.

Eine weitere Problemstellung ergibt sich durch die Laufzeiten innerhalb des OBC. Geht

man davon aus, dass der AC Controller den Wegfall der AC Spannung erst nach einer

definierten Entprellzeit erkennt und diesen dann über die internen UART Bus verzögert

an den Com Controller meldet, so kann es durchaus sein, dass der Com Controller vorher

den Wegfall des CP Signals erkennt (je nach dem Zeitpunkt des Wegfalls). Damit würde

„CP Intermittend“ ggf. nicht mehr als Folgefehler interpretiert und der entsprechende

DTC gesetzt. Um den korrekten DTC zu melden zu können, müssen also die zeitlichen

Abläufe der unterschiedlichen Controller, der internen Kommunikation, der HW

Schaltungen und des äußeren Systems berücksichtigt werden.

4 Fazit

Bei der Entwicklung des hier betrachteten OBCs kommen unterschiedlichste Werkzeuge

zum Einsatz. Neben der Anforderungsspezifikation werden auch die Schnittstellen sowie

die Spezifikation der Diagnose (DTCs) textuell innerhalb des Anforderungsmanagement

Systems IBM Rational DOORS durchgeführt. Die Systemmodellierung sowie Teile der

Software-Architektur und des Software-Feindesigns werden in SysML/ UML erstellt.

Die Software Architektur für die Autosar Anteile auf dem Com Controller wird separat

mit dem Werkzeug DaVinci Developer (Vector Informatik GmbH) modelliert. Für

einige Software Komponenten wird der Code aus Matlab/Simulink-Modellen generiert.

Der Reglerentwurf und die Modellierung der Regelstrecke werden im Tool Simplorer

der Firma Ansys (www.ansys.com) erstellt.

Die Vielzahl der verwendeten Werkzeuge, Modelle und Notationen macht eine

übergreifende Betrachtung schwierig. Dies ist aber, wie in Kapitel 3 verdeutlicht,

notwendig. Insbesondere die rein textliche Spezifikation der Diagnose reicht nicht aus,

die vorhandenen Abhängigkeiten zu erkennen. Unser Ziel ist es daher, einen geeigneten

Lösungsansatz zu finden, welcher eine Analyse oder Simulation bereits zur

Spezifikations- und Entwurfsphase ermöglicht.


[IEC10] IEC 61851-1: Electric vehicle conductive charging system – Part 1: General

Requirements Edition 2.0. November 2010.

99

http://www.ansys.com/

Deployment Calculation and Analysis for a Fault-TolerantSystem Platform

Klaus Becker, Bernhard Schatz

fortiss GmbHAn-Institut Technische Universitat Munchen

Guerickestr. 25, 80805 Munchen{becker, schaetz}@fortiss.org

Abstract: In many embedded systems like in the automotive domain, safety-criticalfeatures are increasingly realized by software. Some of these features are often re-quired to behave fail-operational, meaning that they must stay alive even in the pres-ence of random hardware failures.

In this paper, we introduce a constraint-based approach to calculate valid deploy-ments of mixed critical software components to the execution nodes of a new fault-tolerant SW/HW architecture for electric vehicles. To avoid harm, faulty executionnodes have to be isolated from the remaining system. We treat the changes to the de-ployment that are required after isolations of execution nodes to keep those softwarecomponents alive that realize fail-operational features. However, the remaining sys-tem resources may become insufficient to execute the full set of software componentsafter such isolations. Hence, some components might have to be deactivated, meaningthat features might get lost. Our approach allows to formally analyze which subset offeatures can still be provided after one or more isolations. We present an arithmeticsystem model of the deployment problem that can be solved by an SMT solver.

1 Introduction and Motivation

Many embedded systems are operated in safety-critical environments, in which unhandledfaults could cause harmful system failures. This requires that those systems react on faultsproperly. However, handling faults by invalidating faulty data and going into a fail-safestate may cause the loss of some features. This is not acceptable for critical features thatrequire fail-operational behavior. To increase their dependability, systems must be ableto resume affected features without any service interruption. If system resources get lost,the remaining resources should be used efficiently to keep alive those features with thehighest demand with respect to safety, reliability and availability, as defined in [ALRL04].For instance, if an execution node becomes faulty and has to be isolated from the remainingsystem, another execution node has to be able to provide that features that were providedby the faulty node. However, as the remaining system-resources may become insufficientto provide the full set of features, it may be needed to explicitly deactivate some lowpriority features. This results in a graceful degradation of the system.

100

In this paper, we address the calculation and analysis of the deployment of mixed criticalsoftware components to the execution nodes of a new centralized HW/SW platform forelectric vehicles, which provides inherent safety properties and supports fail-operationalfeatures without requiring mechanical fallbacks. Our approach is based on a formal systemmodel and a set of formal constraints describing the validity of deployments with respectto the safety-concept of the proposed platform. Model and constraints characterize anarithmetic problem that can be solved for instance by SMT solvers.

The main contribution is an approach to calculate and analyze different reconfigurationsof the deployment to become active after execution nodes become isolated. The set ofactive software components – and thus also the set of provided features – is automaticallyreduced when the remaining system resources become insufficient to provide the initial setof components. Our approach allows to formally analyze at design-time, if the desired sys-tem and feature properties can be fulfilled, like which set of features can still be providedafter one or multiple isolations. This also allows to analyze the entire system degradation.

In section 2, we present the basic concepts of the mentioned platform. Section 3 shows themain contribution of this paper, which is a formal model and a constraint-based approachto calculate valid deployments and to analyze which features can be provided after isola-tions of nodes. Section 4 contains an example. Related work is discussed in section 5 andthe conclusion and future work is given in section 6.

2 System Architecture and Safety Concept

Fault-tolerance is the ability of a system to maintain control objectives despite the occur-rence of a fault, while degradation of control performance may be accepted [BSW01]. Ifa system has to support fail-operational features, it has to be capable to absorb loss of ex-ecution nodes. We consider mixed critical software components and deploy high criticalfail-operational components redundantly to the execution nodes. This enables the systemto absorb loss of execution nodes, as these components can continue their operation in thepresence of a limited number of hardware failures, while ensuring the absence of harm tothe users or the environment.

The analysis is tailored to a new scalable, uniform, open and thus easily extensible baseplatform that aims to reduce the complexity of automotive HW/SW architectures. Thebasic principles of this platform have been presented in [SCB+13] and [AFF+12]. Theplatform is composed of a scalable set of central execution nodes (also called DuplexControl Computers (DCCs)) and a set of peripheral execution nodes providing the physicalsensing and actuating (also called Smart-Aggregates). The DCCs assemble the so calledCentral Platform Computer (CPC) and are connected to each other and to the Smart-Aggregates by redundant switched Ethernet-Links. The DCCs are homogeneous, whatenables flexibility in the deployment.

The system has two different power supplies, named red and blue. Each execution nodeis supplied by either the red or the blue power supply. As scheduling policy, the conceptof logical execution times [HHK01] is used, meaning that the software components are

101

executed within fixed cycles. Each execution node provides a certain budget of time percycle that can be used to execute application software components. In this paper, weassume that all software components are scheduled with the same rate in every cycle.

The platform ensures the detection of random hardware failures with a sufficient failuredetection coverage. Sufficient means that the probability to become out-of-control is ac-ceptably low to meet the quantitative safety-requirements of the ISO26262 [Int11]. Wefocus on how to handle detected failures by performing adaptions to the deployment tomeet the requirements w.r.t. fail-operationality. More information about the Fault-Modelis also provided in [BASB14] and [BSAB14].

In the safety concept of the proposed platform, application software components (ASWCs)are grouped into so called ASWC-Clusters. This is done to reduce the complexity of faultdetection and handling mechanisms at runtime. The ASWC-Clusters get deployed to theexecution nodes. Those ASWCs are mapped to the same ASWC-Cluster that have thesame Automotive Safety Integrity Level (ASIL) and the same fail-operational requirement.

We distinguish different types of deployed instances, namely masters, hot-standby slavesand cold-standby slaves (also known as hot/cold spare). A master and a hot-standby slaveis active (executed in schedule), while a cold-standby slave is passive (only in memory,not executed in schedule). If the execution node of the master gets isolated by the runtimeenvironment due to a hardware failure, one hot or cold-standby slave becomes the newmaster and if required, a cold-standby slave becomes a new hot-standby slave.

There exist several constraints for the deployment given by the safety concept. For in-stance, if an ASWC-Cluster has a master and a hot-standby slave, then these two instanceshave to be deployed onto two execution nodes with different power-supplies to avoid thatboth instances get lost simultaneously when a power-supply fails.

These mechanisms are presented in section 3 in a more detailed formal model.

3 Deployment Calculation and Analysis

3.1 Formal System and Deployment Model

Our system model comprises a set of Functional Features F , an Application SoftwareArchitecture SA, an Execution Hardware ArchitectureHA and a System Configuration Φ,as defined below. Further properties for these elements are introduced in later sections. Inthe definitions, we write P+(X) for the power set without empty set P(X) \ ∅ of set X .

Definition 1 An Application Software Architecture SA = 〈S, SC〉 is composed of aset S = {s1, ..., sn} of Application Software Components (ASWCs) and a set SC ={sc1, ..., scq} of ASWC-Clusters with n, q ∈ N. To describe the mapping of the s ∈ Sto the sc ∈ SC, we define αs : S −→ SC. To describe which ASWCs are contained in acluster sc ∈ SC, we define αsc : SC −→ P(S) with αsc(sc) = {s ∈ S | αs(s) = sc}.Note that this mapping is total, but neither injective nor surjective, as clusters might beempty. For sc 6= sc′, it holds that (αsc(sc) ∩ αsc(sc′) = ∅) and

⋃sc∈SC αsc(sc) = S.

102

Definition 2 The set of functional features F = {f1, ..., fm} contains the features of thevehicle that can be recognized by the user. A feature is realized by one or more ASWCsand the involved Sensors and Actuators, while each ASWC contributes to realize one ormore features. We define the relationship between ASWCs s ∈ S and features f ∈ F asχs : S −→ P+(F ) with χs(s) = {f ∈ F | s contributes to realize f}. Accordingly, wedefine χf : F −→ P+(S) with χf (f) = {s ∈ S | f is partly realized by s}.

Definition 3 An Execution Hardware Architecture HA = 〈E,L〉 comprises executionnodes E and communication links L ⊆ E × E between these nodes. The set of executionnodes E = EC ∪ EA is composed of a set of central execution nodes EC = {e1, ..., ek}and a set of peripheral Smart-Aggregate nodes EA = {ek+1, ..., el} with attached physi-cal Sensors and Actuators. EC is also called the Central Platform Computer (CPC).

Definition 4 The Configuration Φ = 〈δP (SC), δA(SC), δ(SC)〉 defines how ASWC-Clusters SC are deployed to execution nodes E, either passively (δP ) or actively (δA). Wedefine δP : SC −→ P(E) with δP (sc) = {e ∈ E | sc is in memory of e, but not executedon e}, as well as δA : SC −→ P(E) with δA(sc) = {e ∈ E | sc is in memory of e andexecuted on e} for sc ∈ SC. Furthermore, δ(sc) = δA(sc) ∪ δP (sc).

Cluster-Deployment δ

Cluster-Mapping α

Feature-Relationship χ

ASWC-Cluster sc1failOp=0

ASWC-Cluster sc2failOp=1

e1 (DCC 1)

sc1 (Active)

sc2 (Passive)

e2 (DCC 2)

sc2 (Active)

ASWC s1failOp=0

ASWC s2failOp=0

ASWC s3failOp=1

Feature f1failOp=0

Feature f2failOp=1

χf(f2) = {s3}

χf(f1) = {s1, s2, s3}

αsc(sc1) = {s1, s2} αsc(sc2) = {s3}

δA(sc1) = {e1} δA(sc2) = {e2}

δP (sc2) = {e1}δP (sc1) = ∅

Figure 1: Example for the definitions

Fig. 1 shows a visualization of the given definitions, based on an example. Two features{f1, f2} are realized by overall three ASWCs {s1, s2, s3}, while the third ASWC s3 con-tributes to both features. The three ASWCs are mapped to two different ASWC-Clusters,depending on a property failOp that defines the level of required fail-operationality of anASWC. As cluster sc1 contains ASWCs that are not required to behave fail-operational,

103

it is deployed only once (δA(sc1) = {e1}). The other cluster sc2 contains an ASWC thatis required to behave fail-operational (αsc(sc2) = {s3} and failOp(s3 ) = 1). Hence,this cluster is deployed twice with one active Master (δA(sc2) = {e2}) and one passivecold-standby slave (δP (sc2) = {e1}). If a hot-standby slave would have been required,then it would hold that δA(sc2) = {e1, e2} and δP (sc2) = ∅.In this paper, we don’t model communication channels between ASWCs.

3.2 Fixed Properties of the Deployment Model

Each ASWC s ∈ S is defined by several properties. Property wcet : S → N+ defines theWorst-Case Execution Time. Property asil : S → {0..4} defines the Automotive SafetyIntegrity Level (ASIL) of an ASWC [0: Quality-Management (QM), 1: ASIL-A, 2: ASIL-B, 3: ASIL-C, 4: ASIL-D]. Property failOp : S → N0 defines the fail-operational level[0: non fail-operational, n: s has to be provided after n isolations].

For execution nodes e ∈ E, the property totalTimeBudget : E → N+ defines the budgetof time that is provided in each cycle to execute ASWCs. We assume here that ASWCsare executed in every cycle. The property powerSupply : E → {0, 1} defines the powersupply of the execution node [0: Blue, 1: Red]. Finally, the property isolated : E →{0, 1} defines if the execution node is isolated in the current solution instance.

3.3 Solution Properties of the Deployment Model

The properties of ASWC-Clusters sc ∈ SC depend on the mapped ASWCs. Propertiesasil : SC → {0..4} and failOp : SC → N0 define the ASIL and the fail-operationallevel of a cluster. It is ensured by constraints that ∀s ∈ αsc(sc) : asil(sc) = asil(s)and failOp(sc) = failOp(s). Property sumWcets : SC → N+ is defined to be equal to∑s∈αsc(sc)

wcet(s). To cover degradation scenarios after isolations of execution nodes,each sc ∈ SC has additionally the following properties:

• hotStandbySlaveReq : SC → {0, 1}, indicates if a hot-standby slave is required.

• hotStandbySlavePresent : SC → {0, 1}, indicates if a required hot-standbyslave can be established

• masterPresent : SC → {0, 1}, indicates if the master can be established

The last two properties may change in degradation scenarios after isolations of faulty ex-ecution nodes. The decision if a hot- or a cold-standby slave is required is based on thefault-recovery time of the vehicle and the minimum fault-tolerance time of the ASWCs fortheir different safety goals, as described in [BASB14].

For execution nodes e ∈ E, property usedTimeBudget : E → N0 is defined to be equal to∑sc∈SC | e∈δA(sc) sumWcets(sc), which is the sum of the wcet(s) of those ASWCs that

104

are active on execution node e. It is ensured by a constraint that the provided time-budgetis never exceeded, ∀e ∈ E : usedTimeBudget(e) ≤ totalTimeBudget(e).

The following properties define the solution matrices of the deployment problem.

• map : (S, SC) → {0, 1}, the mapping of ASWCs s ∈ S to ASWC-Clusterssc ∈ SC. [0: s /∈ αsc(sc), 1: s ∈ αsc(sc)].

• deploy : (SC,E) → {0, 1, 2, 3}, the deployment of ASWC-Clusters sc ∈ SC(and it’s contained ASWCs s ∈ αsc(sc)) to execution nodes e ∈ E. [0: e /∈ δ(sc),1: e ∈ δP (sc), 2: e ∈ δA(sc) while sc is a master on e, 3: e ∈ δA(sc) while sc is ahot-standby slave on e]

3.4 Basic Deployment Constraints

We setup an arithmetic model and constraints about the solution properties to describevalid solutions. Listing 1 shows some basic constraints of the deployment model.

1 ∀sc ∈ SC :∑

e∈E Ite (deploy(sc, e) 6= 0, 1, 0) = failOp(sc) + 1

2

3 ∀sc ∈ SC : Implies(masterPresent(sc) = 1,

∑e∈E Ite(deploy(sc, e) = 2, 1, 0) = 1

)Listing 1: Some basic constraints

The constraint in line 1 ensures the correct number of allocations of ASWC-Clusters.Clusters with failOp(sc) = n have to be allocated n+ 1 times. Hence |δ(sc)| = n+ 1.

The constraint in line 3 controls the presence of the master for each cluster. If a master ispresent, it is ensured that it exists exactly once. To deactivate a master, masterPresent(sc)has to become 0. This indicates that sc cannot be executed in the current deployment. Thehot-standby slaves are handled in a similar manner by the definition of constraints overproperties hotStandbySlaveReq(SC ) and hotStandbySlavePresent(SC ).

3.5 Reconfigurations after Isolations

Let ECf ⊂ EC be the set of isolated central execution nodes. We set isolated(e) = 1 forall e ∈ ECf . It is ensured by constraints that no ASWC-Cluster is activated anymore onone of the isolated execution nodes.

Definition 5 A Platform-Availability-Graph (PAG) is a directed acyclic graphG = (V, T ).Each vertex V represents a set of alive central execution nodesECa = EC \ECf . The edgesT describe a transition between two vertices, meaning that some e ∈ EC move from ECato ECf . A transition happens due to an isolation of a faulty execution node or if a power-supply disappears.

In [BSAB14], some formal constraints are shown that describe the validity of follow-updeployments, that become active after a transition in the PAG. In order to decide about

105

the deactivation order for the ASWC-Clusters in degradation scenarios, each instance ofa cluster gets assigned a priority. These priorities can be used to decide which clusterinstances have to be deactivated when the system resources become insufficient. The ob-jective is to maximize the sum of the priorities of active clusters. Low priority clusters aredeactivated first.

4 Example

In this section we show the applicability of our approach on a simplified example from theautomotive domain. Consider the following functional features and ASWCs:

Features fj ASWCs si ∈ χf (fj) asil(si) failOp(si) wcet(si)in ms

f1 : Infotainment s1 : Infotainment QM 0 2f2 : Energy-Management

s2 : RemainingRangeCalcs3 : EnergyEfficiencyAssist

AA

00

0.70.3

f3 : ADAS-A s4 : AdasSwc1s5 : AdasSwc2

CD

01

1.71

f4 : ADAS-B s5 : AdasSwc2 D 1 1f5 : Manual-Driving

s6 : ManualAccelerations7 : ManuelBrakings8 : ManualSteering

DDD

333

11

0.5Table 1: Example with different functional features, realizing ASWCsand fail-operational requirements

The features f3 and f4 are some Advanced Driver Assistance Systems (ADAS), like anACC or automatic parking. Let f4 be required to stay active after a failure, but f3 is notrequired to be active after a failure. As ASWC s5 contributes to realize both f3 and f4, ithas failOp(s5 ) = 1. As ASWC s4 only realizes f3, it is sufficient that failOp(s4 ) = 0.

In this example, five ASWC-Clusters {sc1, ..., sc5} are established. It holds thatαsc(sc1) ={s1}, αsc(sc2) = {s2, s3}, αsc(sc3) = {s4}, αsc(sc4) = {s5} andαsc(sc5) = {s6, s7, s8}.Notice that s5 is only in one cluster, although it contributes to two features.

Considering a CPC with four execution nodes (DCCs), a valid initial deployment for theexample is shown in Fig. 2. The colors (red/blue) of the execution nodes denote theirattached power-supply. We assume here that hot-standby slaves are required. As providedexecution time of the execution nodes per cycle, we assume totalTimeBudget(ei) =4ms. It can be seen that ∀ei ∈ E : usedTimeBudget(ei) ≤ totalTimeBudget(ei).

In the initial deployment, all master instances and all required hot-standby slave instancescan be deployed. However, if for instance the first execution node (DCC 1) fails and hasto be isolated, the deployment has to be changed.

106

e1 (DCC 1)

usedTimeBudget: 3.5 ms

e2 (DCC 2)

usedTimeBudget: 3 ms

e3 (DCC 3)


e4 (DCC 4)


sc5 (HotSlave)asil: DfailOp: 3sumWcets: 2.5 msASWCs: s6, s7, s8

sc4 (Master)asil: DfailOp: 1sumWcets: 1 msASWCs: s5

sc1 (Master)asil: QMfailOp: 0sumWcets: 2 msASWCs: s1

sc4 (HotSlave)asil: DfailOp: 1sumWcets: 1 msASWCs: s5

sc5 (Inactive)asil: DfailOp: 3sumWcets: 2.5 msASWCs: s6, s7, s8

sc3 (Master)asil: CfailOp: 0sumWcets: 1.7 msASWCs: s4

sc5 (Inactive)asil: DfailOp: 3sumWcets: 2.5 msASWCs: s6, s7, s8

sc2 (Master)asil: AfailOp: 0sumWcets: 1 msASWCs: s2, s3

sc5 (Master)asil: DfailOp: 3sumWcets: 2.5 msASWCs: s6, s7, s8

Figure 2: Initial deployment for the example

After the isolation of e1 (DCC 1), the master of cluster sc4 gets lost and its slave on e2becomes the new master. As failOp(sc4 ) = 1, no new slave is created as it is not requiredthat sc4 is still present after the next isolation. Furthermore, the hot-standby slave ofcluster sc5 gets lost. As failOp(sc5 ) = 3, an inactive instance of sc5 must be activatedto serve as new hot-standby slave to prepare for the next isolation. The new slave of sc5can only be activated on e3 and not on e2, because master and slave must not depend onthe same power-supply. However, to be able to execute cluster sc5 on execution node e3,cluster sc3 has to be deactivated as the sum of the WCETs of sc3 and sc5 would exceedthe time-budget of 4ms of e3. The deactivation of cluster sc3 forces the deactivation offeature f3, as αsc(sc3) = {s4} ⊆ χf (f3). This means, if execution node e1 has to beisolated, feature f3 cannot be provided anymore, using the given initial deployment.

The designer can analyze the system’s fail-operational behavior by considering the set ofdeactivated features in each degradation scenario. This allows to analyze if all desiredsystem and feature properties can be fulfilled, without executing the system. If more ex-ecution nodes are isolated in arbitrary order, cluster sc5 always remains to have a masterinstance, even if only one execution node is left. This is important as failOp(sc5 ) = 3.

A valid initial deployment is calculated automatically, but can also be changed manually inorder to analyze the systems graceful degradation scenarios depending on different initialdeployments.

We implemented the system model and constraints using the Z3 SMT-Solver [DMB08].

107

5 Related Work

In [She03], the authors show an approach to analyze graceful degradation. They use autility function to measure the set of active features. This can be seen as quite similar toour sums of priorities. They group components by defining subsystems based on the inter-faces of components, as we group components by their dependability requirements, whatallows separation of mixed-critical components. We focus more explicitly on deploymentconstraints that ensure fail-operational behavior. Another difference is that we considerthe explicit deactivation of components to be able to keep alive other components that arerequired to behave fail-operational.

In [EB08], an approach for task allocation supporting graceful degradation in distributedembedded real-time systems is introduced. They reuse the utility function of [She03] andintegrate it into an optimization search function based on simulated annealing. The aimis to analyze how many replicas are required to ensure a certain utility function value ina fault scenario. Instead, we use an SMT solver to calculate solutions and assume a pre-defined number of desired redundant deployments. Then, we maximize the priority sumof components that can be established in different degradation scenarios. They provide aquality metric for fault-tolerance based on the utilities of different fault scenarios, what iscurrently not supported by our approach.

In [BDTD08], fault-tolerant deployments with focus on the trade-off between performanceand reliability are optimized using a Mixed Integer Linear Programming (MILP) solver.However, the approach does not consider mixed criticalities explicitly and only a singlenode failure model is supported. Graceful degradation scenarios are not analyzed.

6 Conclusion and Future Work

In this paper, we introduced a formal model about the deployment of mixed-critical,partially fail-operational, software components to the execution nodes of a fault-tolerantHW/SW platform for electric vehicles. We also model the relationship between func-tional features and the software components that realize these features. We propose anapproach to calculate valid initial deployments which satisfy all safety constraints. Fur-thermore, we formally analyze degradation scenarios after isolations of faulty executionnodes. The degradations are required if system resources become insufficient to executeall components, meaning that some features cannot be provided anymore. We analyze ifall fail-operational requirements are met by the system design in all degradation scenarios.We implemented the model and a set of arithmetic constraints as input for an SMT-Solver,which calculates the deployment solutions that we analyze.

As future work, we currently include communication channels between components intothe model. Furthermore, we want to treat multiple system modes with different sets ofrequired features and optimize the deployment to allow mode-switches without requiringmigrations of software components. Finally, we want to evaluate the scalability of ourapproach based on different case-studies, like analyzing a concept car that we construct.

108

Acknowledgments.

This work is partially funded by the German Federal Ministry for Economic Affairs andEnergy (BMWi) under grant no. 01ME12009 through the project RACE (Robust and Re-liant Automotive Computing Environment for Future eCars) (http://www.projekt-race.de).

References

[AFF+12] Michael Armbruster, Ludger Fiege, Gunter Freitag, Thomas Schmid, Gernot Spiegel-berg, and Andreas Zirkler. Ethernet-Based and Function-Independent Vehicle Control-Platform: Motivation, Idea and Technical Concept Fulfilling Quantitative Safety-Requirements from ISO 26262. Adv. Microsystems for Automotive Applications(AMAA), pages 91–107, 2012.

[ALRL04] A. Avizienis, J.C. Laprie, B. Randell, and C. Landwehr. Basic concepts and taxonomyof dependable and secure computing. IEEE Transactions on Dependable and SecureComputing (TDSC), (1):11–33, 2004.

[BASB14] Klaus Becker, Michael Armbruster, Bernhard Schatz, and Christian Buckl. DeploymentCalculation and Analysis for a Fail-Operational Automotive Platform. In 1st Workshopon Engineering Dependable Systems of Systems (EDSoS), 2014.

[BDTD08] Bas Boone, Filip De Turck, and Bart Dhoedt. Automated deployment of distributedsoftware components with fault tolerance guarantees. In 6th Int. Conf. on Software En-gineering Research, Management and Applications (SERA), pages 21–27. IEEE, 2008.

[BSAB14] Klaus Becker, Bernhard Schatz, Michael Armbruster, and Christian Buckl. A FormalModel for Constraint-Based Deployment Calculation and Analysis for Fault-TolerantSystems. In 12th International Conference on Software Engineering and Formal Meth-ods (SEFM), 2014.

[BSW01] Mogens Blanke, Marcel Staroswiecki, and N Eva Wu. Concepts and methods in fault-tolerant control. In Proceedings of the American Control Conf., volume 4. IEEE, 2001.

[DMB08] Leonardo De Moura and Nikolaj Bjørner. Z3: An efficient SMT solver. Tools andAlgorithms for the Construction and Analysis of Systems, pages 337–340, 2008.

[EB08] Paul Emberson and Iain Bate. Extending a task allocation algorithm for graceful degra-dation of real-time distributed embedded systems. In Real-Time Systems Symposium(RTSS), pages 270–279. IEEE, 2008.

[HHK01] T. Henzinger, B. Horowitz, and C. Kirsch. Giotto: A time-triggered language for em-bedded programming. In Embedded Software, pages 166–184. Springer, 2001.

[Int11] International Organization for Standardization. ISO/DIS 26262-1 - Road vehicles -Functional safety, Part 1 Glossary. Technical report, ISO/TC 22, 2011.

[SCB+13] Stephan Sommer, Alexander Camek, Klaus Becker, Christian Buckl, Alois Knoll, An-dreas Zirkler, Ludger Fiege, Michael Armbruster, and Gernot Spiegelberg. RACE: ACentralized Platform Computer Based Architecture for Automotive Applications. InIEEE Vehicular Electronics Conf. / Int. Electric Vehicle Conference (VEC-IEVC), 2013.

[She03] Charles Preston Shelton. Scalable graceful degradation for distributed embedded sys-tems. PhD thesis, Carnegie Mellon University, 2003.

109

Formalizing Performance Degradation Strategies as anEnabler for Self-healing Smart Energy Systems

Pragya Kirti Gupta, Klaus Becker, Markus Duchon, Bernhard Schatz

fortiss GmbH, Guerickestr. 25, 80805 Munich, Germany{gupta, becker, duchon, schaetz}@fortiss.org

Abstract: Smart behavior in reactive systems can be achieved when systems can re-act appropriately to environmental changes. These adjustments in behavior can beachieved through predefined strategies. In this work, we present a formal specificationof performance degradation where the overall performance of the system is intention-ally lowered in order to ensure high availability of the core services of the systemin fault scenarios. We demonstrate the application of this strategy in the energy do-main. Power outages can be foreseen as one of the big challenges in the smart gridfunctionality. In such a power outage situation, it is essential to support high priorityservices at all times. During such situations, to prolong support for high priority ser-vices, we propose an approach using constraint-based formal modeling by developingthe degradation strategy. A service is selected or deactivated based on its priority, en-ergy consumption and its performance contribution. As a consequence, when serviceshave to be disabled due to insufficient available energy, the performance of the overallsystem degrades, but high priority services remain available. We validate our approachby using the Z3 SMT solver to identify a valid degradation strategy scheme for a faultscenario in the fortiss smart energy living lab demonstrator.

1 Introduction

Advancement in power systems technology will lead to smart and efficient usage of energy.A substantial effort in smart grid research is being made to make future grids a self-healingsystem. Self-healing systems not only address the self-recovery during runtime, but theunderlying effect is also the higher availability of system. As explained by Ghosh et al.[GSRRU07], a self-healing system does not crash immediately after the occurrence of afault. Instead, it undergoes a degraded state for a specific duration, during which recoveryprocedures can be carried out. With respect to smart energy systems, during power outagesituations the availability of the overall system can be ensured via energy provisioningof high priority services provided that certain energy backup capabilities already exist inthe system. The priority of the services can be fixed or assigned during the initial phase.The energy intensiveness of the service depends on the kind of smart grid node. Forexample the lighting system will have different priorities in different environments suchas hospitals, factories and small households.

In this paper, we present an approach to prolong support for the critical services by step-wise disabling other non-critical services, using constraint-based formal modeling. We

110

discuss in detail our approach using graceful degradation modes.

Section 2 describes the formulation of the system and various constraints taken into con-sideration in our approach. To establish the context of our approach, an example from theenergy domain is explained in section 3. In section 4, we compare existing approaches andestablish uniqueness of our approach in the energy domain. Section 5 presents a conclu-sion and the intended future work.

2 Strategy Formalization

To improve availability, our approach ensures that high priority services are always avail-able during a fault situation. The objective is to give higher precedence to availability overperformance of the system by guaranteeing support to high priority services during thefault situation.

We develop a scheme called degradation strategy scheme, whose objective is to disablelow priority services in a time sequenced manner. The scheme can be created as following:

1. Feature specification: We define all the features that affect the decision related toservices, degradation modes and the initial assumptions.

2. Constraints: We define the constraints that determine which services need to beavailable and which ones can be disabled.

3. Step-wise disabling of services: We define the sequence for automatically deactivat-ing the services in a time sequenced step-wise manner during the fault situation.

2.1 Formal feature specification of the system

2.1.1 Degradation Modes:

We define a normal mode nm, in which all services are active irrespective of their pri-orities. In order to handle faults, we further introduce different degradation modes M ={m1,m2, .....,mk}. Notice that nm /∈ M . Each degradation mode m ∈ M has theassociated parameters of Degradation duration and Expected Performance level.

The Degradation duration D : M → R is the duration during which a sequence of servicesare available.

The Expected Performance level L : M → N is the user defined minimum performancelevel expected to be maintained by the active services during each Degradation duration.It is the predefined performance index, that is compared with the actual performance levelduring each degradation mode.

111

2.1.2 Services:

Consider a system with a set of services: S = {s1, s2, ..., sn}. A service s ∈ S whichcan be active or not active in a given degradation mode m ∈ M is specified by ActivityA : S×M → {0, 1}. Since the idea is to support high priority services, a priority for eachservice must be defined. It has a direct impact on the activity A(s,m) of the service. Thehighest priority service has activity A(s,m) = 1 in all the degradation modes. Similarly,activity for the lowest priority service is assigned 0 i.e. A(s,m) = 0 in all the degradationmodes. We define the subset of active services in mode m ∈M as

SA(m) = {s ∈ S | A(s,m) = 1} ⊆ S.

In addition to priority, we specify two more properties for each service s ∈ S.

Performance contribution PC : S×M → N is the measure of the comfort level providedby a particular service depending on the degradation mode. This property defines the qual-itative expectation from the service and is based on the user’s experience and interaction.As opposed to the classical notion that the comfort level is static, we argue that duringfault scenarios the user expectations could change.

For example, in a smart grid building, brightness inside the building is maintained byseveral lighting devices such as florescent, halogen and LED lamps. We define a compositeservice for lighting as slight and three sub-services shalogen, sflorescent, sLED . Duringthe normal mode nm all the lights are switched on at night, such that

SAlight(nm) = {shalogen, sflorescent, sLED}

In contrast, during a power outage, a user would prefer to switch off halogen lamps to saveenergy to let the LED lights and florescent light stay on.

SAlight(m1) = {sflorescent, sLED}

Performance contribution for lights could be considered in terms of brightness levels,which depend on user preferences. Studies have been conducted in saving energy in smarthomes, giving high preference to users’ comfort levels [YKYI11], [KOY+13]. In thiswork, we do not focus on finding out the comfort levels during degradation mode.

The Cost C : S ×M → N of a service is measured by the effort of running it for a fixedperiod of time. In this work, we associate cost as the energy consumed by a service, that isunified and independent of the duration of the mode. Since the performance contributionof each service varies in different degradation modes, the cost of services also varies in thedegradation modes m ∈M .

Another aspect of estimating cost of the service is based on pricing, time of use and otherfactors specific to the service. In case of a coffee machine service, the cost may vary dueto the varying demand for the service throughout the day. One way of precisely estimatingthe cost could be by using forecasting for the service demand or varying price of energyduring low/high demands. In this paper, we consider static costs irrespective of the demandof a service and the energy price.

112

2.1.3 Backup power capacity:

The maximum backup capacity K must be known in order to plan the service scheme,which is required to execute during power outage condition. The backup capacity de-creases while supporting the high priority services.

An additional benefit of the graceful degradation approach is the prolonged time for eachdegradation duration to support high priority services.

We define prolonged time T : M → R such that T (m) ≥ D(m) for all m ∈M .

At the beginning of every Degradation duration D(m), an appropriate decision must betaken to select and disable a service. This decision is based on computing the actualPerformance contribution by aggregating the Performance contributions of all the servicesthat are running during a Degradation mode.

2.2 Constraints for validity of solutions

These constraints serve as the decisions to select and disable the service(s) during anydegradation mode.

Constraint1: The primary basis is that the aggregated performance contribution of theactive services should be more than or equal to the expected performance contribution:

∀m ∈M :∑

s∈S(A(s,m) ∗ PC(s,m)) ≥ L(m)

Each degradation mode has a predefined performance level, which means that the aggre-gation of the performance contributions of the active services must be equal to or morethan the expected performance level. Such a bound on the performance level ensures thatthe core functionality is always selected and remains active for as long as possible.

This constraint ensures that during the given degradation mode, the active services providethe expected functionality. But, this constraint is not sufficient, as it does not provide anyestimation about supporting the services during overall degradation process. The continu-ous usage of services reduces the maximum available capacity K.

Hence with decreasing capacity, the exact duration must be calculated in order to deter-mine the sufficiency of maximum capacity to support active services during the overalldegradation process.

Constraint2: It has to be ensured that the backup capacity K is big enough to serve thesequence of active services during the degradation modes. Hence, the cost of running theset of active services for each degradation duration should be less than or equal to themaximum available capacity.∑

m∈M (D(m) ∗∑

s∈S(A(s,m) ∗ C(s,m))) ≤ K

With this constraint, we ensure that the services selected during each degradation modedo not exceed the maximum available capacity. This is a dynamic problem wherein themaximum available capacity is continuously monitored and depending on the satisfactorycompliance of the Constraint1, services continue to remain disabled.

113

Initially, all the services would be active. Upon completion of a degradation duration, thestatus of active services could be decided on the basis of maximum available capacity.When the capacity is decreased, then for the next degradation duration some of the lowerpriority services could be disabled.

We argue that disabling the lower priority services will lead to prolonged duration of avail-able power capacity. Therefore, the prolonged time should be more than the assumed timeinterval i.e., Degradation duration for the maximum utilisation of backup power.

Therefore, the second constraint is now refined to:∑m∈M (T (m) ∗

∑s∈S(A(s,m) ∗ C(s,m))) = K

2.3 Step-wise disabling services

After specifying all the relevant features and the constraints that must be satisfied, thelast step is the step-wise disabling of services. By using Z3 SMT solver [DMB08], wedetermine the sequence in which services will be selected in each degradation mode andto realize how much prolonged support can be provided to the critical services. The SMTsolver provides us one of the ”satisfiable” service sequence, verifying that there exists atleast one valid sequence of services for the degradation strategy.

3 Example

In this section, we explain our approach using a real scenario from the fortiss living labdemonstrator [DGK+14], [KBG+12]. The office environment within the fortiss livinglab demonstrator is equipped with several sensors such as brightness, temperature andoccupancy. The sensor values are used to control actuators such as servers, lights, airconditioners, laptops and a coffee machine. The devices in the fortiss living lab are usedas services to explain the degradation process.

We consider batteries as the energy backup unit, with maximum capacity (K) as 20 kWh.

During the power outage condition, we consider a sequence of three Degradation modes,where service sequences are identified and some services are disabled during each degra-dation mode in order to save energy. At the beginning, we try to use the battery capacityto keep alive a subset of the services for at least the next four hours. Accordingly, in Table1 we make an initial assumption for the degradation duration D(mj) of each degradationmode mj ∈M along with the expected performance level L(mj).

The first degradation mode m1 has a duration of 1 hour and has an expected performancelevel of 80. Important assumptions in this example are that the system will get into degra-dation mode as soon as power outage happens and the battery is already charged to itsmaximum capacity. At the end of first degradation mode m1, the battery capacity is low-ered, necessitating a redefinition of the expected performance level.

114

Degradation Modemj ∈M

Degradation Duration(in hours) D(mj)

Expected PerformanceLevel L(mj)

m1 1 80m2 2 30m3 1 10

Table 1: Degradation Duration and Expected Performance for each Mode

As shown in Table 1, with every change between two degradation modes, the expectedperformance level also goes down, meaning that less energy will be consumed. Tables 2,3, 4 and 5 show each service si ∈ S with its associated priority P (si), activity A(si,mj)according to assigned priorities, performance contribution PC(si,mj) and cost C(si,mj)per mode mj ∈ M . Table 2 shows the priorities defined by the facility manager of theliving lab demonstrator.

Services Servicesi ∈ S

Priority ofservice P (si)

Servers s1 5Lights and air conditioner s2 4Laptops and Monitors s3 3Printers and Scanners s4 2Coffee Machine s5 1

Table 2: Services and their associated costs & priorities

Servers s1 is a single service with multiple sub services such as web servers, file servers,security servers (sserver = {sweb, sfile, ssecurity}). This server service has the highestpriority and should remain active at all times. Lights and air conditioner (s2) are givenhigher priority over laptops and monitors (s3). Printers and scanners (s4) have a higherpriority than the coffee machine (s5), which has the lowest priority.

Activity of each service indifferent modes

s1 s2 s3 s4 s5

A(si, nm) 1 1 1 1 1A(si,m1) 1 1 1 1 0A(si,m2) 1 1 1 0 0A(si,m3) 1 0 0 0 0

Table 3: Activity of services at each degradation mode.

As shown in Table 3, we assume that all the services are fully functional during the normalmode nm. So we assign 1 for the Active services (1 being active and 0 as disabled). Incontrast, A(si,m3) indicates that servers being the highest priority service will remainactive, while rest of the services will be deactivated.

Table 4 shows the performance contribution of each service in all three degradation modes.

115

Performance contribution ofeach service in differentmodes

s1 s2 s3 s4 s5

PC(si, nm) 40 20 10 10 10PC(si,m1) 40 20 10 10 0PC(si,m2) 20 10 10 0 0PC(si,m3) 10 0 0 0 0

Table 4: Performance levels of services at each degradation mode.

As explained earlier, the performance contributions are the comfort levels provided by theservices. It is dynamic and depends on several factors such as user preferences, energyavailability, cost of running the devices, etc. Studies have been done in saving energyin smart homes, giving high preference to users’ comfort levels [YKYI11], [KOY+13].Since we have not looked into finding out the comfort levels during degradation mode, thevalues for performance contribution and performance levels are assumed values and notbased on the fortiss living lab demonstrator.

Cost of each service in dif-ferent modes (kWh)

s1 s2 s3 s4 s5

C(si, nm) 2 2 5 1 2C(si,m1) 2 2 5 1 0C(si,m2) 2 1 3 0 0C(si,m3) 1 0 0 0 0

Table 5: Cost of services at each degradation mode.

As shown in Table 5, cost of service is dependent on activity and performance contributionand changes in every degradation mode. For instance, coffee machine has the lowestpriority P (s5) and is disabled at the beginning of first mode A(s5,m1) = 0. Therefore,the performance contribution and cost for the coffee machine service becomes zero.

In case of single service (e.g. servers), which has the highest priority, remain active inall the degradation modes A(s1,mj) = 1. The performance contribution during first andsecond degradation mode is constant, therefore the cost remains same. In the third mode,we consider the performance degradation within the service. In other words, the webserver sweb and the file server sfile are switched off and the security servers remain active.Therefore, performance contribution PC(s1,m3) is lowered to 10, leading to a decreasedcost C(s1,m3).

During the power outage situation in the office environment, we assume that the backupsystem will kick-in to support uninterrupted power supply to the services in the system.Since the backup capacity is limited, we apply a graceful degradation approach by dis-abling some of the lower priority services to prolong the power supply to support highpriority services.

We used Z3 SMT solver to find a solution for this example. The sequence of services

116

shown in Table 6 is a valid sequence of services which respects all constraints. During thefirst degradation mode m1, all services are active except the coffee machine (s5), whichhas the lowest priority. In the second degradation mode m2, printers & scanners (s4)are further disabled while in degradation mode m3, only servers (s1), being the highestpriority service remain active.

DegradationModemj ∈M

Set of Ac-tive ServicesSA(mj) ⊆ S

ProlongedDurations inhours T(mj)

Aggregated Perfor-mance Contribution∑

s∈S(A(s,m)∗PC(s,m))m1 s1, s2, s3, s4 1 80m2 s1, s2, s3 2 40m3 s1 4 10

Table 6: Solution showing the sequence of services and Prolonged Mode Durations Com-puted using Z3

tm1 m2 m3

power-outage

Perfo

rman

ce L

evel

s

nm

D(m1)

T(m3)

10

3020

405060708090

100

Actual PerformanceExpected Performance L(mj)

1 hr 2 hr 4 hr

D(m3)

Figure 1: Comparison of the expected and actual performance in 3-step degradation modes

Figure 1 shows the prolonged durations for the mode according to the table 6. T (m1)and T (m2) for modes m1 and m2 are same as the assumed durations D(m1) and D(m2).This means that the initially assumed durations are small yet sufficient enough so that thebatteries can support the desired subset of active services. The battery capacity, that isleftover after modes m1 and m2 are finished, is bigger than required to support all theservices that should be active in mode m3. Therefore, the duration T (m3) is 4 hrs, whichis more than 3 hrs longer than the assumption (D(m3) is 1 hour). This means that withthe shown solution, the living lab can operate overall 7 hrs after a power outage, if thebattery is fully charged. If the user wants a different solution, he has to change only someparts of the model properties (like the desired durations D(mj) or the desired expectedperformance levels L(mj)).

Yet another benefit of our approach is the estimation of the maximum storage capacityrequired for the desired services to run in n-step degradation modes. For instance, in the

117

above example, if the maximum battery capacity (K) is 7 kWh, then it is not possible tosupport the desired subset of active services (s1, s2, s3, s4) during degradation mode (m1),since the cost of all the services in m1 is 10 kWh, while total battery capacity as 7 kWh.

To check the feasibility of an estimation for the battery capacity, we can execute the SMT-solver multiple times for different properties in the model.

4 Related Work

In this section, we present the existing work done with respect to the degradation strategies.A formal specification of graceful degradation was given by Herlihy et al [HW91] byproposing relaxation lattices. These lattices are the set of constraints that the system mustsatisfy. We follow a similar approach of defining all the constraints for the system at designtime, but differ from the satisfiability of these constraints. In our approach, constraintsmust be strongly satisfied at all times, which serves as the basis for selecting and disablingparticular services.

Shelton et al [SKN03] specified a framework for graceful degradation in embedded sys-tems at design time. In their approach, the system is partitioned into subsystems at archi-tectural level. Our approach is similar to their work in two aspects. First, we considerthe degradation in terms of capabilities of the system to provide support to specific (inour case, high-priority) services. Second, instead of determining all the possible valid ser-vice sequences, we automatically determine one out of many valid service sequences. Theoptimisation for the best valid service sequence is not discussed in this work.

In [BSAB14], a formal model of an automotive system platform and the deployment ofsoftware components to the hardware platform is introduced. The deployment considera-tion includes redundantly deployed backups of mixed safety critical software componentsto the distributed hardware nodes, as well as required changes of the deployment in case ofpermanent hardware fault scenarios. Compared with our approach, the difference is thatthey have considered multiple hardware failures, each producing one degradation mode.In contrast, we consider multiple degradation modes for one failure.

5 Conclusion and Future Work

In this paper, we have introduced a formal approach to design a graceful degradation strat-egy for smart energy systems during power outage situation. As the outage occurs, thesystem automatically switches into battery operation. Our approach helps to identify effi-cient usage of battery capacity to keep important services alive as long as possible, whiledisabling less important services. We defined constraints for valid degradation modes andfound valid solutions by setting up an arithmetic input model for a SMT solver. Withour approach, the user is enabled to analyze different degradation scenarios based on thedifferent setups like varying the duration of the battery operation, varying amount of ser-

118

vices or varying the battery capacities. Scalability analysis, handling dependencies amongservices and dynamic cost estimations are some of the tasks planned for future.

6 Acknowledgement

We would like to thank the EIT ICT Labs for providing the support to build up thedemonstrator and carry out research experiments. We also acknowledge the support ofthe Stabiliz-E project.

References

[BSAB14] Klaus Becker, Bernhard Schatz, Michael Armbruster, and Christian Buckl. A FormalModel for Constraint-Based Deployment Calculation and Analysis for Fault-TolerantSystems. In 12th International Conference on Software Engineering and Formal Meth-ods (SEFM), 2014.

[DGK+14] Markus Duchon, Pragya Kirti Gupta, Dagmar Koss, Denis Bytschkow, BerhardSchatz, and Sebastian Wilzbach. Advancement of a Sensor Aided Smart Grid NodeArchitecture. 2014.

[DMB08] Leonardo De Moura and Nikolaj Bjørner. Z3: An efficient SMT solver. In Tools andAlgorithms for the Construction and Analysis of Systems, pages 337–340. Springer,2008.

[GSRRU07] Debanjan Ghosh, Raj Sharman, H Raghav Rao, and Shambhu Upadhyaya. Self-healing systems - survey and synthesis. Decision Support Systems, 42(4):2164–2185,2007.

[HW91] Maurice P Herlihy and Jeannette M. Wing. Specifying graceful degradation. Paralleland Distributed Systems, IEEE Transactions on, 2(1):93–104, 1991.

[KBG+12] Dagmar Koss, Denis Bytschkow, Pragya Kirti Gupta, Bernhard Schatz, Florian Sell-mayr, and Steffen Bauereiß. Establishing a smart grid node architecture and demon-strator in an office environment using the soa approach. In Software Engineering forthe Smart Grid (SE4SG), 2012 International Workshop on, pages 8–14. IEEE, 2012.

[KOY+13] Yukitoshi Kashimoto, Kazuya Ogura, Shinya Yamamoto, Keiichi Yasumoto, and Mi-noru Ito. Saving energy in smart homes with minimal comfort level reduction. InPervasive Computing and Communications Workshops (PERCOM Workshops), 2013IEEE International Conference on, pages 372–376. IEEE, 2013.

[SKN03] Charles P Shelton, Philip Koopman, and William Nace. A framework for scalable anal-ysis and design of system-wide graceful degradation in distributed embedded systems.In Object-Oriented Real-Time Dependable Systems, 2003.(WORDS 2003). Proceed-ings of the Eighth International Workshop on, pages 156–163. IEEE, 2003.

[YKYI11] Shinya Yamamoto, Naoya Kouyama, Keiichi Yasumoto, and Minoru Ito. Maximiz-ing users comfort levels through user preference estimation in public smartspaces. InPervasive Computing and Communications Workshops (PERCOM Workshops), 2011IEEE International Conference on, pages 572–577. IEEE, 2011.

119

Tagungsband des Dagstuhl-Workshops - TU Clausthal...Architekturen insbesondere für langlebige und...

Documents

Transcript of Tagungsband des Dagstuhl-Workshops - TU Clausthal...Architekturen insbesondere für langlebige und...