Software Documentation for Embedded Systems : A Problem-Based Approach

Ulfat-Bunyadi, Nelufar GND

Embedded systems shape and govern our world today. We can hardly imagine a life without these systems. Examples are mobile phones, DVD players, pacemakers, train control systems, and automotive components. Embedded systems are frequently part of complex safety-critical systems that can be found in the following domains: automotive, avionics, medical, consumer electronics, automation.</br> A main characteristic of the development process of these complex safety-critical systems is the division of labour. The manufacturer usually decomposes the complex system into subsystems and assigns the development of these subsystems to divisions within the company or to external suppliers. Once they are developed, the manufacturer integrates them into the system. Of course, the suppliers get a list of requirements, that the subsystem they are responsible for, should fulfil. However, they usually have a lot of freedom in developing these subsystems. The manufacturer, on the other hand, has a black-box view on the supplied subsystems and is only able to make small modifications and, thus, integration of the subsystems into a complex system is a challenging task. The communication between suppliers and manufacturer can and should be improved. If each supplier develops not only his own subsystem, but makes also his expectations with regard to other subsystems and the overall system explicit, this would facilitate integration a lot. Yet, frequently, these expectations remain implicit and are not documented in a systematic and structured way. To facilitate integration, suppliers should document not only the requirements their developed subsystem fulfils but also the assumptions they make about the environment of the subsystem, i.e. the domain knowledge. However, it is not sufficient to tell developers to document domain knowledge. Since domain knowledge is knowledge about the environment and the environment is a part of the real world, the question is what to document. Actually, everything could be documented. Developers need guidance as regards the questions what to document and how. Of course, there are existing approaches that provide support in this regard. However, they do not take the peculiarities of embedded systems development and the challenges that arise from them into account. The main objective of this thesis is therefore to develop methods that support software documentation during requirements engineering and are tailored to the peculiarities of embedded systems development.</br> An embedded system must satisfy different types of requirements. For each type of requirement, a different type of domain knowledge must be documented. In this thesis, we answer the questions which type of domain knowledge must be documented for which type of requirement and how it should be documented. We consider functional requirements, safety requirements, security requirements, trustworthiness requirements, and product line requirements. We consider functional requirements since these are relevant for each system. Safety requirements are important because embedded control systems are frequently part of complex safety-critical systems (like cars and airplanes). Today, these safety-critical systems are connected to the Internet which results in new challenges regarding security and trustworthiness of these systems. Therefore, we also consider security and trustworthiness requirements. Suppliers developing embedded control systems often use product line engineering approaches since they develop usually not only one system but different versions of this system to be able to supply the whole market and not only a single customer. Therefore, we consider also product line requirements.</br> The methods that we developed are all problem-based. This means that we use problem diagrams for documentation, since they are well suited for this purpose. To illustrate the applicability of the developed methods, we use two case studies from the automotive domain.

Eingebettete Systeme übernehmen heutzutage eine Vielzahl von Überwachungs-, Steuerungs- und Regelfunktionen und sind aus unserem alltäglichen Leben nicht mehr wegzudenken. Sie verrichten viefältige Aufgaben in diversen Anwendungsbereichen und Geräten wie zum Beispiel in Geräten der Medizintechnik, Flugzeugen, Fahrzeugen, Fernsehern, DVD-Playern und Mobiltelefonen. In komplexen Gesamtsystemen wie Fahrzeugen und Flugzeugen finden sich Vernetzungen von sonst autonomen, eingebetteten Systemen.</br> Die Entwicklung solch komplexer Gesamtsysteme weist einige Besonderheiten auf. Der Hersteller (z.B. Fahrzeug- oder Flugzeughersteller) zerlegt das komplexe Gesamtsystem in Teilsysteme und weist die Entwicklung dieser Teilsysteme einzelnen Abteilungen oder externen Zulieferern zu. Sind die Teilsysteme entwickelt, übernimmt der Hersteller wieder die Aufgabe, die entwickelten Teilsysteme zu einem Gesamtsystem zu integrieren. Natürlich erhalten die Zulieferer eine Liste von Anforderungen, die das von ihnen zu entwickelnde Teilsystem zu erfüllen hat. Dennoch haben sie aber auch viele Freiheiten bezüglich der Entwicklung dieser Teilsysteme. Der Hersteller hingegen hat eine Black-Box-Sicht auf die entwickelten Teilsysteme und kann bis auf kleinere Modifikationen keine größeren Änderungen an den geliefereten Teilsystemen vornehmen. Daher stellt die Integration der Teilsysteme zu einem komplexen Gesamtsystem eine große Herausforderung dar. Die Kommunikation zwischen Zulieferern und Herstellern kann und sollte verbessert werden. Wenn jeder Zulieferer nicht nur sein eigenes Teilsystem entwickeln würde, sondern auch die Erwartungen, die er an andere Teilsysteme hat, explizit machen würde, würde dies die Integration erheblich erleichtern. Doch häufig werden diese Erwartungen nicht systematisch und strukturiert dokumentiert und bleiben daher implizit. Um die Integration zu vereinfachen, sollten Zulieferer aber nicht nur die Anforderungen dokumentieren, die das von ihnen entwickelte Teilsystem erfüllt, sondern auch die Annahmen explizit machen, die sie über die Umgebung des Teilsystems treffen, im Folgenden als Domänenwissen (engl. domain knowledge) bezeichnet. Es reicht aber nicht aus, Entwicklern zu sagen, dass sie Domänenwissen dokumentieren sollten. Da sich Domänenwissen auf die Umgebung bezieht und die Umgebung ein Teil der realen Welt ist, stellt sich die Frage, was und wieviel über die Umgebung zu dokumentieren ist. Entwickler brauchen eine sytematische Unterstützung in dieser Hinsicht. Es gibt einige existierende Ansätze, die diese Unterstützung zum Teil bieten. Diese existierenden Ansätze sind aber nicht auf die Besonderheiten der Entwicklung eingebetteter Systeme zugeschnitten und stellen sich daher nicht den daraus resultierenden Herausforderungen. Das Ziel dieser Arbeit ist es daher, Methoden zu entwickeln, die die Dokumentation von Domänenwissen während des Requirements Engineerings unterstützen und auf die Besonderheiten eingehen, die sich aus der Entwicklung eingebetteter Systeme ergeben.</br> Ein eingebettetes System muss verschiedene Arten von Anforderungen (z.B. funktionale Anforderungen und verschiedene Arten von Qualitätsanforderungen) erfüllen. Für jede Anforderungsart muss eine andere Form von Domänenwissen dokumentiert werden. In dieser Arbeit wird daher die Frage beantwortet, welche Form von Domänenwissen für welche Anforderungsart dokumentiert werden muss und wie diese Dokumentation erfolgen kann (d.h. mit welcher Systematik und mit welchen Mitteln). Die folgenden Anforderungsarten werden dabei betrachtet: funktionale Anforderungen, Sicherheitsanforderungen in zweierlei Hinsicht: Security und Safety, Anforderungen an die Vertrauenswürdigkeit des Systems und Produktlinienanforderungen. Funktionale Anforderungen müssen betrachtet werden, da sie für jedes eingebettete Systeme relevant sind. Sicherheitsanforderungen im Bereich Safety sind von großer Bedeutung, weil eingebettete Systeme häufig Teil von komplexen sicherheitskritischen Systemen wie Fahrzeugen und Flugzeugen sind. Heutzutage werden diese komplexen sicherheitskritischen Systeme mit dem Internet verbunden. Dies resultiert bei Nutzern (aber auch anderen Beteiligten) in Bedenken bezüglich der Sicherheit (d.h. Security) und Vertrauenswürdigkeit dieser Systeme. Aus diesem Grund ist es notwendig, Sicherheits- (Security) und Vertrauenswürdigkeitsanforderungen zu betrachten. Da Hersteller und Zulieferer häufig Produktlinienansätze in ihren Entwicklungsprozessen einsetzen (um nicht nur ein System zu entwickeln, sondern mehrere Versionen eines Systems und damit einen größeren Markt bedienen zu können), werden darüber hinaus auch Produktlinienanforderungen betrachtet. </br> Die Methoden, die in dieser Arbeit vorgestellt werden, basieren auf der Nutzung von sogenannten Problemdiagrammen. Daher können die Methoden und somit die gesamte Arbeit als problem-basiert bezeichnet werden. Um die Anwendbarkeit der entwickelten Methoden zu veranschaulichen, werden zwei Fallstudien aus dem Automobilbereich genutzt.

Cite

Citation style:
Ulfat-Bunyadi, N., 2019. Software Documentation for Embedded Systems: A Problem-Based Approach. https://doi.org/10.17185/duepublico/70056
Could not load citation form.

Rights

Use and reproduction:
All rights reserved

Export