 Page 2Die Durchführung einer Daten- und Kontrollflussanalyse wird in fast allen funktionalen Sicherheitsstandards gefordert. Im Vergleich zu anderen Methoden und Maßnahmen, fristet die Daten- und Kontrollflussanalyse aber eher ein Schattendasein. Der Grund liegt vor allem auch darin, dass bisher die technologischen Fähigkeiten zur Durchführung einer solchen Analyse gefehlt haben. Die non-intrusive Systembeobachtungstechnologie der Firma Accemic (www.accemic.de) bietet nun die Möglichkeit die Daten- und Kontrollflüsse durch Tests nachzuweisen. Dadurch wiederum wird es möglich die funktionale Vollständigkeit der Requirements systematisch zu überprüfen. Definition Daten- und KontrollflussWikipedia definiert den Datenfluss wie folgt: „In der Informatik und Strukturierten Analyse bedeutet Datenfluss ein Element eines Datenflussdiagramms und benennt die Datenstrukturen, die zwischen zwei Funktionen ausgetauscht werden. Der Datenfluss definiert dabei die kausale Abhängigkeit der Funktionen und erlaubt es so, die Nebenläufigkeit einzelner Teilprozesse zu bestimmen. Kontrollfluss bedeutet gemäß Wikipedia: Der Kontrollfluss oder Programmablauf bezeichnet in der Informatik die zeitliche Abfolge der einzelnen Befehle eines Computerprogramms. Der Kontrollfluss eines Programms ist gewöhnlich durch die Reihenfolge der Befehle innerhalb des Programms vorgegeben, jedoch erlauben Kontrollstrukturen von der sequenziellen Abarbeitung des Programms abzuweichen. Die Daten- und Kontrollflussanalyse hat das Ziel den Daten- und Kontrollfluss einer Software zu analysieren und dessen Korrektheit nachzuweisen. Herausforderungen der Daten- und KontrollflussanalyseZunächst fällt es in der praktischen Anwendung sehr schwer eindeutig zwischen Daten- und Kontrollfluss zu unterscheiden. An vielen Stellen eines Softwareprogramms gibt es eine enge Kopplung zwischen einem Daten- und einem Kontrollfluss. Darüber hinaus gibt es in einer Software tendenziell unendliche viele Daten- und Kontrollflüsse. Ein vollständiger Nachweis der Korrektheit aller Daten- und Kontrollflüsse ist daher in der Praxis unmöglich. Dazu kommt, dass ein dynamischer Nachweis der Daten- und Kontrollflüsse bisher auch aus technologischen Gründen bisher nicht möglich war. In der Luftfahrt wurde bisher meist auf Unittests oder SW Integrationstest zurückgegriffen, um wichtige Daten- und Kontrollflüsse nachzuweisen. Da diese Tests aber nicht mit der realen Hardware durchgeführt werden, konnten keine Daten- und Kontrollflüsse unter Stressbedingungen für das gesamte Embedded System nachgewiesen werden. Auch für zeitkritische Applikationen, welche einen Großteil der Embedded Systeme darstellt, konnten diese Nachweise nicht erbracht werden. Non-intrusive SystembeobachtungDie non-intrusive Systembeobachtung bietet zukünftig die Möglichkeit Software Parameter und gleichzeitig andere externe und interne Ereignisse ohne Beeinflussung des Verhaltens des Gesamtsystems zu beobachten. Da solche Tests, im Vergleich zum Test mit dem Debugger vollautomatisierbar sind, wird es möglich Daten- und Kontrollflüsse in den Integrations- und Systemtests systematisch nachzuweisen. Da bei diesen Tests auch die funktionalen Requirements nachgewiesen werden, bietet diese Technologie eine Möglichkeit auch die Vollständigkeit der Requirements zu überprüfen. Wichtige Daten- und Kontrollflüsse spiegeln sich nämlich immer auch in Funktionalitäten des Systems. Aktivitätsdiagramme spezifizieren die Daten- und KontrollflüsseDie neuen Möglichkeiten welche sich durch die non-intrusive Systembeobachtung ergeben, lenken allerdings den Blick auch noch auf eine weitere Schwäche des bisherigen Vorgehens. Dies ist die Spezifikation der Daten- und Kontrollflüsse. In kaum einem Projekt, welches ich in den letzten Jahren begleitet habe, wurde der Daten- und Kontrollfluss systematisch spezifiziert. Diese Schwäche der meisten Projekte wird zukünftig mehr in den Mittelpunkt der Betrachtungen rücken. Sowohl der systematische Nachweis per Test, des Daten- und Kontrollflüsse, als auch die Vervollständigung ggf. vorhandener funktionaler Spezifikationslücken, sind nur wirklich erfolgreich, wenn in der Software Architektur zumindest die wichtigsten Daten- und Kontrollflüsse definiert sind. Wenn man in UML die Software Architektur beschreibt, bieten sich Aktivitätsdiagramme als gutes Mittel dafür an. FazitDie ISO 26262 (Teil 6 Tabelle 7 Punkte 1f und 1g) in der Automobilbranche, die DO178C (Tabelle A-7 Punkt 8) in der Luftfahrt und die EN 50128 und EN 50657 (jeweils Tabelle A19 Punkt 3 und 4) in der Bahnindustrie fordern eine Daten- und Kontrollflussanalyse. Bisher konnten für diesen Nachweis nur statische Analysen bzw. Unit- und SW Integrationstests als Nachweis de Daten- und Kontrollflusses herangezogen werden. Die non-intrusive Systembeobachtung macht es zukünftig möglich Daten- und Kontrollflüsse systematisch auf Integrations- und Gesamtsystemebene nachzuweisen. Diese neue Technologie bietet damit neben der Möglichkeit komplexe Fehlerszenarien zu testen, auch die Möglichkeit die Vollständigkeit der funktionalen Requirements zu überprüfen. Dies wird insbesondere dann zu einem mächtigen Qualitätsinstrument, wenn die Software Architektur die Daten- und Kontrollflüsse systematisch spezifiziert. UML bietet mit den Aktivitätsdiagrammen eine gute Methode an. Ihre individuellen Fragen zur Funktionalen Sicherheit beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch! Der Terminus Datenfluss hat mehrere Bedeutungen:
Das Prinzip des Datenflusses kann auch direkt zur Programmierung verwendet werden, etwa durch die Verwendung von Futures – auf diese Weise kann automatisch eine Parallelisierung bzw. Sequentialisierung des Prozessablaufes geplant werden. Die grafische Programmiersprache LabVIEW verwirklicht zum Beispiel diesen Ansatz.
In einer nebenläufigen Umgebung definiert der Datenfluss Punkte der Prozesssynchronisation zur Übergabe von Daten.
|
Was ist der unterschied zwieschen datenfluss und kntrollfluss
zusammenhängende Posts
Urheberrechte © © 2024 frojeostern Inc.
