Summary

The terms model and model-based can be interpreted very broadly. This has not least to do with the fact that a model is always created for a specific purpose and the set of legitimate models is at least very large, if not infinite.

What they all have in common, however, is that they are simplified or reduced to what is essential. The aim is always to facilitate the activities it carries out.

General advantages and disadvantages of model-based methods:

The advantages lie in the improvement or support of work processes.

The necessary tool support can be considered a disadvantage. This can be further subdivided into tool costs, familiarization with new tools and the danger of tool lock-ins (strong ties to proprietary data formats, etc.).

However, the disadvantages mentioned can be greatly reduced with a considered choice of tools/development tools. Of course, even then it is still necessary to weigh up the advantages and disadvantages. At IMT, we are convinced that every project, regardless of size, can benefit from the use of model-based methods.

Examples for application of model-based methods at IMT:

For the development of specific electronic and mechanical components, we use CAD systems such as “Altium Designer” or “SOLIDWORKS 3D CAD”. The majority of such systems are already established on the market.

When developing larger systems, we mostly use MBD. In addition to the benefits of rapid prototyping, this also enables early fault detection through the simulation/testing approaches offered by the “in-the-loop” processes. Among other things, IMT relies on “MATLAB/Simulink” for this. For example, this is used in the development of measuring instruments.

If the product also has to meet strict standard requirements, it makes sense to combine this with an MBSE approach, which supports proof of conformity with the standard. For example, this is the case in the development of medical technology products.

Model-based methods are often used to implement smaller projects such as test automation tools, which allows “boilerplate code” to be generated. Among other things, IMT uses its own “DATAFLOW Designer” software tool, which follows an MBSE approach.

Introduction

The (EN) ISO 13485 in its 2016 edition, as well as the FDA Guidances and the European Medical Device Regulation (MDR) require software used in the quality management systems of medical device manufacturers to be validated. While ISO 13485 and the EU MDR do not go into detail on validation should look like, the US FDA published guidelines on January 11, 2002: “General Principles of Software Validation; Final Guidance for Industry and FDA Staff”. The ISO and IEC working groups have also considered this topic and published ISO/TR 80002-2 in 2017: “Validation of software for medical device quality systems”.

The aim of this article is to demonstrate a simple way to set up tool validation.

Software List

Both ISO 13485 (in chapter 4.1.6) and the FDA Guidance (in chapter 4.8) require software validation to be commensurate with the risk of the software, regardless of the size of the company or the resources available. Accordingly, a quality management system requires an overview of the software applications used and their intended use. Preferably, this overview will also document whether the software is

• “Off the shelf” software (i.e. software that can be purchased as a mass product in stores),
• adapted software
• or even software explicitly developed for the intended use.

For standard software such as Microsoft Word, which is installed in the thousands, the probability that an error will be found through the swarm intelligence of its thousands of users is probably much higher than through tool validation. This circumstance should be taken into account in tool validation. It is possible that the process for standard software, which is only used for non-critical purposes, has already been completed at this stage.

Figure 1: Software list

Software Validation Plan

The software validation plan should include the following elements:

• Description of the software including intended use, intended users and their environment
• Software requirements
• Test specifications for software requirements
• Risk management plan for the software to be validated

These elements can either all be documented in one document with different sub-chapters or they can be outsourced to different documents. The latter is particularly suitable for more extensive requirements documents.

Description of software

The chapter or document describing the software should describe the intended use, the intended users and their environment. Use case diagrams can be beneficial to give a simple, visual overview:

User requirements in the software

The user requirements should be in a testable format and given a unique ID. At IMT, we mostly use the following syntax:

for example, such a requirement could be

or

Both requirements have a unique ID and can be tested. Requirements that cannot be tested are to be avoided. For example, “fast” should be replaced by a time such as “2 seconds”, or “bright” by “under an inspection lamp with 1500 lx”.

Test specifications for user requirements

Each user requirement requires at least one test. In addition to a unique ID, the test specification includes the test instruction and the acceptance criterion or expected result. A test for the UR-001 above could look like this:

Risk management plan for this software

Since the effects of a software error in the quality management system are different from those of a medical device, the risk management plan must also be adapted accordingly. In particular, the definitions of the impact categories must be considered differently. Depending on the area of application, the same impact categories take on completely different meanings. The impact category “critical” potentially means the death of a patient in the case of a medical device, but the loss of data in the case of medical device tracking software.

Testing and assessment

Before the validation report can be produced, the software must be tested and the risks assessed.

Testbericht

The software must be tested according to the test specification. In the process, not only a “pass/fail” must be logged for each test step, but also the actual behavior observed, so that the test can be re-enacted. Therefore, the software and its environmental conditions must also be logged. This includes:

• Name and manufacturer of the software
• Version, build number
• Operating system
• 32/64-Bit environment
• Peripherals used
• ….

Date, examiner and 4-eye-principle evaluation

Using the above example, the report could look as follows:

Risk analysis

The risk analysis should assess all known problems. In the case of software that is distributed for use in a regulated environment, a corresponding list of known anomalies is often also published. It is worthwhile to check the manufacturer’s support website or to contact support. In addition to problems known to the manufacturer, shortcomings such as missing features must also be assessed. If a risk is not acceptable, control measures must be defined to reduce the risk. As medical device manufacturers who are used to risk management according to ISO 14971, we recommend following the same process.

Software validation report

The software validation report should include the following elements:

• Identify software and environment
• Test report(s) or reference(s) thereto
• Risk management report on the known anomalies of the software
• Evidence that all requirements have been tested. This is most easily mapped via a traceability matrix.
• Formal evaluation and approval of the software for use

NB: For “smaller” applications, it is possible to produce the test report, risk analysis and validation report in one document.

Identifying the software and environment, test report

Often there is a matrix of validated versions and environments for the software. If this is the case, it should be mapped accordingly in the validation report:

Risk management report on the known anomalies of the software

The validation report shall further assess the residual risk arising from the use of this software. The focus is on the acceptability of the known anomalies and/or missing functions.

Traceability

Another aspect to cover is to prove that all requirements for the software have been tested. Depending on the scope of the requirements and the documentation of the tests, two ways of documenting this have emerged:

Forward linking of the requirements to the tests

A column is added to the requirement table where the requirement is checked:

This variant is particularly suitable for a small scope of requirements and if the entire validation is created in one document.

Traceability Matrix

In the case of extensive requirements documents or if the test implementation has its own IDs, it is advisable to create a traceability matrix that contrasts the requirements with the test specification and possibly the test report:

If several reports need to be mapped for different runtime environments and software versions, this can be mapped very easily in a traceability matrix by adding additional columns.

Formal evaluation and approval

Last but not least, the entire package of documentation should be evaluated and documented with an approval decision.

Summary

As shown in the images, the validation of the software in the quality management system is nothing more than the systematic, documented execution of the upper left and right corners of the V-model widely used in software development:

This includes:

• Intended benefits and requirements
• Risk management
• Validation of user requirements
• Assessing the risks
• Assessing the overall validation and approval of the software for its intended use.

Introduction

Embedded „system design“, „system architecture“, „software architecture“, what exactly is behind these terms? What do they mean? What are the definitions? Why is it important to differentiate between these two terms?

This article deals with the answers to these questions.

The system

Here, we are dealing with technical systems, Or more specifically, with embedded systems. An embedded system is defined as follows:

“An embedded system is an electronic computer that is integrated (embedded) in a technical context. In this context, the computer either performs monitoring, control or regulating functions or is responsible for some form of data or signal processing, for example in locking or unlocking, encoding or decoding or filtering.”

Source: Wikipedia

Very similar to this definition (source https://www.embedded-software-engineering.de):

“An embedded system is a binary-valued digital system (also called a computer system) that is embedded in and interacts with a surrounding technical system. Here, the computer usually takes over monitoring, control or regulation functions, but is often also responsible for some form of data or signal processing.”

These definitions can be clarified with the following diagram:

Figure 1: General embedded system with the desired function/responsibility, surrounded by external systems and one or more users.

For the sake of simplicity, we usually simply refer to the “system” we are dealing with. Throughout the remainder of this article, we will often only refer to the „system“, which means the corresponding technical or embedded system.

Architecture and design

In order to explain the terms, we must demonstrate how such a system is built. Figure 1 presents the embedded system as a black box. The structure of the system has not yet been defined. The components from which the system is to be built must be defined. This activity is known as “design”. A “system design” is therefore about defining and determining the system structure. Based on the diagram (Figure 2), the result of this design activity could look as follows:

Figure 2: Result (architecture) the first design iteration to define the components (architecture elements).

Design activities tend to be repetitive. This means that the components—referred to here as architectural elements—are decomposed until they are sufficiently defined. Only then can the creation (development) of the system begin.

The result of this design activity is called “architecture”. Figure 2 is therefore a first “system architecture” (strictly speaking, Figure 2 is a reference architecture of a general embedded system), although the term architecture still needs to be defined more precisely in this context. There is no single established definition of the term architecture. You can find a list of definitions here: Definition Software Architecture. While these are definitions of software architecture, they also apply to the term system architecture. The distinction lies in the scope—more on this below.

We use the following definition of architecture (from „Software Architecture in Practice – Third Edition“):

Definition of (software) architecture:

“The (software) architecture of a system is the set of structures needed to reason about the system, which comprise (software) elements, relations among them, and properties of both.”

It contains the following 3 sentences:

1. The architecture of a system is built from a set of structures.
2. These are the structures needed to be able to infer the system.
3. The structures include the elements, their relationships and their properties.

So, what does that mean?

The structures consist of the elements, their relationships and their properties. Architecture consists of structures, which are needed to ensure that the system behaves as required. The whole area of non-functional requirements is also meant here, in addition to the fulfillment of functional requirements. For example, requirements regarding further development usually influence the structure of the system. However, not all structures in a system belong to architecture. Not all structures are architecture-relevant. These structures are then no longer referred to as architecture, but as design.

“Design” is on the one hand the activity that leads to an architecture (see above), and on the other hand the term for all non-architectural results of the design activity.

Many definitions simplify things by stating that the rough structure or the structures defined early in the design process are architecture. All later or more detailed structures are design. However, these definitions are insufficient, as more detailed structures may well be necessary to meet the required demands. Also, in agile development, not everything relevant is defined early in the design process.

System versus software

Finally, the distinction between “system architecture” and “software architecture”: As already mentioned above, they differ in scope. The system architecture includes the structures of various system elements, such as hardware, software and mechanics. The software architecture, on the other hand, comprises the structures that define the structure of a software element (an element from the system architecture). This can be seen in the diagrams below:

Figure 3: System architecture diagram with hardware and software elements.

In the further decomposition of a software element, we eventually end up with the software architecture:

Figure 4: Software architecture diagram of software elements “Control Software”.

Summary

The most important terms and their definitions are summarized again in the following table:

Table 1: Terms and their meaning/definition

Introduction

The documentation for system and software architectures is explicitly required for medical systems with safety-critical requirements, such as patient monitoring systems or ventilators. In addition, proof must be provided that an architecture has also been implemented according to its definition. But even outside the regulated area, the accurate description of an architecture is useful for most applications, because the description of an architecture is not only proof that requirements have been fulfilled, but it also helps to detect errors in the specification at an early stage. This article shows which (auxiliary) means can be used to describe an architecture and what can be followed.

Description of architecture

As explained in the article on system and software architecture, the architecture of a system is “the set of structures needed to infer the system, or to ensure that the system satisfies the required properties. ”

Admittedly, this definition is rather abstract and shows no concrete reference to hardware, electronics or software. However, a system consists of different structures such as software, electronics or mechanics. In addition, a system can also be characterized by logical structures or temporally sequential processes. In this sense, the term “the architecture” can be misleading, as the singularity of the term architecture might suggest that an architecture consists of a single image. However, practical experience shows that a system must be viewed from many different angles (views) and thus must also be described. For example, a system may be divided into logical units and functions that do not necessarily correspond to the physical division. This can be shown by the following, highly simplified, example:

Figure 1: Logical and physical view of a client-server application and an associated scenario to connect the views.

But which is the right or best view, and most importantly, the one recognized by regulations?

An architecture description usually consists of showing different views, making connections between views, and making the fulfillment of different requirements clear. In this respect, the description of an architecture consists of several views, which highlight different aspects. That is, there is no one true view, but the description of an architecture takes into account different views equally [1].

Views of an architecture

The views are an essential part of the international ISO/IEC/IEEE 42010 standard [link to https://www.iso.org/standard/50508.html], which provides guidance on how to describe the architecture of a system. This standard was published in 2011 and is the result of a joint ISO and IEEE revision of the earlier (software-heavy) IEEE 1471 standard [link to https://standards.ieee.org/standard/1471-2000.html]. The original IEEE 1471 standard specified how to describe the architecture of a system. Further requirements, such as the structure of an architecture as well as requirements for description language, were added in 42010. However, the standard does not require a specific architecture description or description language. Instead, the practice of describing an architecture should be standardized.

Views are intended to represent a system by considering stakeholder requirements (concerns) based on defined viewpoints. Figure 2 shows how views, viewpoints, requirements and stakeholders are related.

Figure 2: Dependencies between views, positions, requirements and stakeholders based on the ISO 42010 standard

Due to IMT’s many years of experience in the field of system and software design, the following process has been established to create an architecture description, which is strongly based on the ISO 42010 standard:

• Identifying stakeholders
• Identifying description concerns/requirements
• Defining appropriate points of view (viewpoints)
• Creating views, based on the viewpoints
• Verifying the architecture using scenarios, repeating steps 4 and 5.

The individual steps are described in more detail in the following chapters.

Identifying stakeholders

In order to define the viewpoints in a targeted and, above all, systematic manner, the first step is to identify the stakeholders who work with and for the system, or make decisions about the system. These may include developers, product managers, risk managers, end users, production staff, project managers, etc.

Identifying concerns and requirements

The requirements for the architecture description should be recorded and documented based on the stakeholders identified. In addition to the context interview held with the stakeholders, information on requirements for architecture documentation can also be found in the user or system requirements. Table 1 shows how this might look using Figure 1 as an example.

Table 1: Identifying stakeholders and system-architecture expectations

Definition of appropriate points of view

The viewpoint is characterized by a set of requirements from the corresponding stakeholders, as well as different conventions regarding model types, notations and techniques for the views based on them. Table 2 gives an example of how the viewpoints can be defined. The corresponding notations must be defined in addition to the tabular list. This can be done either in each view separately, or, in terms of the 42010 standard, in a separate viewpoint-specific section.

Table 2: Definition of viewpoints

Viewpoints

A viewpoint is a type of template that can be (re)used across multiple systems and/or is interchangeable among architects. This template is then used to create system-specific views based on it. A well-known collection of viewpoints is the “4+1 view model https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf” by Kruchen or the arc42 template , which are used in software systems especially. However, the use of viewpoints is not limited to software architectures—they can be applied to any system.

The definition and choice of viewpoints is primarily determined by the concerns of the identified stakeholders. In the following chapters, we present three possible views, although this set is not applicable to every system.

In general, it is recommended to keep the number of views used to a reasonable minimum, as redundancies increase with each additional view. In addition, each view must be maintained, tracked and, most importantly, kept consistent throughout the course of the project. The resulting effort increases with the number of views. In this case, less is more—provided that the views allow the requirements to be proven.

The logical view

The logical view is often used as the (primary) viewpoint for devices consisting of hardware and software. In the process, the system is broken down into its individual logical parts and arranged. In this view, functional requirements can be assigned to components and possible functional redundancies within the system can be identified. Explicit assignment of system requirements makes sense, as this ensures traceability. Proof of traceability is required, especially for safety-critical systems. This applies not only to system architectures, but also to subsystem and software architectures.

Communication paths and timing sequences/dependencies can also be defined within the logical view, depending on the architectural language. A combination is presented, as logical division and the associated processes are extremely dependent. Alternatively, the processes can be represented in a dedicated view, in which case the design of the logical view and process view is usually repetitive.

The physical view

As with the logical view, different physical viewpoints can expand the description and understanding of the system. Physical views can be, for example, electronic, pneumatic or electromechanical views, which are useful depending on the requirements of the system. A physical view can also make sense for distributed software systems, in which implementing non-functional requirements such as scalability, availability or performance can be demonstrated.

The development view

The development view is often only implicit, but it is also very important for a smooth project workflow. This shows how the system to be developed can be divided into small work packages in order to assign them to individual developers or development teams. Not only can internal requirements such as reusability or the selection of development tools be taken into account, but this view also enables development costs and deadlines to be monitored throughout the course of the project. The development view is often not part of the formal system architecture, but is created as part of project planning.

Verification of architecture

Running scenarios is a popular tool for architecture verification. The most important key scenarios are defined depending on the requirements. A scenario is not a view in its own right, but builds on existing views by linking them. Therefore, a complete architecture description is the basis for verification, or rather, the scenarios can only be run if the architecture has been fully described. Analogous to the description of the logical or physical view, the sequence of the scenario is presented in diagram form. Object interaction diagrams are often used to represent the interaction between logical and/or physical elements (see also Figure 1). Such scenarios are not only used to verify an architecture, but also to help understand the structure of a system.

Summary

Often, different stakeholders are involved who place different demands on a system. In order to address these concerns specifically and to verify that they have been fulfilled, several views are needed to describe an architecture. These views can be derived from generally defined viewpoints. The viewpoints consist of universally applicable conventions and are thus interchangeable and reusable across multiple systems. Finally, an architecture description can be verified with the help of scenarios to demonstrate fulfillment of the most important requirements.

[1] Basic principle (II) of ISO 42010

Einleitung

Referenzen auf nichtexistierende Kapitel oder Dokumente, veraltete Abbildungen, inkonsistente Bezeichnungen!

Eine ungepflegte Systemarchitektur-Dokumentation wirft oft mehr Fragen auf, als sie zu beantworten im Stande ist. Dementsprechend sollte darauf geachtet werden, dass alle Informationen immer auf Stand gehalten werden.

Doch selbst mit den besten Vorsätzen, präzise definierten Arbeitsabläufen und streng eingehaltenen Entwicklungsprozessen, werden sich immer wieder einmal Fehler einschleichen. Dies hat zur Folge, dass man den Informationen doch nicht immer ganz vertraut und öfter auch in der Implementation nachsieht.

Im Folgenden wird das Problem des Informations-Managements im Systementwicklungsprozess beleuchtet. Dabei werden die Schwächen des «klassischen» dokumentenzentrierten Ansatzes angesprochen und alternative Ansätze aufgezeigt.

Wieso ist es so schwierig die, Informationen aktuell zu halten?

Eine Systemarchitektur hat eine hierarchische Struktur, welche üblicherweise in einem oder mehreren Dokumenten mittels Abbildungen und Text, beschrieben wird.

In Abbildung 1 ist ein Beispiel für die Struktur einer Systemarchitektur dargestellt. Die Pfeile stellen zum einen die hierarchische Abhängigkeit dar und zum anderen den Informationsfluss (Bezeichnungen etc.) im Zuge des Design-Prozesses.

Abbildung 1: Systemarchitektur Dokumente (mit Implementations-Artefakten) für ein System mit drei Teilsystemen.

Die Informationen sind also über mehrere Dokumente und Abbildungen verteilt und wenn eine Information an mehreren Stellen verwendet wird, handelt es sich immer um eine Duplikation. Man erstellt also jedes Mal eine Kopie der Information, wobei keinerlei Verbindung mehr zur Ursprungsinformation besteht.

Damit ist das Problem schon offensichtlich. Um eine Änderung korrekt durchzuführen, muss die Information an allen Stellen, wo diese verwendet wird, angepasst werden. Dies ist nicht nur sehr zeitaufwändig, sondern auch fehleranfällig, da völlig unbekannt ist, wo die entsprechende Information überall verwendet wird.

Das fortlaufende Kopieren und Weitergeben einer Information erinnert stark an das wohl allen bekannte Kinderspiel «Stille Post», wobei hier der Reiz gerade darin liegt, dass es unvermeidlich zu Fehlern kommt.

In Abbildung 2 dient dieses einfache Spiel, zum Aufzeigen dessen, was mit einer Parameterbezeichnung passieren könnte – in diesem Fall sogar, ohne einen inhaltlichen Fehler einzuführen. Für die Verständlichkeit einer Systemarchitektur ist dies jedoch auch sehr abträglich.

Abbildung 2: Problem von Informationsduplizierung, veranschaulicht anhand des Kinderspiels «Stille Post»

Wie kann das divergieren von Informationen verhindert werden?

Wenn wir uns das «Stille Post»-Beispiel ansehen, ist die Lösung wohl offensichtlich.

Abbildung 3: Der erste in der Reihe stellt sicher, dass alle die Information direkt von ihm erhalten. Die Information kann nicht divergieren, wenn sie immer aus einer einzigen Quelle stammt.

Und so einfach ist der ganze Spass des Spiels zunichtegemacht. Für alle anderen Fälle, in denen abweichende Informationen keinen Spass machen, bringt dies jedoch einen grossen Vorteil.

In der Softwareentwicklung gibt es ein Grundprinzip, welches genau darauf abzielt: «Don’t repeat yourself». Hauptziel ist, Redundanz zu vermeiden, um die Widerspruchsfreiheit zu erhöhen. Dieses Prinzip kann auch auf eine Systemarchitektur angewendet werden. Damit wäre es möglich, diese einfach und mit geringem Fehlerrisiko auf Stand zu halten, wovon nicht nur der Design-Prozess profitiert, sondern auch der Entwicklungs- und LifeCycle-Prozess.

Ein weiterer Weg, dies zu erreichen, ist die andauernde Synchronisation der Informationen. Dabei wird die Änderung einer Information automatisch an alle Instanzen, welche diese benutzen, propagiert. Dabei handelt es sich um einen dezentralen Ansatz, bei welchem eine Softwareentwicklungs-Analogie am ehesten einem Git-Repository, mit der Möglichkeit zum Zusammenführen (merge), mehrerer Informationsbestände entspricht.

Wie lässt sich dies umsetzen?

Single Point of Definition

Ebenfalls aus der Softwareentwicklung kommt ein Ansatz, den man entweder als pragmatisch oder radikal betrachten kann, «the Code is the design». Vielleicht ist dieser Ansatz auch ein Resultat des «Law of the Instrument» («Wer nur einen Hammer hat, sieht in jedem Problem einen Nagel»).

Und obwohl die Schlichtheit dieser Idee einen gewissen Reiz hat, bringt sie zu viele Limitierungen mit sich.

• Limitierung auf reine Software-Projekte.
• Die Verständlichkeit leidet enorm an einer Überfrachtung mit zu vielen unnötigen Details.
• Das rein textbasierte Medium erlaubt keinerlei grafische Elemente zur Erläuterung.

Ein etwas generellerer Ansatz ist die Verwendung eines zentralen Informationsmanagers, welcher Informationen zentral verwaltet und für die unterschiedlichen Einsatzgebiete zur Verfügung stellt. Diese Idee ist auch nicht neu und wird in der Softwareentwicklung zum Beispiel im «Model View Controller»-Konzept verwendet. In der Systementwicklung spricht man dabei oft von «Model based …» oder «Model driven …». Dabei versteht man unter «Model» den Ort, an dem die zentralen Daten abgelegt bzw. verwaltet werden.

In Abbildung 4 ist das weiter oben gezeigte Beispiel der Struktur einer Systemarchitektur dargestellt, wobei eine zentrale Informationsmanagement-Instanz hinzugefügt wurde.

Abbildung 4: Systemarchitektur für ein System mit drei Teilsystemen mit zentraler Informationshaltung.

Dieser Ansatz benötigt aber eine stärkere Unterstützung durch spezifische Softwarelösungen, da Informationen vom «System Model» bezogen werden müssen. Als Folge dessen sind die Architektur-Dokumente nicht mehr das direkte Ausgangsprodukt des Designprozesses, sondern müssen in einem gesonderten Schritt, aus dem «System Model», generiert werden.

Doch auch, wenn dies eine gewisse Umstellung in den gewohnten Arbeitsmitteln mit sich bringt, überwiegen die Vorteile einer solchen Lösung. Dies ist nicht zuletzt daran zu sehen, dass sich ähnliche Konzepte in anderen Gebieten bereits durchgesetzt haben. Als Beispiele seien hier die CAD-Software für die Mechanikentwicklung oder ECAD-Software für die Elektronikentwicklung erwähnt. In der IMT werden hierfür zum Beispiel «SOLIDWORKS 3D CAD» und «Altium Designer» eingesetzt.

Synchronisation

Eine geläufige Bezeichnung für diesen Ansatz ist «Roundtrip engineering», dabei sollen Informationen in unterschiedlichen Dokumenten, Software-Artefakten, etc. synchron gehalten werden.  Es beschreibt damit so etwas, wie das Idealbild einer Software Architektur oder gar einer ganzen Produktumsetzung. Unabhängig an welcher Stelle ich eine Information verändere wird diese automatisch an allen Stellen, wo sie verwendet wird, nachgeführt. Es verspricht sogar noch mehr, unabhängig davon, ob eine neue Komponente in der Architektur oder der Implementation hinzugefügt wird, erhält man denselben vollständigen Satz an Dokumenten, Software-Artefakten, etc. So schön dies auch wäre, beginnt hier diese Utopie etwas zu bröckeln.

Das grundlegende Problem ist, dass dies eine eineindeutige Beziehung zwischen allen hierarchischen Ebenen voraussetzt. Dies würde nicht nur zu sehr strikten Einschränkungen bei der Umsetzung führen, sondern ist in manchen Fällen zudem nicht erreichbar, da durch die Abstraktion auf höheren Ebenen gar nicht die gesamte Information vorhanden ist.

Doch betrachten wir das etwas pragmatisch, zeigt sich, dass dies für den Anwendungsfall der Systementwicklung auch gar nicht nötig ist. Vielmehr scheint es für mich viel verständlicher, wenn klar definiert ist, auf welcher Ebene welche Information definiert ist. Mit der Ausnahme dieser Einschränkung kann die zentrale Datenhaltung, welche zuvor vorgestellt wurde, dieselbe Funktionalität zur Verfügung stellen.

Kann die zentrale Information auch über die Systemarchitektur hinaus verwendet werden?

Natürlich wäre es konsequent, in möglichst allen Aspekten der Systementwicklung, diese zentralen Daten zu verwenden. Dies erfordert jedoch eine Integration aller dafür notwendigen Funktionen in eine Softwarelösung, oder zumindest eine definierte Schnittstelle, um die Informationen zu teilen. Da die unterschiedlichen Gebiete der Systementwicklung jedoch jeweils sehr spezifische Anforderungen haben und es dafür bereits sehr gute eigenständige Softwarelösungen gibt (z.B. «SOLIDWORKS 3D CAD» und «Altium Designer»), wäre es wohl mit einem enormen Aufwand verbunden, die Informationen auch direkt in den spezifischen CAD-Anwendungen zu verwenden.

Für den agilsten Teil der Systementwicklung, die Softwareentwicklung, ist es aber gut möglich, mit Hilfe von Code-Generierung, die Struktur und sogenannten «Boilerplate-Code», für die Implementation zu erzeugen. Damit können die Vorteile des zentralen Informationsmanagements bis in die Umsetzung hinein genutzt werden. Die IMT setzt hierfür auf das eigene, im Haus entwickelte Software-Tool «DATAFLOW Designer», welches neben dem Bereitstellen von Boilerplate-Code auch beim Nachweis der Normenkonformität unterstützt.

Zusammenfassung

Das Ziel ist eine aktuelle, widerspruchsfreie und verständliche System Architektur, welche jedem Entwickler die benötigten Informationen einfach und schnell zur Verfügung stellt. Um dies zu erreichen, sollte die Entwickler bei der Erstellung und Anpassung bestmöglich unterstützt werden. Ein fundamentaler Baustein dafür stellt das zentrale Informations-Management dar, mit dem es möglich ist, die Entwickler vom Design bis zur Umsetzung auf vielseitige Weise zu unterstützen. Die erzielbaren Effizienz- und Qualitätssteigerungen kommen dabei sowohl dem Kunden als auch dem Entwickler zugute.

Einleitung

Die (EN) ISO 13485 in Ihrer Ausgabe von 2016, genauso wie die FDA Guidances und die Europäische Medical Device Regulation (MDR) fordern, dass Software, welche im Qualitätsmanagement System der Medizingerätehersteller verwendet wird, zu validieren sei. Während die ISO 13485 und die EU MDR nicht weiter beschreiben, wie die Toolvalidierung auszusehen hat, hat die US FDA am 11. Januar 2002 eine Guidance veröffentlicht: “General Principles of Software Validation; Final Guidance for Industry and FDA Staff”. Auch die Arbeitsgruppen von ISO und IEC haben sich Gedanken zu diesem Thema gemacht und 2017 den ISO/TR 80002-2 veröffentlicht: «Validation of software for medical device quality systems».

Ziel dieses Artikels ist es, einen einfachen Weg aufzuzeigen, wie eine solche Tool-Validierung aufgebaut werden kann.

Software Liste

Beide, die ISO 13485 (in Kapitel 4.1.6) und die FDA Guidance (in Kapitel 4.8) fordern, dass die Validierung der Software dem Risiko der Software entspricht, unabhängig von der Firmengrösse oder der zur Verfügung stehenden Ressourcen. Dementsprechend benötig ein Qualitätsmanagementsystem eine Übersicht über die eingesetzten Softwareapplikationen sowie ihres Verwendungszwecks. Vorzugsweise wird in dieser Übersicht auch dokumentiert ob es sich um eine

• «Off the shelf» Software (also eine Software die als Massenprodukt im Handel erworben werden kann),
• eine angepasste Software
• oder sogar um eine explizit für den geplanten Einsatz entwickelte Software handelt.

Eine Standard-Software wie z.B. Word von Microsoft sind zu tausenden installiert, die Wahrscheinlichkeit, dass die Schwarmintelligenz dieser tausenden von Nutzern ein Fehler findet, ist wohl um einiges höher, als meine Tool Validierung. Diesem Umstand darf in der Toolvalidierung Rechnung getragen werden. Der Prozess für Standard Software, welche nur für nicht-kritische Zwecke verwendet wird, kann unter Umständen bereits hier abgeschlossen werden.

Abbildung 1: Software Liste

Software Validierungsplan

Der Software-Validierungsplan bzw. Toolvalidierung sollte folgende Elemente enthalten:

1. Beschreibung der Software inklusive vorgesehenen Gebrauch, vorgesehene Nutzer und deren Umgebung
2. Anforderungen an die Software
3. Testspezifikation für die Softwareanforderungen
4. Risikomanagement Plan für die zu validierende Software

Diese Elemente können entweder alle in einem Dokument mit verschiedenen Unterkapitel dokumentiert werden, oder aber in verschiedene Dokumente ausgelagert. Letzteres eignet sich vor allem bei umfangreicheren Anforderungsdokumenten.

Beschreibung der Software

Das Kapitel oder Dokument mit der Beschreibung der Software soll den vorgesehenen gebrauch, die vorgesehenen Nutzer und deren Umgebung beschreiben. Use Case Diagramme können hier von Vorteil sein um eine einfache, visuelle Übersicht zu geben:

Abbildung 2: Use Case Diagram – Benutzer Verwalten

Software Nutzer Anforderungen

Die Nutzer-Anforderungen sollten in einer testbaren Form erfasst und mit einer eindeutigen ID versehen werden. Wir bei IMT nutzen hier meist die folgende Syntax:

zum Beispiel könnte eine solche Anforderung heissen

oder

Beide Anforderungen haben eine eindeutige ID und können getestet werden. Anforderungen welche nicht getestet werden können sind zu vermeiden, so sollte «schnell» durch eine Zeitangabe wie «2 Sekunden» ersetzt werden, oder «hell» durch «unter einer Inspektionslampe mit 1500lx».

Testspezifikation für die Nutzer-Anforderungen

Jede Nutzer-Anforderung benötigt im Minimum einen Test. Zur Testspezifikation gehört neben einer eindeutigen ID, die Prüfanweisung sowie das Akzeptanzkriterium oder erwartete Resultat. So könnte ein Test für obiges UR-001 aussehen:

Risikomanagement Plan für diese Software

Da die Auswirkungen bei einem Fehler der Software im Qualitätsmanagementsystem anders sind, als bei einem Medizinprodukt, muss auch der Risikomanagementplan entsprechend angepasst sein. Insbesondere die Definitionen der Auswirkungskategorien benötigen eine differenzierte Betrachtung. Je nach Anwendungsbereich bekommen die selben Auswirkungskategorien eine völlig unterschiedliche Bedeutung. Die Auswirkungskategorie «kritisch» bedeutet bei einem Medizingerät möglicherweise den Tod eines Patienten, bei einer Software zur Rückverfolgung der Medizingeräte dagegen der Verlust von Daten.

Prüfen und Bewerten

Bevor der Validierungsbericht erstellt werden kann, muss die Software getestet und die Risiken müssen bewertet werden.

Testbericht

Die Software ist gemäss der Prüfspezifikation zu prüfen. Dabei ist zu jedem Prüfschritt nicht nur ein «Pass/Fail» zu protokollieren, sondern auch das tatsächlich beobachtete Verhalten, so dass die Prüfung nachgestellt werden kann. Daher muss auch die Software und ihre Umgebungsbedingungen protokolliert werden. Dazu gehören:

• Name und Hersteller der Software
• Version, Build Nummer
• Betriebssystem
• 32/64 Bit Umgebung
• Verwendete Peripherie
• ….

Aber auch Datum, Prüfer sowie eine Bewertung im 4-Augen-Prinzip gehört dazu:

Ein solcher Report für obiges Beispiel könnte wie folgt aussehen:

Risikoanalyse

In der Risikoanalyse sollten alle bekannten Probleme bewertet werden. Bei Software, welche mit dem Zweck des Einsatzes in regulierter Umgebung vertrieben wird, wird oft auch eine entsprechende Liste der bekannten Anomalien veröffentlicht. Hier lohnt es sich auf der Support-Webseite vom Hersteller nachzusehen oder den Support zu kontaktieren. Neben den Problemen die dem Hersteller bekannt sind, sind auch Unzulänglichkeiten wie fehlende Features zu bewerten. Ist ein Risiko nicht akzeptabel, müssen Kontrollmassnahmen definiert werden, um das Risiko zu reduzieren. Als Medizingerätehersteller, welche sich an Risikomanagement nach ISO 14971 gewöhnt sind, empfehlen wir, dabei dem gleichen Prozess zu folgen.

Software Validierungsbericht

Der Software Validierungsreport sollte folgende Elemente enthalten:

1. Identifikation der Software und Umgebung
2. Testbericht(e) oder Verweis(e) darauf
3. Risikomanagementbericht über die bekannten Anomalien der Software
4. Nachweis, dass alle Anforderungen geprüft wurden. Dies lässt sich am einfachsten über eine Traceability Matrix abbilden.
5. Formelle Bewertung und Freigabe der Software zur Nutzung

Hinweis: Für «kleinere» Applikationen, kann möglicherweise Testreport, Risikoanalyse und Validierungsbericht auch in einem Dokument erstellt werden.

Identifikation der Software und Umgebung, Testbericht

Oft gibt es für die Software eine Matrix der validierten Versionen und Umgebungen, dann sollte diese im Validierungsbericht entsprechend abgebildet werden:

Risikomanagementbericht über die bekannten Anomalien der Software

Der Validierungsbericht soll weiter das Restrisiko welche durch die Nutzung dieser Software entsteht bewerten. Insbesondere liegt hier der Fokus auf der Akzeptabilität der bekannten Anomalien und/oder fehlenden Funktionen.

Traceability

Ein weiterer Aspekt den es abzudecken gibt, ist nachzuweisen dass alle Anforderungen an die Software getestet wurden. Je nach Umfang der Anforderungen und der Dokumentation der Tests haben sich zwei Möglichkeiten herausgeschält dies zu dokumentieren:

Vorwärts-Verlinkung der Anforderungen zu den Tests

Die Anforderungstabelle wird um eine Spalte ergänzt, wo die Anforderung geprüft wird:

Diese Variante eignet sich vor allem bei kleinem Umfang an Anforderungen und wenn die gesamte Validierung in einem Dokument erstellt wird.

Traceability-Matrix

Bei umfangreichen Anforderungsdokumenten oder wenn die Testdurchführung ihre eigenen ID’s besitzt, empfiehlt es sich eine Traceability Matrix zu erstellen, welche die Anforderungen der Testspezifikation und eventuell dem Testbericht gegenüberstellt:

Sollen mehrere Berichte für verschiedene Laufzeitumgebungen und Softwareversionen abgebildet werden müssen, so kann dies in einer Traceability Matrix sehr einfach durch zusätzliche Spalten abgebildet werden.

Formelle Bewertung und Freigabe

Zu guter Letzt soll das Gesamtpaket der Dokumentation bewertet und mit einem Entscheid der Freigabe dokumentiert werden.

Zusammenfassung

Bildlich dargestellt, ist die Validierung der Software im Qualitätsmanagementsystem nichts anderes, als die Systematische, dokumentierte Durchführung der linken und rechten, oberen Ecken des in der Softwareentwicklung weit verbreiteten V-Modells:

Dazu gehören:

• Vorgesehener Nutzen sowie Anforderungen
• Risikomanagement
• Validierung der Nutzeranforderung
• Bewerten der Risiken
• Bewerten der Gesamtvalidieurng und Freigabe der Software für den vorgesehenen Nutzen.

Einleitung

Für medizinische Systeme mit sicherheitskritischen Anforderungen, wie z.B. Patientenüberwachungssysteme oder Beatmungsgeräte, ist die Dokumentation von System- und Software-Architekturen explizit erforderlich. Ergänzend muss ein Nachweis erfolgen, dass eine Architektur auch gemäss Ihrer Definition umgesetzt ist. Aber auch ausserhalb des regulierten Bereiches ist die sorgfältige Beschreibung einer Architektur für die meisten Anwendungen sinnvoll, denn die Beschreibung einer Architektur ist nicht nur ein Nachweis der Erfüllung von Anforderungen, sondern hilft auch, Fehler in der Spezifikation frühzeitig zu erkennen. Dieser Artikel zeigt, mit welchen (Hilfs-)Mitteln eine Architektur beschrieben werden kann und woran man sich dabei halten kann.

Beschreibung von Architekturen

Wie im Artikel über System- und Software-Architektur erläutert, ist die Architektur eines Systems «die Menge von Strukturen, welche benötigt werden, um auf das System schliessen zu können, respektive, um sicherzustellen, dass das System die geforderten Eigenschaften erfüllt. »

Zugegeben, diese Definition ist ziemlich abstrakt und zeigt keinen konkreten Bezug zu Hardware, Elektronik oder Software. Ein System besteht aber aus verschiedenen Strukturen wie Software, Elektronik oder Mechanik. Zusätzlich kann sich ein System auch durch logische Strukturen oder zeitlich aufeinanderfolgende Vorgänge charakterisieren. In diesem Sinne kann der Begriff «Die Architektur» irreführend sein, da die Singularität des Begriffes Architektur suggerieren könnte, dass eine Architektur aus einem einzigen Bild besteht. Die Praxis zeigt aber, dass ein System aus vielen unterschiedlichen Ansichten (Views) betrachtet und demnach auch beschrieben werden muss. Beispielsweise kann ein System in logische Einheiten und Funktionen unterteilt werden, die nicht unbedingt mit der physikalischen Aufteilung übereinstimmen. Dies kann anhand des folgenden, stark vereinfachten, Beispiels gezeigt werden:  

Abbildung 1: Logische und physikalische Sicht einer Client-Server-Anwendung sowie ein zugehöriges Szenario, um die Ansichten zu verbinden.

Aber welche ist die richtige oder beste, und vor allem von Regularien anerkannte Ansicht?

Eine Architekturbeschreibung besteht in der Regel genau darin, unterschiedlichen Ansichten aufzuzeigen, Verbindungen zwischen den Ansichten herzustellen und das Erfüllen von unterschiedlichen Anforderungen deutlich zu machen. Insofern besteht die Beschreibung einer Architektur aus mehreren Ansichten, welche unterschiedliche Aspekte beleuchten. Das heisst, es gibt nicht die einzig wahre Ansicht, sondern die Beschreibung einer Architektur berücksichtigt unterschiedliche Ansichten gleichwertig^[1].

Ansichten einer Architektur

Die Ansichten sind ein wesentlicher Bestandteil des internationalen ISO/IEC/IEEE 42010-Standards [link to https://www.iso.org/standard/50508.html], welcher eine Leitlinie bietet, wie die Architektur eines Systems zu beschreiben ist. Dieser Standard wurde 2011 veröffentlicht und ist das Resultat einer gemeinsamen ISO- und IEEE-Überarbeitung des früheren (stark Software-geprägten) IEEE 1471-Standards [link to https://standards.ieee.org/standard/1471-2000.html]. Der ursprüngliche IEEE 1471-Standard spezifizierte, wie die Architektur eines Systems zu beschreiben ist. Weitere Anforderungen wie der Aufbau einer Architektur sowie Anforderungen an die Beschreibungssprache wurden in 42010 ergänzt. Der Standard erfordert jedoch keine spezifische Architekturbeschreibung oder Beschreibungssprache. Stattdessen sollte die Praxis der Beschreibung einer Architektur standardisiert werden.

Ansichten (engl. Views) sollen ein System abbilden, indem sie auf Basis definierter Standpunkte die Anforderungen (Concerns) der Stakeholder berücksichtigen. Abbildung 2 zeigt, wie Ansichten, Standpunkte, Anforderungen und Stakeholder zusammenhängen.

Abbildung 2: Abhängigkeiten zwischen Ansichten, Standpunkten, Anforderungen und Stakeholdern in Anlehnung an den ISO 42010- Standard

Für die Erstellung einer Architekturbeschreibung hat sich folgender Prozess etabliert, welcher stark an den ISO 42010-Standard angelehnt ist:

1. Identifikation der Stakeholder
2. Identifikation der Belange / Anforderungen an die Beschreibung
3. Definition der passenden Standpunkte (Viewpoints)
4. Erstellung der Ansichten, basierend auf den Standpunkten
5. Verifikation der Architektur mittels Szenarien, wobei die Schritte 4 und 5 iterativ erfolgen.

Die einzelnen Schritte werden in den folgenden Kapiteln näher beschrieben.

Identifikation der Stakeholder

Damit die Standpunkte gezielt und vor allem systematisch definiert werden können, sollen in einem ersten Schritt die Stakeholder identifiziert werden, welche mit und für das System arbeiten oder Entscheidungen über das System treffen. Das können unter anderem Entwickler, Produkt-Manager, Risk-Manager, Endanwender, Produktionsmitarbeiter, Projekt-Manager usw. sein.

Identifikation der Belange und Anforderungen

Auf der Basis der identifizierten Stakeholder sollen deren Anforderungen an die Architekturbeschreibung erfasst und dokumentiert werden. Ergänzend zum Kontext-Interview mit den Stakeholdern können Hinweise zu Anforderungen an die Architekturdokumentation auch in den User- oder System-Requirements zu finden sein. Tabelle 1 zeigt, wie dies am Beispiel von Abbildung 1 aussehen könnte.

Tabelle 1: Identifikation von Stakeholdern und Erwartungen an die System-Architektur

Definition der passenden Standpunkte

Der Standpunkt charakterisiert sich durch eine Menge von Anforderungen der entsprechenden Stakeholder sowie durch unterschiedliche Konventionen hinsichtlich Modell-Typen, Notationen sowie Techniken für die darauf aufbauenden Ansichten. Die Standpunkte können wie im Beispiel von Tabelle 2 definiert werden. Ergänzend zu der tabellarischen Aufführung müssen die entsprechenden Notationen definiert werden. Dies kann entweder in jeder Ansicht separat, oder, im Sinne des 42010-Standards, in einem separaten Standpunkt-spezifischen Abschnitt erfolgen.

Tabelle 2: Definition der Standpunkte

Definition eines Standpunktes

Ein Standpunkt ist eine Art Vorlage, welche über mehrere Systeme (wieder-)verwendet werden kann und/oder unter Architekten austauschbar ist. Eine solche Vorlage wird dann verwendet um auf deren Basis systemspezifische Ansichten zu erstellen. Eine bekannte Sammlung von Standpunkten ist das «4+1 view model» von Kruchen oder das arc42 template, welche insbesondere in Software-Systemen Anwendung finden. Die Verwendung von Standpunkten ist aber nicht nur auf Software-Architekturen limitiert, sie können auf beliebige Systeme angewendet werden.

Die Definition und Wahl der Standpunkte werden primär durch die Belange der identifizierten Stakeholder festgelegt. In den nachfolgenden Kapiteln stellen wir drei mögliche Standpunkte vor, wobei diese Zusammenstellung nicht für jedes System anwendbar ist.

Generell empfiehlt es sich, die Anzahl der verwendeten auf ein sinnvolles Minimum zu beschränken, da Redundanzen mit jedem zusätzlichen steigen. Ausserdem muss jede Ansicht, welche aus den Standpunkten erstellt wird, über den Projektverlauf gepflegt, nachgeführt und vor allem konsistent gehalten werden. Der resultierende Aufwand nimmt mit der Anzahl der Standpunkte und den erstellten Ansichten zu. Unter der Voraussetzung, dass die Standpunkte und deren Ansichten den Nachweis der Anforderungen ermöglichen, ist also in diesem Fall weniger mehr.

Der logische Standpunkt

Der logische Standpunkt wird für Geräte, bestehend aus Hard- und Software, häufig als (primären) Standpunkt verwendet. Dabei wird das System in seine logischen Einzelteile zerlegt und angeordnet. In den daraus erstellten Ansichten können insbesondere funktionale Anforderungen den Komponenten zugeordnet und mögliche funktionale Redundanzen innerhalb des Systems identifiziert werden. Eine explizite Zuordnung der Systemanforderungen ist sinnvoll, da dadurch die Rückverfolgbarkeit (Traceability) gewährleistet wird. Insbesondere für sicherheitskritische Systeme ist ein Nachweis der Rückverfolgbarkeit erforderlich. Dies gilt nicht nur für System-Architekturen, sondern auch für Subsystem- und Software-Architekturen.

Kommunikationswege und zeitliche Abfolgen/Abhängigkeiten können, je nach Architektursprache, ebenfalls innerhalb der logischen Ansicht definiert werden. Da die logische Aufteilung und die dazugehörigen Prozesse eine sehr starke Abhängigkeit haben, bietet sich eine Kombination an. Alternativ können die Prozesse in einer dedizierten Sicht dargestellt werden, wobei für diesen Fall das Design von logischer Sicht und Prozess-Sicht üblicherweise iterativ erfolgt.

Der physikalische Standpunkt

Gleichwertig zum logischen Standpunkt können unterschiedliche physikalische Standpunkte die Beschreibung und das Verständnis des Systems erweitern. Physikalische Standpunkte können beispielsweise elektronische, pneumatische oder elektromechanische Ansichten sein, welche je nach Anforderungen an das System sinnvoll sind. Auch für verteilte Software-Systeme kann ein physikalischer Standpunkt Sinn machen, in der die Umsetzung von nicht-funktionalen Anforderungen wie Skalierbarkeit, Verfügbarkeit oder Performance aufgezeigt werden kann.

Der Entwicklungs-Standpunkt

Eine häufig nur implizit durchgeführte, aber für einen reibungslosen Projektablauf sehr wichtiger Standpunkt, ist die Entwicklungssicht. Dabei wird aufgezeigt, wie das zu entwickelnde System in kleine Arbeitspakete aufgeteilt werden kann, um diese den einzelnen Entwicklern oder Entwicklungs-Teams zuzuweisen. Damit können nicht nur interne Anforderungen wie beispielsweise Wiederverwendbarkeit oder die Auswahl der Entwicklungs-Tools berücksichtigt werden, sondern eine solche Ansicht ermöglicht auch die Überwachung der Entwicklungskosten und Termine im Verlauf des Projektes. Die Entwicklungssicht ist häufig nicht Bestandteil der formalen System-Architektur, sondern wird im Rahmen der Projektplanung erstellt.

Verifikation der Architektur

Ein beliebtes Instrument zwecks Verifikation einer Architektur ist das Durchspielen von Szenarien. Dabei werden in Abhängigkeit von den Anforderungen die wichtigsten Schlüssel-Szenarien definiert. Ein Szenario ist keine eigene Ansicht, sondern baut auf bestehenden Ansichten auf, indem es diese in Verbindung bringt. Demnach ist eine vollständige Architekturbeschreibung die Grundlage für die Verifikation, respektive, die Szenarien können nur durchgespielt werden, sofern die Architektur vollständig beschrieben ist. Analog zur Beschreibung der logischen oder physikalischen Ansichten, wird der Ablauf des Szenarios in der Form eines Diagramms dargestellt. Häufig werden dazu Objekt-Interaktions-Diagramme verwendet um die Interaktion zwischen den logischen und/oder physikalischen Elementen darzustellen (siehe dazu auch Abbildung 1). Solche Szenarien dienen nicht nur der Verifikation einer Architektur, sondern helfen auch, den Aufbau eines Systems zu verstehen.

Zusammenfassung

Häufig sind unterschiedliche Stakeholder involviert, welche unterschiedliche Anforderungen an ein System stellen. Damit diese Anliegen gezielt adressiert und deren Erfüllung nachgewiesen werden kann, bedarf es zur Beschreibung einer Architektur mehrerer Ansichten. Diese Ansichten können von generell definierten Standpunkten abgeleitet werden. Die Standpunkte bestehen aus allgemein anwendbaren Konventionen und sind somit über mehrere Systeme hinweg austausch- und wiederverwendbar. Abschliessend zur Architekturbeschreibung kann diese mit Hilfe von Szenarien verifiziert werden, um die Erfüllung der wichtigsten Anforderungen nachzuweisen.

Einleitung

«System-Design», «System-Architektur», «Software-Architektur», was steckt genau hinter diesen Begriffen? Was ist damit gemeint? Was sind die Definitionen? Warum ist es wichtig diese Begriffe zu unterscheiden?

Mit Antworten auf diese Fragen beschäftigt sich dieser Artikel.

Das System

Wir beschäftigen uns hier mit technischen Systemen. Noch etwas spezifischer mit Embedded Systemen. Ein Embedded System, auf Deutsch ein «eingebettetes System» ist wie folgt definiert:

«Ein eingebettetes System ist ein elektronischer Rechner oder auch Computer, der in einen technischen Kontext eingebunden (eingebettet) ist. Dabei übernimmt der Rechner entweder Überwachungs-, Steuerungs- oder Regelfunktionen oder ist für eine Form der Daten- bzw. Signalverarbeitung zuständig, beispielsweise beim Ver- bzw. Entschlüsseln, Codieren bzw. Decodieren oder Filtern.»

Quelle: Wikipedia

Ganz ähnlich diese Definition (Quelle https://www.embedded-software-engineering.de):

«Ein eingebettetes System ist ein binärwertiges digitales System (auch Computersystem genannt), das in ein umgebendes technisches System eingebettet ist und mit diesem in Wechselwirkung steht. Dabei übernimmt der Rechner meist Überwachungs-, Steuerungs- oder Regelungsfunktionen, ist oft aber auch für eine Form der Daten- bzw. Signalverarbeitung zuständig.»

Diese Definitionen können mit dem folgenden Diagramm verdeutlicht werden:

Abbildung 1: Allgemeines Embedded System mit der gewünschten Funktion / Verantwortung umgeben von externen Systemen und einem oder mehrere Benutzer.

Der Einfachheitshalber wird meist einfach von dem „System“ gesprochen mit welchem man sich befasst. Auch im Rest dieses Artikels wird häufig nur noch von „System“ gesprochen und meint damit das entsprechende technische oder eben das Embedded System.

Architektur & Design

Um die Begriffe zu erklären, muss aufgezeigt werden, wie ein solches System gebaut wird. Abbildung 1 stellt das Embedded System als Blackbox dar. Der Aufbau des Systems ist noch nicht definiert. Es muss definiert werden aus welchen Bestandteilen das System aufgebaut werden soll. Diese Tätigkeit nennt man «Design». Bei einem «System-Design» geht es also um die Definition und Festlegung des Systemaufbaus. Das Resultat einer solchen Design-Tätigkeit könnte dann basierend auf dem Diagramm (Abbildung 2) wie folgt aussehen:

Abbildung 2: Resultat (Architektur) der ersten Design Iteration zur Definition der Bestandteile (Architekturelemente).

Meist läuft eine solche Design-Tätigkeit iterativ ab. Das heisst die Bestandteile – man spricht hier von Architekturelementen – werden soweit zerlegt (engl. «decompose»), bis diese genügend definiert sind. Erst dann kann die Erstellung (Entwicklung) des Systems beginnen.

Das Resultat dieser Design-Aktivität nenn man «Architektur». Die Abbildung 2 ist also eine erste «System-Architektur» (genau genommen ist die Abbildung 2 eine Referenzarchitektur eines allgemeinen Embedded System). Wobei der Begriff Architektur in diesem Zusammenhang noch genauer definiert werden muss. Es gibt nicht eine einzige etablierte Definition des Architektur-Begriffes. Eine Sammlung von Definitionen findet man hier: https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513807. Dies sind zwar Definitionen für Software-Architektur, gelten jedoch auch für den System-Architektur Begriff. Die Unterscheidung liegt im Anwendungsbereich (engl. Scope) –  dazu aber weiter unten noch mehr.

Wir verwenden die folgende Definition des Architektur-Begriffes (aus «Software Architecture in Practice – Third Edition»):

Definition (Software-) Architektur

“The (software) architecture of a system is the set of structures needed to reason about the system, which comprise (software) elements, relations among them, and properties of both.”

Übersetzt sind darin die folgenden 3 Sätze enthalten:

1. Die Architektur eines Systems ist aus einer Menge von Strukturen aufgebaut.
2. Es sind die Strukturen, welche benötig werden, um auf das System schliessen zu können.
3. Die Strukturen umfassen die Elemente, deren Beziehungen und deren Eigenschaften.

Was bedeutet das nun?

Die Strukturen bestehen aus Elementen, deren Beziehungen und deren Eigenschaften. Architektur besteht aus den Strukturen, welche benötigt werden, um sicherzustellen, dass sich das System wie gefordert verhält. Wobei hier nicht nur die Erfüllung der funktionalen Anforderungen gemeint ist, sondern auch der ganze Bereich der nicht-funktionalen Anforderungen. Beispielsweise haben Forderungen bezüglich Weiterentwickelbarkeit meist Einfluss auf die Struktur des Systems. Es gehören jedoch nicht alle Strukturen eines Systems zur Architektur. Nicht alle Strukturen sind Architektur-relevant. Man spricht bei diesen Strukturen dann nicht mehr von Architektur, sondern von Design.

«Design» ist einerseits die Tätigkeit, welche zu einer Architektur führt (siehe weiter oben), als auch der Begriff für sämtliche nicht Architektur-relevanten Resultate aus der Design Tätigkeit.

Viele Definitionen machen sich das einfacher, indem sie ausführen, die Grobstruktur oder die früh im Design Prozess definierten Strukturen sind Architektur. Alle späteren oder detaillierteren Strukturen sind Design. Diese Definitionen sind allerdings unzureichend, da durchaus detailliertere Strukturen notwendig sein können, um die geforderten Anforderungen zu erfüllen. Auch wird in einer agilen Entwicklung nicht alles Relevante schon früh im Design Prozess definiert.

System versus Software

Zuletzt noch die Unterscheidung zwischen «System-Architektur» und «Software-Architektur»: Wie bereits weiter oben aufgeführt unterscheiden sich diese im Anwendungsbereich (Scope). Die System-Architektur umfasst die Strukturen von verschiedenen System-Elementen, wie Hardware, Software, Mechanik. Die Software-Architektur hingegen umfasst die Strukturen, welche den Aufbau eines Software-Elementes (ein Element aus der System-Architektur) definieren. Dies ist in den nachfolgenden Diagrammen ersichtlich:

Abbildung 3: System Architektur Diagramm mit Hardware und Software Elementen.

Bei der weiterführenden Zerlegung eines Software Elementes landen wir schlussendlich bei der Software Architektur:

Abbildung 4: Software Architektur Diagramm des Software Elementes «Control Software».

Zusammenfassung

Tab. 1: Begriffe und deren Bedeutung resp. Definition