„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
Keine Bearbeitungszusammenfassung
Zeile 48: Zeile 48:


* '''„Definiere das Problem – ''Analyse des operativen Bedarfs des Auftraggebers''“''',
* '''„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.
Der erste Schritt konzentriert sich auf die Analyse der Kundenbedürfnisse und -ziele, der erwarteten Missionen und Aktivitäten, weit über die System-/SW-Anforderungen hinaus. Es wird erwartet, dass dies eine gute Angemessenheit der System-/SW-Definition in Bezug auf ihre tatsächliche betriebliche Verwendung sicherstellt – und IVVQ-Bedingungen definiert. Die Ergebnisse dieses Schritts bestehen hauptsächlich in einer „Betriebsarchitektur“, die diesen Bedarf in Bezug auf Akteure/Nutzer, ihre betrieblichen Fähigkeiten und Aktivitäten, betriebliche Nutzungsszenarien mit Dimensionierungsparametern, betrieblichen Einschränkungen einschließlich Sicherheit, Lebenszyklus usw. beschreibt und strukturiert.


* '''„Formalisierung von System-/HW-/SW-Anforderungen – ''System-/SW-Bedarfsanalyse''“''',
* '''„Formalisierung von System-/HW-/SW-Anforderungen – ''System-/HW-/SW-Bedarfsanalyse''“''',
Der zweite Schritt konzentriert sich nun auf das System/die Software selbst, um zu definieren, wie es die früheren betrieblichen Anforderungen erfüllen kann, zusammen mit seinem erwarteten Verhalten und seinen Eigenschaften: zu unterstützende System-/SW-Funktionen und zugehöriger Austausch, nicht funktionale Einschränkungen (Sicherheit, Sicherheit...), der Systemgrenze zugeordnete Leistungen, Rollenverteilung und Interaktionen zwischen System und Betreibern. Es prüft auch die Machbarkeit (einschließlich Kosten, Zeitplan und Technologiereife) von Kundenanforderungen und gibt gegebenenfalls die Möglichkeit, deren Inhalt neu zu verhandeln. Dazu wird eine erste frühe System-/SW-Architektur (Architectural Design Model) aus System-/SW-Funktionsbedarf skizziert; Anschließend werden die Anforderungen anhand dieser Architektur untersucht, um ihre Kosten und Konsistenz zu bewerten.
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.
Die Ergebnisse dieses Schritts bestehen hauptsächlich aus der funktionalen Bedarfsbeschreibung des Systems/der Software, der Interoperabilität und Interaktion mit den Benutzern und externen Systemen (Funktionen, Austausch plus nicht-funktionale Beschränkungen) und den System-/SW-Anforderungen.


Beachten Sie, dass diese beiden Schritte, die den ersten Teil des Architekturbaus darstellen, das weitere Design „vorgeben“ und daher mit dem Kunden genehmigt/validiert werden sollten.
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''"''',
* '''"Entwicklung der System-/HW-/SW-Architektur – ''Logische Architektur''"''',
Der dritte Schritt zielt darauf ab, die System-/SW-Teile (im Folgenden als Komponenten bezeichnet), ihre Inhalte, Beziehungen und Eigenschaften zu identifizieren, ohne Implementierung oder technische/technologische Probleme. Dies bildet die logische System/SW-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.
Damit diese Aufteilung in Komponenten in weiteren Schritten stabil ist, werden alle wichtigen [nicht funktionalen] Einschränkungen (Sicherheit, Sicherheit, Leistung, IVV, Kosten, nicht technisch usw.) berücksichtigt und miteinander verglichen den besten Kompromiss zwischen ihnen zu finden.
Diese Methode wird als "Viewpoints-driven" beschrieben, wobei Viewpoints die Formalisierung der Art und Weise sind, wie diese Einschränkungen die System-/SW-Architektur beeinflussen. Die Ergebnisse dieses Schritts bestehen aus der ausgewählten logischen Architektur: Komponenten- und Schnittstellendefinition, einschließlich der Formalisierung aller Sichtweisen und der Art und Weise, wie sie im Komponentendesign berücksichtigt werden.
Da die Architektur gegen Need validiert werden muss, werden auch Verknüpfungen mit Anforderungen und Einsatzszenarien hergestellt.


* '''„Entwicklung der System-/HW-/SW-Architektur – ''Physische 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/der SW auf dieser Entwicklungsebene definiert, bereit zur Entwicklung (durch niedrigere Entwicklungsebenen). Daher werden Rationalisierungen, Architekturmuster, neue technische Dienste und Komponenten eingeführt und die logische Architektur entsprechend der Implementierung, den technischen und technologischen Einschränkungen und Entscheidungen (auf dieser Ebene des Engineerings) weiterentwickelt.
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
Beachten Sie, dass für die Definition der physischen Architektur die gleiche "Ansichtspunkt-gesteuerte" Methode wie für den Aufbau der logischen Architektur verwendet wird. Die Ergebnisse dieses Schritts bestehen aus der ausgewählten physikalischen Architektur: zu produzierenden Komponenten, einschließlich der Formalisierung aller Gesichtspunkte und der Art und Weise, wie sie im Komponentendesign berücksichtigt werden. Auch Verknüpfungen mit Anforderungen und Einsatzszenarien werden hergestellt.


* '''"Komponentenanforderungen formalisieren – ''Entwicklungsverträge und IVVQ''"''',
* '''"Komponentenanforderungen formalisieren – ''Entwicklungsverträge und IVVQ''"''',
Der fünfte und letzte Schritt ist ein Beitrag zum EPBS-Aufbau (End-Product Breakdown Structure), der aus der früheren Architekturarbeit Nutzen zieht, um die Definition der Komponentenanforderungen durchzusetzen und einen gesicherten IVVQ vorzubereiten.
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.
Alle Entscheidungen im Zusammenhang mit der gewählten System-/HW-/SW-Architektur und alle Hypothesen und Einschränkungen, die den Komponenten und der Architektur auferlegt werden, um den Bedürfnissen und Einschränkungen zu entsprechen, werden hier zusammengefasst und überprüft.
Die Ergebnisse dieses Schritts sind hauptsächlich "Komponentenintegrationsvertrag", der alle erforderlichen erwarteten Eigenschaften für jede zu entwickelnde Komponente sammelt.


Die folgende Abbildung zeigt eine ganzheitliche Sicht, die den Arcadia-Prozess zusammenfasst, mit allen Elementen und Aktivitäten des [[V-Modell]]s während des gesamten Definitions- und Designprozesses.
Die folgende Abbildung zeigt eine ganzheitliche Sicht, die den Arcadia-Prozess zusammenfasst, mit allen Elementen und Aktivitäten des [[V-Modell]]s während des gesamten Definitions- und Designprozesses.
Zeile 82: Zeile 75:
Im Rahmen des Clarity-Projekts wurde ein Buch über die Arcadia-Methode veröffentlicht. Eine Arcadia-Beschreibung steht auf der Capella-Website zur Verfügung.<ref>{{cite web|url=https://www.eclipse.org/capella/capella_mbse_ge.html#arcadia|title=ARCADIA Einführung|accessdate=2022-12-16}}</ref>
Im Rahmen des Clarity-Projekts wurde ein Buch über die Arcadia-Methode veröffentlicht. Eine Arcadia-Beschreibung steht auf der Capella-Website zur Verfügung.<ref>{{cite web|url=https://www.eclipse.org/capella/capella_mbse_ge.html#arcadia|title=ARCADIA Einführung|accessdate=2022-12-16}}</ref>


Die Arcadia-Methode wurde auf einer Vielzahl von Veranstaltungen weltweit vorgestellt:
Die Arcadia-Methode wurde auf einer Vielzahl von Veranstaltungen weltweit vorgestellt. Hier sind nur die Veranstaltungen seit 2017 aufgeführt:


{| class="wikitable" style="text-align:center;"
{| class="wikitable" style="text-align:center;"
Zeile 119: Zeile 112:
|style="width:100px"| 20/06/2017
|style="width:100px"| 20/06/2017
|style="width:100px"| [[Toulouse]]
|style="width:100px"| [[Toulouse]]

|-
|style="width:250px"| SiriusCon 2016
|style="width:450px"| Collaborative modeling with Capella and Sirius<ref>{{cite web|url=http://www.slideshare.net/Obeo_corp/siriuscon2016-capella-team-live-collaborative-modeling-with-sirius|title=Collaborative modeling with Capella and Sirius|accessdate=2016-11-15}}</ref>
|style="width:100px"| 15/11/2016
|style="width:100px"| [[Paris]]
|-
|style="width:250px"| Incose 2016
|style="width:450px"| Simplifying (and enriching) SysML to perform functional analysis and model instances<ref>{{cite web|url=https://www.eclipsecon.org/na2016/session/mars-exploration-guided-polarsys|title=Simplifying (and enriching) SysML to perform functional analysis and model instances|accessdate=2016-10-06|archive-url=https://web.archive.org/web/20161009112505/https://www.eclipsecon.org/na2016/session/mars-exploration-guided-polarsys|archive-date=2016-10-09|url-status=dead|df=}}</ref>
|style="width:100px"| 18/06/2016
|style="width:100px"| [[Edinburgh]]
|-
|style="width:250px"| EclipseCon France
|style="width:450px"| Hands-On Systems Modeling with ARCADIA / Capella<ref>{{cite web|url=https://www.eclipsecon.org/na2016/session/mars-exploration-guided-polarsys|title=Hands-On Systems Modeling with ARCADIA / Capella|accessdate=2016-10-06|archive-url=https://web.archive.org/web/20161009112505/https://www.eclipsecon.org/na2016/session/mars-exploration-guided-polarsys|archive-date=2016-10-09|url-status=dead|df=}}</ref>
|style="width:100px"| 07/06/2016
|style="width:100px"| [[Toulouse]]
|-
|style="width:250px"| Dutch Eclipse Day
|style="width:450px"| Model-based engineering with Capella: Status and perspectives<ref>{{cite web|url=https://www.eclipsecon.org/na2016/session/mars-exploration-guided-polarsys|title=Model-based engineering with Capella: Status and perspectives|accessdate=2016-10-06|archive-url=https://web.archive.org/web/20161009112505/https://www.eclipsecon.org/na2016/session/mars-exploration-guided-polarsys|archive-date=2016-10-09|url-status=dead|df=}}</ref>
|style="width:100px"| 18/04/2016
|style="width:100px"| [[Eindhoven]]
|-
|style="width:250px"| EclipseCon North America
|style="width:450px"| Mars exploration guided by PolarSys<ref>{{cite web|url=https://www.eclipsecon.org/na2016/session/mars-exploration-guided-polarsys|title=Mars exploration guided by PolarSys|accessdate=2016-10-06|archive-url=https://web.archive.org/web/20161009112505/https://www.eclipsecon.org/na2016/session/mars-exploration-guided-polarsys|archive-date=2016-10-09|url-status=dead|df=}}</ref>
|style="width:100px"| 07/03/2016
|style="width:100px"| [[Reston, Virginia|Reston]]
|-
|style="width:250px"| ERTS
|style="width:450px"| MBSE with ARCADIA Method and Capella Tool<ref>{{cite web|url=https://twitter.com/pascalRoques/status/692999198359359488|title=MBSE with ARCADIA Method and Capella Tool|accessdate=2016-10-06}}</ref>
|style="width:100px"| 27/01/2016
|style="width:100px"| [[Toulouse]]
|-
|style="width:250px"| MODELS
|style="width:450px"| CLARITY: Open-Sourcing the Model-Based Systems Engineering Solution Capella<ref>{{cite web|url=https://flux.cs.queensu.ca/oss4mde/files/2015/06/OSS4MDE15_paper_3.pdf|title==CLARITY: Open-Sourcing the Model-Based Systems Engineering Solution Capella|accessdate=2016-10-06|archive-url=https://web.archive.org/web/20160215060428/https://flux.cs.queensu.ca/oss4mde/files/2015/06/OSS4MDE15_paper_3.pdf|archive-date=2016-02-15|url-status=dead|df=}}</ref>
|style="width:100px"| 29/09/2015
|style="width:100px"| [[Ottawa]]
|-
|SPLC
|Tooling Support for Variability and Architectural Patterns in Systems Engineering
|23/07/2015
|[[Nashville]]
|-
| MODELS'16
| ARCADIA in a nutshell<ref>{{cite web|url=http://models2016.irisa.fr/tutorials/|title=ARCADIA in a nutshell|accessdate=2016-10-06}}</ref>
| 02/10/2016
| [[Saint-Malo]]
|-
| [[INCOSE International Symposium]]
| Implementing the MBSE Cultural Change: Organization, Coaching and Lessons Learned<ref>{{cite web|url=http://events.incose.org/sessiondetail_928|title=Implementing the MBSE Cultural Change: Organization, Coaching and Lessons Learned|accessdate=2015-10-23|archive-url=https://web.archive.org/web/20160303204501/http://events.incose.org/sessiondetail_928|archive-date=2016-03-03|url-status=dead}}</ref>
| 14/07/2015
| [[Seattle]]
|-
| INCOSE International Symposium
| From initial investigations up to large-scale rollout of an MBSE method and its supporting workbench: the Thales experience<ref>{{cite web|url=http://events.incose.org/sessiondetail_916|title=From initial investigations up to large-scale rollout of an MBSE method and its supporting workbench: the Thales experience|accessdate=2015-10-23|archive-url=https://web.archive.org/web/20160303203940/http://events.incose.org/sessiondetail_916|archive-date=2016-03-03|url-status=dead}}</ref>
| 14/07/2015
| [[Seattle]]
|-
| [[EclipseCon]] France
| Systems Modeling with the ARCADIA method and the Capella tool<ref>{{cite web|url=https://www.eclipsecon.org/france2015/session/systems-modeling-arcadia-method-and-capella-tool|title=Systems Modeling with the ARCADIA method and the Capella tool|accessdate=2015-10-23|archive-url=https://web.archive.org/web/20150914171138/https://www.eclipsecon.org/france2015/session/systems-modeling-arcadia-method-and-capella-tool|archive-date=2015-09-14|url-status=dead}}</ref>
| 24/06/2015
| [[Toulouse]]
|-
| Model-Based System Engineering (MBSE) Symposium
| The Challenges of Deploying MBSE Solutions<ref>{{cite web|url=http://www.sesa.org.au/downloads-usermenu-33/doc_download/420-the-challenges-of-deploying-mbse-solutions-introduction|title=The Challenges of Deploying MBSE Solutions|accessdate=2015-10-23}}</ref>
| 28/10/2014
| [[Canberra]]
|-
| Model-Based System Engineering (MBSE) Symposium
| Arcadia and Capella in the Field<ref>{{cite web|url=http://www.sesa.org.au/downloads-usermenu-33/doc_download/406-arcadia-and-capella-in-the-field|title=Arcadia and Capella in the Field |accessdate=2015-10-23}}</ref>
| 27/10/2014
| [[Canberra]]
|-
| EclipseCon France
| Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering<ref>{{cite web|url=https://www.eclipsecon.org/france2014/session/arcadia-capella-field-proven-modeling-solution-system-and-software-architecture-engineering|title=Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering|accessdate=2015-10-23|archive-url=https://archive.today/20151021040414/https://www.eclipsecon.org/france2014/session/arcadia-capella-field-proven-modeling-solution-system-and-software-architecture-engineering|archive-date=2015-10-21|url-status=dead}}</ref>
| 19/06/2014
| [[Toulouse]]
|-
| MDD4DRES ENSTA Summer school
| Feedbacks on System Engineering – ARCADIA, a model-based method for Architecture-centric Engineering<ref>{{cite web|url=http://www.mdd4dres.org/program/#JL|title=Feedbacks on System Engineering – ARCADIA|accessdate=2015-10-22}}</ref>
| 01/09/2014
| [[Aber Wrac'h]]
|-
| EclipseCon North America
| Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering<ref>{{cite web|url=https://www.eclipsecon.org/na2014/session/arcadia-capella-field-proven-modeling-solution-system-and-software-architecture-engineering |title=Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering |accessdate=2015-10-23 |url-status=dead |archiveurl=https://web.archive.org/web/20160303183801/https://www.eclipsecon.org/na2014/session/arcadia-capella-field-proven-modeling-solution-system-and-software-architecture-engineering |archivedate=2016-03-03 }}</ref>
| 20/03/2015
| [[San Francisco]]
|-
| Complex Systems Design & Management (CSDM)
| ARCADIA: Model-Based Collaboration for System, Software and Hardware Engineering<ref>{{cite web|url=http://www.csdm2013.csdm.fr/-Program-.html|title=Model-Based Collaboration for System, Software and Hardware Engineering|accessdate=2015-10-23}}</ref>
| 04/12/2013
| [[Paris]]
|-
| Congrès Ingénierie grands programmes et systèmes complexes
| La modélisation chez Thales : un support majeur à la collaboration des acteurs dans l’ingénierie des grands systèmes<ref>{{cite web|url=http://www.avantage-aquitaine.com/conferences/ingenierie13/assets/pdf/Programme%20IGPSC%20ed8.pdf|title=La modélisation chez Thales : un support majeur à la collaboration des acteurs dans l'ingénierie des grands systèmes|accessdate=2015-10-23|archive-url=https://web.archive.org/web/20160303170952/http://www.avantage-aquitaine.com/conferences/ingenierie13/assets/pdf/Programme%20IGPSC%20ed8.pdf|archive-date=2016-03-03|url-status=dead}}</ref>
| 10/06/2013
| [[Arcachon]]
|-
| MAST
| Toward integrated multi-level engineering - Thales and DCNS advanced Practices<ref>{{cite web|url=http://lanyrd.com/2013/mastconfex/scftxc/|title=Toward integrated multi-level engineering - Thales and DCNS advanced Practices|accessdate=2015-10-23}}</ref>
| 04/06/2013
| [[Gdańsk]]
|-
| CSDM
| Modelling languages for Functional Analysis put to the test of real life<ref>{{cite book|doi=10.1007/978-3-642-34404-6_9|title = Complex Systems Design & Management|pages = 139–150|year = 2013|last1 = Voirin|first1 = Jean-Luc|isbn = 978-3-642-34403-9|chapter = Modelling Languages for Functional Analysis Put to the Test of Real Life}}</ref>
| 2012
| [[Paris]]
|-
| ICAS
| Method and tools to secure and support collaborative architecting of constrained systems<ref>{{cite web|url=http://www.icas.org/ICAS_ARCHIVE/ICAS2010/ABSTRACTS/172.HTM|title=Method and tools to secure and support collaborative architecting of constrained systems|accessdate=2015-10-23}}</ref>
| 2010
| [[Nice]]
|-
| CSDM
| Model-driven Architecture building for constrained Systems<ref>{{cite web|url=http://www.cesames.net/fichier.php?id=291|title=Model-driven Architecture building for constrained Systems|accessdate=2015-10-23|archive-url=https://web.archive.org/web/20160303170640/http://www.cesames.net/fichier.php?id=291|archive-date=2016-03-03|url-status=dead}}</ref>
| 2010
| [[Paris]]
|-
| INCOSE;08 Symposium
| Method & Tools for constrained System Architecting<ref>{{cite journal|title=Method & Tools for constrained System Architecting| doi=10.1002/j.2334-5837.2008.tb00857.x|volume=18|journal=INCOSE International Symposium|pages=981–995|year = 2008|last1 = Voirin|first1 = Jean-Luc| s2cid=111113361}}</ref>
| 2008
| [[Utrecht]]
|}


== Siehe auch ==
== Siehe auch ==

Version vom 20. Dezember 2022, 18:18 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 relevante Aspekte für System-, Hardware- und Software-Architektur-Design.

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. 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.[1]. 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. Branchen sind Luft- und Raumfahrt, Microelektronik, Eisenbahnen, 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

Die Arcadia-Methode:

  • Deckt alle strukturierten Engineering-Aktivitäten ab, von der Erfassung der operativen Anforderungen des Kunden bis zur Validierung der Systemintegrationsverifizierung (IVV);
  • Berücksichtigt mehrere Engineering-Ebenen und die dafür erforderliche effektive Zusammenarbeit (System, Subsystem, Software, Hardware usw.);
  • Integriert Co-Engineering mit Spezial-Ingenieurtätigkeiten (Safety, Security, Performance, Schnittstellen, Logistik ...) und IVV;
  • Bietet die Möglichkeit, nicht nur beschreibende Modelle zu teilen, sondern auch gemeinsam Eigenschaften der Definition und der Architektur zu validieren;
  • Ist in großtechnischen Industrieanwendungen praxiserprobt und wird derzeit in Dutzenden von Großprojekten in mehreren Ländern sowie in Geschäftsbereichen von Thales eingesetzt.

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.

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. [2][3]

Kommunikation

Im Rahmen des Clarity-Projekts wurde ein Buch über die Arcadia-Methode veröffentlicht. Eine Arcadia-Beschreibung steht auf der Capella-Website zur Verfügung.[4]

Die Arcadia-Methode wurde auf einer Vielzahl von Veranstaltungen weltweit vorgestellt. Hier sind nur die Veranstaltungen seit 2017 aufgeführt:

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


Siehe auch

Einzelnachweise

  1. ↑ Norme PR XP Z67-140 | Norm'Info. In: norminfo.afnor.org. Abgerufen am 1. Februar 2018 (französisch).
  2. ↑ https://www.sebokwiki.org/wiki/Digital_Engineering
  3. ↑ https://ac.cto.mil/digital_engineering/
  4. ↑ ARCADIA Einführung. Abgerufen am 16. Dezember 2022.
  5. ↑ More successful deployments of Capella. Abgerufen am 15. Dezember 2022.
  6. ↑ Case study experiences with the deployment of Capella. Abgerufen am 17. November 2021.
  7. ↑ Capella Case Studies. Abgerufen am 13. Oktober 2020.
  8. ↑ Deployment of Capella. Abgerufen am 17. September 2019.
  9. ↑ Status of Capella. Abgerufen am 17. März 2018.
  10. ↑ Relevance of Capella. Abgerufen am 21. Juni 2017.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Arcadia_(Ingenieurwesen)&oldid=229034832“