Spiraling vehicle complexity requires an overall architectural concept that provides a total vehicle perspective across all functional domains. Here we summarize the concept and some basic elements of an architecture framework for the automotive industry. We intend to drive the thought process within the automotive industry toward a standardized architectural foundation that builds upon successful examples of similar efforts, such as the Department of Defense Architecture Framework (DoDAF).

Reactive distributed systems, including business information systems and embedded control systems, require systematic software engineering approaches that can manage the complexity of the system and the development. This helps to ensure resulting implementations of high quality within reasonable cost and time frames. The CoCoME POS system (see Chapter 3) is a telling example that combines elements of both system classes.

In diesem Beitrag wird mit dem Feature Net, einer Kombination aus klassischem Feature Tree und Semantic Net, ein Modell zur strukturierten Erfassung von applikationsund domänenspezifischen Anforderungen eingeführt. Das Feature Net unterstützt, als Ergebnis eines modellbasierten Requirements Engineering Prozesses, den Übergang zum Design, sowie, als modellbasierte Repräsentation von Domänenwissen, die gezielte Wiederverwendung von Artefakten. Schlüsselwörter: Automobilspezifische Modellierung, Domänenwissen, Feature Tree, Feature Net, Klassifikation von Anforderungen, Semantic Net, Wiederverwendung 1 Motivation und Einleitung Die steigende Bedeutung von Software-Systemen im Automobil sowie deren zunehmende Komplexität führen zu neuen Herausforderungen im Entwicklungsprozess [FGP04]. Die zunehmende Vernetzung einer kontinuierlich wachsenden Anzahl an SoftwareFunktionen erfordert eine systematische Erfassung der funktionalen Abhängigkeiten sowie Methoden zur frühzeitigen Analyse von Systemfunktionalität hinsichtlich Feature Interaction, Konsistenz und Vollständigkeit. Große Variantenvielfalt, steigender Kostendruck und die Notwendigkeit kürzerer Entwicklungszeiten begründen ein Bedürfnis nach gezielter Wiederverwendung [TH02, MG02]. Eine weitere Herausforderung bei der Entwicklung eingebetteter automobilspezifischer Applikationen stellt die frühzeitige Erfassung von Abhängigkeiten zwischen der zu entwickelnden Software und ihrer Hardwareumgebung dar. In diesem Papier wird mit dem Feature Net ein Ansatz vorgestellt, der darauf abzielt, Anforderungen und deren Abhängigkeiten strukturiert zu erfassen und dadurch Inkonsistenzen zwischen Anforderungen frühzeitig aufzudecken, den Übergang zum Design zu erleichtern sowie gezielte Wiederverwendung zu unterstützen. In Abschnitt 2 wird das Feature Net näher definiert und mittels eines automobilspezifischen Beispiels illustriert. Abschnitt 3 skizziert den methodischen Einsatz des Feature Net. Abschnitt 4 gibt einen Ausblick auf aktuelle und geplante Weiterentwicklungen des Ansatzes. 2 Feature Net – Definition und Ziele Ein Feature Net liefert eine strukturierte Darstellung aller relevanten Features eines Systems. Unter Features verstehen wir Bestandteile oder Eigenschaften des SW-/HWSystems (vgl. [KCH+00]), die durch einen Abstraktionsprozess aus Anforderungen gewonnen werden. Im Wesentlichen werden damit funktionale Einheiten des Systems beschrieben, aber auch HW-Bestandteile des Systems. Auch nichtfunktionale Anforderungen, wie Qualitätsanforderungen, werden als Attribute von Features strukturiert abgelegt. Jedes Feature Net setzt sich zusammen aus einem Feature Tree (domänenspezifischer Klassifikationsbaum) und einem Semantic Net (vgl. [BL85]), das die Abhängigkeiten zwischen einzelnen Features erfasst. Durch diese Aufspaltung wird eine klare Trennung unterschiedlicher Aspekte erreicht, die bei bekannten Ansätzen wie [KCH+00] oft vermischt werden: Bei unseren Feature Trees liegt der Fokus auf der vollständigen Erfassung und hierarchischen Strukturierung aller Features. Weitere Relationen zwischen Features spielen hier keine Rolle; diese werden beim Aufbau des Semantic Net untersucht. In dem Ansatz werden ein Domain Feature Net, welches das gesamte Domänenwissen repräsentiert, und verschiedenen Application Feature Nets, die nur die Informationen umfassen, die für die Entwicklung einer Applikation benötigt werden, unterschieden. Ersteres liefert einen „Bauteilekatalog“, einen strukturierten Pool an Features, aus dem man sich bei dem Design künftiger Systeme bedienen kann. Somit wird die gezielte Wiederverwendung von Artefakten unterstützt. Ein Application Feature Net hingegen ist eine Projektion aus dem Domain Feature Net auf ein bestimmtes System. Es stellt eine geeignete Struktur für die formalisierte Erfassung von Anforderungen und deren Beziehungen bereit und erleichtert den Übergang vom Requirements Engineering zum Design. 2.1 Der Feature Tree Die Grobstruktur aller Feature Trees ist domänenspezifisch, die weitere Strukturierung hingegen hängt von dem zu modellierenden System ab. Abb. 1 zeigt exemplarisch anhand der Fensterhebung einen Ausschnitt eines Application Feature Trees. Jeder Knoten eines Feature Trees repräsentiert ein mehr oder weniger fein granulares Feature. Jedem Knoten ist ein Template zugeordnet, welches alle relevanten Informationen des Features in strukturierter Form enthält. Der Aufbau des Templates unterscheidet sich für die einzelnen Teilbäume und ist unter anderem geprägt von den Design-Modellen, die zur Modellierung der entsprechenden Features verwendet werden. Die vorgegebene Struktur des Templates vereinfacht den Übergang zum Design und erlaubt eine automatische Transformation in Modellfragmente. Zudem fungieren die Templates als Checkliste und stellen sicher, dass keine relevanten Informationen vergessen werden. Jedes Template beinhaltet Metainformationen (ID, Autor,...), eine Kurzbeschreibung, die Anknüpfungspunkte des Semantic Net sowie weitere spezifische Informationen. Allgemein gilt, dass in das Design der Templates Erfahrung und Domänenwissen einfließt. 1 Der genaue Aufbau der Templates kann aus Platzgründen nicht näher erläutert/graphisch dargestellt werden. Abb. 1 Ausschnitt aus dem Application Feature Tree "Fensterhebung" Die Kanten eines Feature Trees repräsentieren die Klassifikationsbeziehungen zwischen verschiedenen Features, d.h. sie liefern eine hierarchische Einteilung der Feature in verschiedene Klassen. Im Gegensatz zu [KCH+00] gibt der Feature Tree in unserem Ansatz keine Auskunft über weitere Abhängigkeiten. Bei dem Aufbau der Feature-Hierarchie wird eine Gruppierung gleichartiger Informationen angestrebt, um Feature-Familien auszuzeichnen und die Vererbung von Eigenschaften zu optimieren. Besonders auf den oberen Ebenen des Baums wird das „Separation of Concerns“-Prinzip angewendet (s. Abb. 1), um domänenspezifische Informationen möglichst vollständig zu erfassen. 2.2 Das Semantic Net Neben der Klassifikation der Features existieren zahlreiche weitere Beziehungstypen. Mit dem Semantic Net wird ein Modell zur Verfügung gestellt, um diese Beziehungen strukturiert zu erfassen. Grundlegende, für die Entwicklung von SW-Systemen im Automobilbereich charakteristische Beziehungstypen sind beispielsweise hierarchische Relationen (Dekomposition, Variantenbildung, Spezialisierung), kausale Relationen (Voraussetzung, wechselseitiger Ausschluss, Kompatibilität), Interaktionsrelationen (Aufrufbeziehung, Sender/Empfängerbeziehung) oder Deploymentbeziehungen. Für die in einem Feature Tree klassifizierten Features lässt sich klar definieren, welche Typen von Beziehungen zwischen den Features verschiedener Teilbäume auftreten. Beispielsweise können die Beziehungen zwischen Aktionen und Diensten zu einer Relation „setzt in kausalen Zusammenhang“ abstrahiert werden, welche beschreibt, aus welchen Aktionen sich ein Dienst aufbaut. Diese Relation wiederum stellt einen Spezialfall der Dekomposition dar. Die feste Vorgabe möglicher Beziehungstypen in Verbindung mit einer formalen Fundierung dieser hilft beim Erarbeiten, Strukturieren und Analysieren des oft sehr umfangreichen Beziehungsgeflechts zwischen den Features. 3 Methodischer Einsatz eines Feature Net In diesem Abschnitt wird der methodische Einsatz des Feature Net skizziert. Insbesondere wird aufgezeigt, an welcher Stelle im Software-Entwicklungsprozess dieses eingesetzt und wie es methodisch und systematisch erarbeitet werden kann. 3.1 Feature Net – Ergebnis der Requirements Engineering Phase Ein Feature Net ist als Endergebnis des Formalisierungsprozesses des Requirements Engineerings anzusehen, da es alle Anforderungen der Requirements Engineering Phase formalisiert abbildet. Für die systematische Erarbeitung eines (Application) Feature Net sind folgende Schritte notwendig: Identifikation und Normalisierung. Zunächst müssen die Anforderungen aus den Eingabedokumenten extrahiert, identifiziert, atomarisiert sowie attributiert werden. Außerdem muss die verwendete Terminologie sprachlich vereinheitlicht werden. Aufbau des Feature Trees. Ausgehend von einer unstrukturierten Menge an normalisierten Anforderungen wird schrittweise ein Feature Tree aufgebaut. Hierzu wird die Menge der Anforderungen zunächst entsprechend der domänenspezifischen Grobstruktur unterteilt. Auf den unteren Ebenen werden weitere applikationsspezifische Klassen gebildet, indem Anforderungen mit gemeinsamen Aspekten in Gruppen zusammengeordnet werden. Der Aufbau des Feature Trees ist abgeschlossen, wenn eine weitere Unterteilung nicht mehr sinnvoll ist. Aufbau und Befüllen der Templates. Charakteristische Informationen aus den Anforderungen, die ein spezifisches Feature betreffen, werden in Templates gespeichert und können dadurch eindeutig formuliert und verstanden werden. Die Templates müssen zu Beginn der Analysephase im Requirements Engineering einmal erarbeitet werden. Ziel ist es jedoch, bestehende Templates wiederzuverwenden und dadurch das Domänenwissen, das sich im Aufbau der Templates widerspiegelt, zu nutzen, z.B. um Lücken in den Anforderungen aufzudecken. Aufbau des Semantic Net. Hand in Hand mit der Erstellung des Feature Trees geht die Spezifikation des Semantic Net einher, um die Abhängigkeiten zwischen den Features zu erfassen und damit auch Inkonsistenzen aufzudecken. Domänenspezifische Vorgaben, die festlegen, welche Beziehungen zwischen Features existieren, helfen bei der korrekten und vollständigen Erfassung von existierenden Abhängigkeiten. Die über die Zeit erarbeiteten spezifischen Beziehungstypen spiegeln somit Teile des Domänenwissens wider. 3.2 Feature Net – Ausgangspunkt des Designs Die in einem Feature Net systematisch gespeicherten Informationen bilden den Ausgangspunkt für das Design. Die eingeführte Strukturierung unterstützt eine Entwicklung über verschiedene Abstraktionsebenen hinweg, da die Anforderungen bereits nach derartigen Gesichtspunkten klassifiziert sind. Von diesen Teilmen

In this paper a model-based design approach currently developed is introduced to optimize the development process of automotive software. The approach plays special emphasis on a quality-oriented construction of embedded software to shorten the development life cycle and the development costs at the same time. “Quality-oriented” in this context means, that design and implementation decisions may be better traced back to the actual user requirements which are essential for the validation of the system. In contrast to low-level modeling approaches (such as Matlab/Simulink [1] or ASCETSD [2], which mainly focus on technical aspects of the system), high-level modeling concepts are introduced to represent HW-/SW-architectures within a set of consecutive abstraction level s. A newly reworked system of automotive-specific abstraction levels is presented, where architectures are specified introducing more detail on each level. The system of abstraction levels supports the inheritance of model information from abstract levels down to concrete levels and the refinement of this information at each level. Thus the gap between (informal) requirements and the implementation is reduced. Since the higher levels

In this paper, we will introduce a simple but forma l service description language (ForSeL) together with a methodology for its application in software engineering. ForSeL helps to bridge the gap between informal functional requirements and formal models in the subsequent design phase. Though its semantics i s formally defined and therefore well suited for development techniques like behavioural refinement, code generation and verification, the language is v ery easy to use for software engineers. Using our approach, requirements can be formulated precisely and without any contradictions. The basic notion in ForSeL is an action. A ForSeL specification is the composition of a finite number of functional requirements. Each (functional) requirement describes a system “re”-action that is triggered by a set of input actions – but only if a n additional precondition holds. A pragmatic and at t he same time adequate notation for this triple is give n by so-called reaction tables. 1

In this paper, we introduce a simple but formal service description language (ForSeL) for model-based requirements engineering. The basic notion in ForSeL is a service representing a functional requirement. Each service describes a system "re"-action that is triggered by a set of input actions $(but only) if an additional precondition holds. The functional part of a specification is then obtained by the combination of a finite number of services. We pay special attention to two kinds of preconditions which are often mixed up in practice: sufficient and necessary preconditions. Moreover, we present refinement concepts for services that enable a stepwise development of functional requirements

One of the most crucial questions concerned with model-based testing is how to find "interesting" test cases. We consider test cases to be interesting if firstly, they cover the user requirements and secondly, they have a high probability to find potential errors. In this paper we introduce an approach to derive test cases along different levels of abstraction during the design phase. These levels start with services representing user requirements on the topmost level and result in models for a specific technical platform on the most concrete level. Within the presented test process we use design models of different abstraction levels as test models out of which test cases can be generated. The test cases are executed on more concrete levels and finally on the implementation. An exception is the (topmost) service level which isused for the derivation of the test case specification.One main advantage of our approach lies in preserving the link from test cases to corresponding user requirements. Furthermore the danger of using too abstract models which do not reflect inevitable crucial aspects of the realization is avoided. Finally this yields to a front loading of quality control activities to a point as early as possible in the development process. In our work we focus on embedded reactive systems especially in the field of automotive software. Our current research targets at new kinds of test coverage criteria which reflect the systems requirements rather than structural aspects of models.

Within Requirements Engineering it is a difficult task to systematically increase the quality of individual requirements and the whole specification. In this position paper we present our current research effort on a requirement engineering process for automotive software, which is an intermediate result of the mobilSoft project. In order to improve the requirements specification we propose the integration of conceptual dimensions of quality – namely concretization and formalization – into the Requirements Engineering Process (REP) and we illustrate how a process using these dimensions will guide and support achieving completeness of the specification.

The service-oriented paradigm is a promising approach to handle the growing complexity of software systems. This paper introduces a methodology for a stepwise refinement of service specifications on different levels of abstraction. Moreover, it deals with the integration of service and architecture specifications. Underlying concepts for a formal service specification are motivated from a methodological point of view and are precisely given in this paper. Furthermore the application of these concepts is demonstrated within a case example. The presented methodology stems from the RoFa-Soft project, where both aforementioned development paradigms are consolidated and integrated.

This paper discusses the concept of model driven system architecture development for the automotive industry. It outlines best practices and methods and introduces specific abstraction layers for complexity reduction. // A common standardised Automotive Architecture Framework is postulated to allow common description structures, increase re-use and better collaboration within the automotive value creation community.

In this paper we introduce the component language COLA for the design and development of embedded systems. We present the formal syntax and semantics of COLA which is based upon synchronous data?ow. Utilizing the abstraction provided by this paradigm, the designer is freed from implementation details and is able to focus on the core-functionality to be modeled and implemented. Due to the well-founded semantics of the language, it is possible to establish an integrated development process, the artifacts of which can be formally reasoned about and are dealt with in automated tools such as model checkers or model-based test case generators. Since COLA has been developed in the context of an industrial cooperation, the main rationale in the design of COLA is its industrial applicability: Thus, the language must provide a well-de?ned semantical foundation which is accessible to today’s tools and techniques and which is also able to capture today’s industrial applications. To this end, we extend the data?ow approach with automata to model operating modes concisely as well as with a hierarchical decomposition to facilitate reuse e?ciently. We designed a textual and an equivalent graphical representation of COLA models to meet the need of our industrial collaborators. Finally, we demonstrate the viability of our approach with a case study from the automotive domain where we design an adaptive cruise control (ACC) unit.

In diesem technischen Bericht wird ein umfassendes Architekturmodell fur die Entwicklung von eingebetteten Systemen vorgestellt. Im Vordergrund stehen hier Software-intensive Systeme, so wie sie im Automobil zu finden sind. Das Architekturmodell kann jedoch auch auf alle anderen Branchen ubertragen werden, die sich mit der Entwicklung von Software-intensiven eingebetteten Systemen beschaeftigen. Die Grundidee hinter diesem umfassenden Architekturmodell ist eine Software-Entwicklung entlang geeigneter automobilspezifischer Abstraktionsebenen. Damit soll die Grundlage fur einen systematischen Software-Entwicklungsprozess und fur eine modellbasierte Werkzeugunterstuetzung geschaffen werden. Dieser Bericht konzentriert sich auf die Charakterisierung der einzelnen Abstraktionsebenen, deren Ziele, Hauptelemente und Sichten. Die wichtigsten Konzepte werden anhand eines durchgaengigen Fallbeispiels veranschaulicht.