ARCADIA (Architecture Analysis & Design Integrated Approach) ist eine Methode des System Engineerings, mit deren Hilfe bei der Planung komplexer Systeme und Produkte die verschiedenen Teilbereiche der Systemarchitektur definiert und in Modellen beschrieben werden. Mit ihrer Anwendung sollen die Anforderungen eines Auftraggebers detailliert verstanden werden. Alle Aspekte der Produktentwicklung sollen für die beteiligten Ingenieur-Disziplinen (wie beispielsweise Mechanik, Hydraulik, Elektronik, Elektrik, Software usw.) so beschrieben werden, dass sie durch weiter detaillierende rechnergestützte Entwicklung einer Lösung zugeführt werden können.

Das Ziel dabei ist, dass jeder am Projekt Beteiligte das endgültige Produkt kennt und über die Anforderungen an die anderen Teilbereiche zum frühestmöglichen Zeitpunkt informiert ist. Die Arcadia-Methode bietet einen interdisziplinären Zugang über ingenieurspezifische Limitierungen hinaus und ermöglicht damit eine Arbeitsweise, die alle für die technische Lösung erforderlichen technischen Disziplinen einschließt. Sie stellt sicher, dass allen Beteiligten die Auswirkungen ihrer Tätigkeiten auf andere Disziplinen bewusst sind und entsprechend im Architektur-Modell der Lösung dokumentiert werden. Jede Disziplin erhält auf diesem Weg zeitnah Kenntnis über die sie betreffenden Änderungen, um auf dieser Grundlage optimal weiterarbeiten zu können.

Entstehungsgeschichte

Arcadia ist bei der Thales Group zwischen 2005 und 2010 in einem iterativen Prozess entstanden, an dem operative IT-Spezialisten aus allen Geschäftsbereichen von Thales beteiligt waren. Es wird vom Capella-Software-Werkzeug unterstützt, das ständig weiterentwickelt wird.

Frühere Anwendungen für System-Modelle 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 betonen eher Funktionsanalyse, Systemdesign, Zugrundelegung von Architekturentscheidungen und Verifikationsschritte.

Darüber hinaus berücksichtigt ein solches Designvorgehen nicht nur die funktionale Sichtweise, sondern auch Gesichtspunkte, die die Gestaltung des Systems beeinflussen, wie einschränkende Bedingungen in Bezug auf die Systemintegration, das Produktlinien-Management, die Sicherheit, die Leistung und die Durchführbarkeit. Beim Systems Engineering geht es also nicht nur um die Verwaltung der Systemanforderungen, sondern um eine komplexe und umfassende Entwurfstätigkeit.

Beschreibung

Allgemein

Arcadia wird methodisch in fünf Hauptschritte strukturiert: Die zwei Schritte, die ein erstes frühes Verständnis schaffen sollen, sind die Zweckbeschreibung (Operative Analyse) und die Analyse der Mittel zur Zweckerreichung (Systembedarfsanalyse). Die weiteren Schritte zur Lösung sind die Analyse der funktionalen Eigenschaften (logische Analyse), die Analyse der technologischen Mittel und Fähigkeiten (physikalische Analyse) und die Hierarchische Struktur des Endprodukts (Aufschlüsselungsstruktur).

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

Zusammenhang

Die Arcadia-Methode steht für das Design von komplexen- und kritischen-Systemen und allgemeinen Architekturen zur Verfügung, die mehreren funktionalen und nichtfunktionalen Anforderungen und operativen Einschränkungen unterliegen, darunter der Software, der Mechanik, der Elektronik, den elektrischen Aufgabenstellungen wie Energiezufuhr und Verkabelung sowie industriellen Prozessabläufen in der Fertigung. Es geht meist um komplexe mechatronische Systeme aus Hardware und Software, deren Systemarchitekturen mit modell-basierten Verfahren geplant, konzipiert, gestaltet, gefertigt und in Betrieb genommen werden. Oftmals arbeiten dafür einzelne Fachbereiche noch immer singulär als Insel. Dies führt zu unzureichendem Informationsaustausch mit denen, die von ihren Ergebnissen betroffen sind. Arcadia fasst solche Vorgänge durch Modellverfahren interdisziplinär zusammen und führt Design-Ingenieure durch den Entwicklungs-Prozess bis zur Teilebeschaffung und Fertigung.

Als erste spezifische Branche brachte die Eisenbahnsignaltechnik die Methode zum Einsatz. Es folgten die Luft- und Raumfahrt, die Mikroelektronik, komplexe Bauprojekte, komplexe Medizintechnik (CT, MRT usw.) und zum Beispiel die kritische Energieinfrastruktur. Arcadia definiert dafür eine Reihe von Techniken, die durch die Bedarfsanalyse und das Design führen, um operative Notwendigkeiten zu erfüllen. Gleichzeitig ist die Arcadia-Methode an die Prozesse und Einschränkungen anpassbar, die mit verschiedenen Arten von Lebenszyklen wie Bottom-up-Ansatz, Wiederverwendung von Anwendungen sowie agilen, auf einander aufbauenden, iterativen und partiellen Entwicklungsvorgängen verbunden sind.

Funktionale Zusammenfassung

Mit der Arcadia-Methode werden die Ingenieursaktivitäten in der Breite abgedeckt, wobei mehrere Prozess-Ebenen berücksichtigt werden und Co-Engineering mit Spezial-Ingenieurtätigkeiten integriert wird. Außerdem können gemeinsam Eigenschaften der System-Definition und -Architektur überprüft werden. Arcadia findet in großtechnischen Industrieanwendungen international Verwendung.

Methodischer Ansatz

Bei der Entwicklung komplexer Systeme treten häufig Schwierigkeiten auf, die sich aus der Überlagerung mehrerer teilweise unabhängiger Verbindungen von Funktionen unter Verwendung gemeinsamer Ressourcen ergeben. Um die Überschneidungen von unabhängig voneinander entwickelten Elementen des Funktionsgefüges zu erkennen, wurden 3 zentrale Tätigkeitsbereiche für die Arcadia-Methode definiert und im dazu passenden Werkzeug Capella umgesetzt – Anforderungsanalyse, Bedarfsmodellierung und Architekturdesign

Bei der Anforderungsanalyse werden die unterschiedlichen gewünschten Leistungen und Fähigkeiten der Funktions-Elemente definiert. Neben der Anforderungsanalyse ist eine operative und funktionale/nicht funktionale Bedarfsanalyse einschließlich zugehöriger Modellbildung durchzuführen, die die Erwartungen der Endnutzer, die Nutzungsbedingungen und realistische Integrations-, Verifikations- und Validierungsbedingungen beschreibt.

Anschließend wird untersucht, wie die Verortung der Funktionen und ihrer Fähigkeiten in der Architektur hilft, die unabhängig entwickelten Funktionen miteinander zu verzahnen. Dabei werden die Anforderungen anhand eines Architekturentwurfsmodells (frühe Architektur) auf Robustheit und Machbarkeit überprüft.

Die Strukturierung des Systems/der Hardware/Software und Aufbau einer logischen Architektur geschieht durch iterative Suche nach dem besten Kompromiss zwischen Entwurfsfaktoren, (nicht-funktionalen) Einschränkungen und Gesichtspunkten (auch „Viewpoints“ oder Ansichten genannt), denen das System ausgesetzt sein oder die es erfüllen sollte (befürchtete Ereignisse, Sicherheitsbedrohungen, Erwartungen an das Antwortverhalten (Latenzerwartung), 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 „Sichtweisen“ (auch „Ansichten“ oder „Viewpoints“ genannt) überprüft, ob die vorgeschlagene Architektur in der Lage ist, die erforderlichen Fähigkeiten durch die beschriebenen Funktionen mit dem gewünschten Maß an Leistung, Sicherheit, Zuverlässigkeit, Skalierbarkeit, Umgebungen, Masse und Schnittstellen bereitzustellen. Ferner ist die Gewährleistung der Konsistenz von Engineering-Entscheidungen abzusichern, da alle Interessenvertreter im Ingenieurbereich (Engineering-Stakeholder) die gleichen Engineering-Informationen teilen und ihre eigenen Betrachtungen und Überprüfungen darauf anwenden können, um durch die gemeinsam genutzten Architekturmodelle eine einheitliche und konsistente System-Definition für deren vollständigen Produktlebenszyklus sicherzustellen.

Grobe Vorgehensübersicht

Laut Jean-Luc Voirin sind die verschiedenen Ebenen, die zum kooperativen Ausarbeiten des Architekturmodells verwendet werden, wie folgt aufeinander aufgebaut:

  • 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-/HW-/SW-Anforderungen hinausgehen.
  • System-/HW-/SW-Bedarfsanalyse
Der zweite Schritt fokussiert sich auf die Anforderungen an das System sowie an 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-/HW-/SW-Funktionen, zugehöriger Datenaustausch, nicht funktionale Rahmenbedingungen wie Sicherheit, Antwortverhalten, 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-Funktionen – 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 auch neue Komponenten verwendet werden.
  • Entwicklungsverträge mit Lieferanten – Produktstruktur – IVVQ
Der fünfte und letzte Schritt ist ein Beitrag zum Aufbau der Produktstruktur (End-Produkt „Breakdown“ Struktur / EPBS), der auf der vorherigen Architekturarbeit basiert, um weitere Details der Komponentenanforderungen abzusichern und eine gesicherte Integration, Verifizierung und Validierung plus Qualitätsmanagement (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 nebenstehenden Abbildungen zeigen die ganzheitliche Sicht, die den Arcadia-Prozess zusammenfasst, mit allen Elementen und Aktivitäten des V-Modells während des gesamten Definitions- und Designprozesses. Arcadia deckt dabei den linken Ast des V-Modells vollständig ab.

Die Produktstruktur/EPBS-Ebene bildet den Übergang zum Product Lifecycle Management (PLM) und allen damit verbundenen CAD- und CAE-Methoden (CAx) nebst zugehörigen Werkzeugen. PLM deckt den rechten Ast des V-Modells vollständig ab. Auch etwaige Zuliefertechnologie wird an der Schnittstelle dieser beiden Äste festgelegt. Arcadia bildet deshalb zusammen mit PLM und dem V-Modell die zentrale Grundlage eines digitalen Ökosystems von Herangehensweisen und Verfahren für umfassendes, domänen-übergreifendes und interoperabeles Digital Engineering.

Einsatzbereiche und Projekte

Arcadia wird gemeinsam mit Capella in einer ganzen Reihe von Branchen eingesetzt. Fallbeispiele beschreiben Arcadia/Capella-Projekte bei Thales Australien, Deutsche Bahn – Digitale Schiene Deutschland, UK Atomic Energy Authority, Rolls-Royce, Ariane Group, CNES, Autonomous Train Projekt, Framatome und Continental Automotive. Die European Space Agency (ESA) ist ebenfalls ein Arcadia/Capella Nutzer.

Den Arcadia/Capella-Einsatz nutzen zudem komplexe Bahnprojekte wie im Bereich der Leit- und Sicherungstechnik für Eisenbahnen in Nordeuropa. oder beim Großprojekt SmartRail 4.0 der europäischen Bahngesellschaften in diverser Projektarbeit.

Ein anderer Anwendungsbereich ist das MBSE-Explorations-Großprojekt mit Arcadia und Capella beim weltgrößten Hersteller für Mikroelektrionik-Herstellungsmaschinen ASML.

Darüber hinaus werden Arcadia und Capella bei einer Vielzahl von industriellen Akteuren eingesetzt. Ein Spezialfall ist dabei die Siemens AG, die gemeinsam mit OBEO Arcadia und Capella in das Produktportfolio von Siemens Digital Industries Software integriert hat.

Einmal jährlich wird auf den Capella Days über neue Arcadia/Capella Projekte aus allen Teilen der Welt berichtet. Zusätzlich finden in regelmäßigen Abständen Webinare statt, wo über Spezialthemen vorgetragen wird.

Siehe auch

Einzelnachweise

  1. ↑ Capella – Open Source Software für Modell-basiertes Systems Engineering. Abgerufen am 20. Dezember 2022.
  2. ↑ Stefan N. Grösser , Arcadio Reyes-Lecuona, Göran Granholm: Dynamics of Long-Life Assets: From Technology Adaptation to Upgrading the Business Model. Springer, 2017, ISBN 978-3-319-45438-2, S. 180.
  3. ↑ Einstieg in Arcadia mit Capella. Abgerufen am 20. Dezember 2022.
  4. ↑ 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]).
  5. ↑ 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]).
  6. ↑ Norme PR XP Z67-140 | Norm'Info. In: norminfo.afnor.org. Abgerufen am 1. Februar 2018 (französisch).
  7. ↑ 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.
  8. ↑ Model Based Avionics. ESA, 2022, abgerufen am 21. Dezember 2022 (englisch).
  9. ↑ Jean-Luc Voirin: Model-based System and Architecture Engineering with the Arcadia Method. Elsevier Science 2017, ISBN 978-0-08-101794-4
  10. ↑ 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.
  11. ↑ Iris Graessler, Julian Hentze: The new V-Model of VDI 2206 and its validation. In: at – Automatisierungstechnik. Band 68, Nr. 5, 1. Mai 2020, ISSN 2196-677X, S. 312–324, doi:10.1515/auto-2020-0015 (degruyter.com [abgerufen am 30. Dezember 2022]).
  12. ↑ INCOSE SEBoK – Definition von Digital Engineering. Abgerufen am 20. Dezember 2022.
  13. ↑ US Verteidigungsministerium – Digital Engineering. Abgerufen am 20. Dezember 2022.
  14. ↑ Capella Fallbeispiele (Beschreibungen). Abgerufen am 20. Dezember 2022.
  15. ↑ Capella Fallbeispiele (Videos). Abgerufen am 20. Dezember 2022.
  16. ↑ 1. Fallbeispiel ESA. Abgerufen am 20. Dezember 2022.
  17. ↑ 2. Fallbeispiel ESA. Abgerufen am 20. Dezember 2022.
  18. ↑ Sicherungstechnik bei Eisenbahnen in Nordeuropa. Abgerufen am 20. Dezember 2022.
  19. ↑ Projektarbeit für SmartRail 4.0 der europäischen Bahngesellschaften. Abgerufen am 20. Dezember 2022.
  20. ↑ MBSE-Explorationsprojekt bei ASML. Abgerufen am 20. Dezember 2022.
  21. ↑ Weitere industrielle Capella Nutzer. Abgerufen am 20. Dezember 2022.
  22. ↑ Capella Erweiterungen und Ergänzungen. Abgerufen am 20. Dezember 2022.
  23. ↑ Teamcenter System Modeling Workbench. Abgerufen am 20. Dezember 2022.
  24. ↑ Teamcenter System Modeling Workbench im Siemens Produktportfolio. Abgerufen am 20. Dezember 2022.
  25. ↑ Capella Days. Abgerufen am 20. Dezember 2022.
  26. ↑ Capella Webinare. Abgerufen am 20. Dezember 2022.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.