„Arcadia (Ingenieurwesen)“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Versionsgeschichte interaktiv durchsuchen
[ungesichtete Version][ungesichtete Version]
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
Inhalt gelöscht Inhalt hinzugefügt
VisuellWikitext
Keine Bearbeitungszusammenfassung
Zeile 4: Zeile 4:
[[Datei:Arcadia logo.png|mini|ARCADIA, eine modellbasierte Engineering-Methode für System-, Hardware- und Software-Architekturdesign.]]
[[Datei:Arcadia logo.png|mini|ARCADIA, eine modellbasierte Engineering-Methode für System-, Hardware- und Software-Architekturdesign.]]
'''ARCADIA''' ('''Arc'''hitecture '''A'''nalysis & '''D'''esign '''I'''ntegrated '''A'''pproach) ist eine [[Systems engineering|System]]-Architekturmethode, basierend auf architekturzentrischen und [[Modellbasiertes Systems Engineering|Modellbasierten Systemsentwicklungs]]-Aktivitäten, die interdisziplinär alle ingenieurtechnischen Architektur-Design-Domänen umfasst. Die ARCADIA-Methode kann zur Definition des Designs jeder Art von System angewendet werden, wobei der Schwerpunkt auf der Beschreibung und Bewertung der Designeigenschaften (Kosten, Leistung, Sicherheit, Wiederverwendbarkeit, Verbrauch, Gewicht ...) liegt. Arcadia integiert dabei alle relevanten Aspekte für System-, Hardware- und Software-Architektur-Design.
'''ARCADIA''' ('''Arc'''hitecture '''A'''nalysis & '''D'''esign '''I'''ntegrated '''A'''pproach) ist eine [[Systems engineering|System]]-Architekturmethode, basierend auf architekturzentrischen und [[Modellbasiertes Systems Engineering|Modellbasierten Systemsentwicklungs]]-Aktivitäten, die interdisziplinär alle ingenieurtechnischen Architektur-Design-Domänen umfasst. Die ARCADIA-Methode kann zur Definition des Designs jeder Art von System angewendet werden, wobei der Schwerpunkt auf der Beschreibung und Bewertung der Designeigenschaften (Kosten, Leistung, Sicherheit, Wiederverwendbarkeit, Verbrauch, Gewicht ...) liegt. Arcadia integiert dabei alle relevanten Aspekte für System-, Hardware- und Software-Architektur-Design.

== Beschreibung ==

Arcadia-Methode beschreibt eine detaillierte Begründung, um den tatsächlichen Kundenbedarf zu verstehen, die Produktarchitektur zu definieren und sie allen Ingenieurwissenschafts[[Stakeholder]]n zur Verfügung zu stellen. Sie wird in fünf Hauptschritte strukturiert. Zwei Schritte, die den Verständnisteil beschreiben, sind „Betriebsanalyse“ und „Systembedarfsanalyse“, die anderen Schritte, die die Lösung beschreiben, sind „Logische Analyse“, „Physikalische Analyse“ und „Aufschlüsselungsstruktur des Endprodukts“.<ref>{{Literatur |Autor=Christophe Debruyne, Hervé Panetto, Wided Guédria, Peter Bollen, Ioana Ciuciu, George Karabatis, Robert Meersman |Titel=On the Move to Meaningful Internet Systems: OTM 2019 Workshops: Confederated International Workshops: EI2N, FBM, ICSP, Meta4eS and SIAnA 2019, Rhodes, Greece, October 21–25, 2019, Revised Selected Papers |Verlag=Springer Nature |Datum=2020 |ISBN=978-3-030-40907-4 |Seiten=129 |Online=https://books.google.de/books?id=RADQDwAAQBAJ&pg=PA129&dq=%22arcadia+is+a+method+devoted+to%22+five+major+steps&hl=de&sa=X&ved=2ahUKEwjI5oibi4r8AhV5SPEDHV9QAiIQ6AF6BAgAEAE#v=onepage&q=%22arcadia%20is%20a%20method%20devoted%20to%22%20five%20major%20steps&f=false |Abruf=2022-12-21}}</ref>


== Geschichte ==
== Geschichte ==

Version vom 21. Dezember 2022, 08:51 Uhr

Dieser Artikel wurde zur Löschung vorgeschlagen.

Falls du Autor des Artikels bist, lies dir bitte durch, was ein Löschantrag bedeutet, und entferne diesen Hinweis nicht.
Zur Löschdiskussion

Begründung: Klingt wie ein Werbeprospekt. In dieser Form ist es kein enzyklopädischer Artikel. Zudem werden als Nachweise die englische Wikipedia verwendet. --Viele Grüße, Alabasterstein (Diskussion) 13:29, 19. Dez. 2022 (CET)
ARCADIA, eine modellbasierte Engineering-Methode für System-, Hardware- und Software-Architekturdesign.

ARCADIA (Architecture Analysis & Design Integrated Approach) ist eine System-Architekturmethode, basierend auf architekturzentrischen und Modellbasierten Systemsentwicklungs-Aktivitäten, die interdisziplinär alle ingenieurtechnischen Architektur-Design-Domänen umfasst. Die ARCADIA-Methode kann zur Definition des Designs jeder Art von System angewendet werden, wobei der Schwerpunkt auf der Beschreibung und Bewertung der Designeigenschaften (Kosten, Leistung, Sicherheit, Wiederverwendbarkeit, Verbrauch, Gewicht ...) liegt. Arcadia integiert dabei alle relevanten Aspekte für System-, Hardware- und Software-Architektur-Design.

Beschreibung

Arcadia-Methode beschreibt eine detaillierte Begründung, um den tatsächlichen Kundenbedarf zu verstehen, die Produktarchitektur zu definieren und sie allen IngenieurwissenschaftsStakeholdern zur Verfügung zu stellen. Sie wird in fünf Hauptschritte strukturiert. Zwei Schritte, die den Verständnisteil beschreiben, sind „Betriebsanalyse“ und „Systembedarfsanalyse“, die anderen Schritte, die die Lösung beschreiben, sind „Logische Analyse“, „Physikalische Analyse“ und „Aufschlüsselungsstruktur des Endprodukts“.[1]

Geschichte

Frühere Praktiken konzentrierten sich im Entwicklungszyklus eines Systems eher auf die Definition von Anforderungen, deren Zuordnung zu jeder Komponente der Systemstruktur und der damit verbundenen Nachvollziehbarkeit. Aktuelle Ansätze konzentrieren sich eher auf Funktionsanalyse, Systemdesign, Begründung von Architekturentscheidungen und Verifikationsschritte.[2] Darüber hinaus berücksichtigt das Design nicht nur die funktionale Sichtweise, sondern auch andere Gesichtspunkte, die die Definition und Gliederung des Systems beeinflussen. Zum Beispiel einschränkende Bedingungen in Bezug auf Systemintegration, Produktlinien-Management, Sicherheit, Leistung und Durchführbarkeit. Beim Systems Engineering geht es also nicht nur um die Verwaltung der Systemanforderungen, sondern um eine komplexe Entwurfstätigkeit.

Standards und Normen

Die Arcadia-Methode wurde am 7. März 2018 als AFNOR-Norm XP Z67-140 standardisiert.[3]. AFNOR ist das französische Gegenstück zur DIN.

Kontext

Die Arcadia-Methode steht für das Design von komplexen- und kritischen-Systemen und allgemeinen Architekturen zur Verfügung, die mehreren funktionalen und nichtfunktionalen Anforderugen und operativen Einschränkungen unterliegen, einschließlich Software, Mechanik, Elektronik, elektrischer Infrastrukturen und industrieller Prozesse. Es geht dabei meist um komplexe mechatronische Systeme aus Hardware und Software, deren Systemarchitekturen von Systemarchitekten heute mit modell-basierten Verfahren geplant, konzipert, designed, gefertigt und in Betrieb genommen werden. Oftmals arbeiten dafür einzelne Fachbereiche nur in ihrem Bereich, quasi als Insel, mit häufig nicht ausreichendem Informationsaustausch mit denen, die von ihren Ergebnissen betroffen sind (Insel-artiges Vorgehen). Arcadia fasst solche Modellverfahren Fachbereichs-übergreifend zusammen und führt Design-Ingenieure durch den Entwicklungs-Prozess bis zur Beschaffung und Fertigung. Erste Branche waren Eisenbahnsignale,[4] dann Luft- und Raumfahrt, Microelektronik, komplexe Bauprojekte, komplexe Medizintechnik (CT, MRT usw.), kritische Energieinfrastruktur, Produktion etc. Arcadia definiert dafür eine Reihe von Praktiken, die durch Bedarfsanalyse und das Design führen, um operative Anforderungen zu erfüllen. Gleichzeitig ist es an die Prozesse und Einschränkungen anpassbar, die mit verschiedenen Arten von Lebenszyklen wie Bottom-up-Ansatz, Wiederverwendung von Anwendungen sowie agilen, inkrementellen, iterativen und partiellen Entwicklungsvorgängen verbunden sind.

Funktionale Zusammenfassung

Mit der Arcadia-Methode werden die Engineering-Aktivitäten umfassend abgedeckt, wobei mehrere Engineering-Ebenen berücksichtigt werden und Co-Engineering mit Spezial-Ingenieurtätigkeiten integriert wird. Außerdem können gemeinsam Eigenschaften der Definition und der Architektur validiert werden. Arcadia hat Erfahrungswerte aus großtechnischen Industrieanwendungen findet in diesem Kontext bis heute international Verwendung.

Methodischer Ansatz

Viewpoints
Zusammenarbeit

Eine der bei der Entwicklung komplexer Systeme häufig auftretenden Schwierigkeiten ergibt sich aus der Überlagerung mehrerer teilweise unabhängiger Funktionsketten unter Verwendung gemeinsamer Ressourcen (einschließlich, aber nicht beschränkt auf Rechenressourcen). Die Arcadia-Methode und die zugrunde liegenden Tools werden verwendet, um Funktionsketten, ihre sich überschneidenden Szenarien und die gewünschte Leistung sowie ihre Unterstützung durch die Architektur zu identifizieren. Beginnend mit der ersten Ebene der Systemanalyse stellen sie die Rückverfolgbarkeit während der gesamten Prozessdefinition sicher und prüfen jedes vorgeschlagene Architekturdesign auf die erwartete Leistung und Einschränkungen.

Auch die von der Systemlösung erwarteten nicht-funktionalen Eigenschaften werden in „Viewpoints“ formalisiert. Jeder Gesichtspunkt erfasst Einschränkungen, denen das System ausgesetzt sein oder die es erfüllen sollte (befürchtete Ereignisse, Sicherheitsbedrohungen, Latenzerwartungen, Produktlinien- oder Wiederverwendungseinschränkungen, Stromverbrauch oder Kostenprobleme und mehr). Anschließend wird das Architekturmodell automatisch analysiert, um zu überprüfen, ob es diese Einschränkungen erfüllt, dank dedizierter Expertenregeln (Leistungsberechnung, Ressourcenverbrauch, Sicherheitsbarrieren usw.). Diese Analyse kann sehr früh im Entwicklungszyklus durchgeführt werden, um Designprobleme so früh wie möglich zu erkennen ("frühe Validierung").

Zusammenfassend lässt sich sagen, dass der Ansatz zur Charakterisierung durch Ansichten (oder "Ansichtspunkte") überprüft, ob die vorgeschlagene Architektur in der Lage ist, die erforderlichen Funktionen mit dem gewünschten Maß an Leistung, Sicherheit, Zuverlässigkeit, Masse, Skalierbarkeit, Umgebungen, Masse und Schnittstellen bereitzustellen , etc. Gewährleistung der Konsistenz von Engineering-Entscheidungen, da alle Engineering-Stakeholder die gleichen Engineering-Informationen teilen und ihre eigenen Ansichten und Prüfungen darauf anwenden können, um die gemeinsame Definition sicherzustellen.

Darstellung des Ansatzes und Schlüsselkonzepte

Die verschiedenen Ebenen, die zum Ausarbeiten und Teilen des Architekturmodells verwendet werden, sind wie folgt aufeinander aufgebaut:

  • „Definiere das Problem – Analyse des operativen Bedarfs des Auftraggebers“,

Der erste Schritt konzentriert sich auf die Analyse der operativen Auftraggeberbedürfnisse und -ziele, die weit über die reinen System-/SW-Anforderungen hinausgehen.

  • „Formalisierung von System-/HW-/SW-Anforderungen – System-/HW-/SW-Bedarfsanalyse“,

Der zweite Schritt konzentriert sich auf die Anforderungen an das System sowie die Hardware und Software. Dabei ist zu definieren, wie das geplante System die frühen operativen Anforderungen erfüllen soll. Dabei werden das zu erwartende Verhalten und weitere Eigenschaften betrachtet: zu unterstützende System-/SW-Funktionen, zugehöriger Datenaustausch, nicht funktionale Rahmenbedingungen wie Sicherheit, Rollenverteilung und Interaktionen zwischen System und Betreibern.

Diese beiden Schritte, die den ersten Teil der Architektur-Struktur darstellen, geben das weitere Design vor und sollten daher mit dem Auftraggeber validiert werden .

  • "Entwicklung der System-/HW-/SW-Architektur – Logische Architektur",

Der dritte Schritt zielt darauf ab, die System-/HW-/SW-Teile (im Folgenden als Komponenten bezeichnet), ihre Inhalte, Beziehungen und Eigenschaften zu identifizieren, ohne bereits auf Implementierung oder technische/technologische Aspekte einzugehen. Dies bildet die logische System/SW-Architektur.

  • „Entwicklung der System-/HW-/SW-Architektur – Physische Architektur“,

Der vierte Schritt hat die gleichen Absichten wie das Erstellen einer logischen Architektur, außer dass er die „endgültige“ Architektur des Systems auf dieser Entwicklungsebene definiert. Hier können Architekturmuster, neue technische Dienste und von Komponenten verwendet werden

  • "Komponentenanforderungen formalisieren – Entwicklungsverträge und IVVQ",

Der fünfte und letzte Schritt ist ein Beitrag zum EPBS-Aufbau (End-Product Breakdown Structure), der auf der verherigen Architekturarbeit basiert, um weitere Details der Komponentenanforderungen abzuschern und einen gesicherten IVVQ vorzubereiten. Alle Entscheidungen, Hypothesen und Einschränkungen im Zusammenhang mit der gewählten System-/HW-/SW-Architektur werden hier zusammengefasst und überprüft.[5]

Die folgende Abbildung zeigt eine ganzheitliche Sicht, die den Arcadia-Prozess zusammenfasst, mit allen Elementen und Aktivitäten des V-Modells während des gesamten Definitions- und Designprozesses.

ARCADIA engineering phases
Breakdown

Die EBPS-Ebene bildet den Übergang zum Product Lifecycle Management (PLM) und allen damit verbundenen CAD- und CAE-Methoden (CAx) nebst zugehörigen Werkzeugen. Arcadia bildet damit eine zentrale Grundlage für umfassendes, domänen-übergreifendes und interoperabeles Digital Engineering. [6][7]

Kommunikation

Im Rahmen des Clarity-Projekts wurde ein Fachbuch über die Arcadia-Methode veröffentlicht.[8][9] In diesem Fachbuch finden sich weitere umfangreiche Angaben zur MBSE-Fachliteratur.

Die Arcadia-Methode wurde auf einer Vielzahl von Veranstaltungen und Konferenzen weltweit vorgestellt und entsprechen veröffentlicht. Hier sind nur die Veranstaltungen seit 2017 aufgeführt:

Conference Title Date Place
Capella Days 2022 More experiences of successful industrial deployments of Capella [10] 15/11/2022 Online
Capella Days 2021 The experience of industrial adopters who have successfully deployed Capella in various projects [11] 15/11/2021 Online
Capella Days 2020 Industrial MBSE case-studies with Capella [12] 12/10/2020 Online
Capella Day 2019 Successful Deployment of Capella [13] 16/09/2019 Munich
Capella Day 2018 The Status of Capella [14] 16/03/2018 Stuttgart
Capella Day 2017 Why are Arcadia and Capella relevant for MBSE? [15] 20/06/2017 Toulouse

Siehe auch

Weblinks

Einzelnachweise

  1. ↑ Christophe Debruyne, Hervé Panetto, Wided Guédria, Peter Bollen, Ioana Ciuciu, George Karabatis, Robert Meersman: On the Move to Meaningful Internet Systems: OTM 2019 Workshops: Confederated International Workshops: EI2N, FBM, ICSP, Meta4eS and SIAnA 2019, Rhodes, Greece, October 21–25, 2019, Revised Selected Papers. Springer Nature, 2020, ISBN 978-3-03040907-4, S. 129 (google.de [abgerufen am 21. Dezember 2022]).
  2. ↑ Carlo Ghezzi: ESEC '89: 2nd European Software Engineering Conference, University of Warwick, Coventry, UK, September 11-15, 1989. Proceedings. Springer Science & Business Media, 1989, ISBN 978-3-540-51635-4, S. 72 - 73 (google.de [abgerufen am 20. Dezember 2022]).
  3. ↑ Norme PR XP Z67-140 | Norm'Info. In: norminfo.afnor.org. Abgerufen am 1. Februar 2018 (französisch).
  4. ↑ Gauthier Fanmuy, Eric Goubault, Daniel Krob, François Stephan: Complex Systems Design & Management: Proceedings of the Seventh International Conference on Complex Systems Design & Management, CSD&M Paris 2016. Springer, 2016, ISBN 978-3-319-49103-5, S. 9.
  5. ↑ Rainer Stark: Virtual Product Creation in Industry: The Difficult Transformation from IT Enabler Technology to Core Engineering Competence. Springer Nature, 2022, ISBN 978-3-662-64301-3, S. 586 f.
  6. ↑ https://www.sebokwiki.org/wiki/Digital_Engineering
  7. ↑ https://ac.cto.mil/digital_engineering/
  8. ↑ ARCADIA Einführung. Abgerufen am 16. Dezember 2022.
  9. ↑ https://www.lehmanns.de/shop/mathematik-informatik/41149435-9780081017944-model-based-system-and-architecture-engineering-with-the-arcadia-method
  10. ↑ More successful deployments of Capella. Abgerufen am 15. Dezember 2022.
  11. ↑ Case study experiences with the deployment of Capella. Abgerufen am 17. November 2021.
  12. ↑ Capella Case Studies. Abgerufen am 13. Oktober 2020.
  13. ↑ Deployment of Capella. Abgerufen am 17. September 2019.
  14. ↑ Status of Capella. Abgerufen am 17. März 2018.
  15. ↑ Relevance of Capella. Abgerufen am 21. Juni 2017.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Arcadia_(Ingenieurwesen)&oldid=229050437“