Architecture frameworks provide an approach to describing systems and the presentation of these elements and relationships to deliver the stakeholder needs. Essentially, frameworks provide templates for our engineering artefacts. The design of a framework must accommodate a level of freedom in its usage; specific enough to answer the majority of stakeholder concerns whilst generic enough to allow for differences between projects. This balancing act often results in framework design being more generic to allow for a wider audience. Having an untailored framework, which is more ‘open’, can lead to creating inconsistent viewpoints. Arcadia is one such framework as implemented through the Capella tool. The framework provides 4 perspectives/levels for product definition: - The Operational Analysis, where the user needs are considered. Note: no concept of the System at this level. - The System Analysis, where we define the contribution and scope of the System as a ‘black box’, identifying external interfaces, and top-level system functions. - The Logical Architecture, where we break the System down into logical ‘blocks’ and decompose the functionality. - The Physical Architecture, in which we define a (candidate) physical architecture, further decompose the functions, and deploy this functionality to the physical sub-systems, hardware, software and/or firmware. In this talk, we acknowledge the strengths of the Arcadia framework, and the benefits it brings, whilst considering the need to tailor the generic viewpoints. We will provide examples of how we have adopted the generic Arcadia framework and further specified some of the viewpoints to meet the needs of our stakeholders. We will discuss future work looking at how we can translate these specialisations across other areas of the model. Finally, we will provide some suggestions and advice on tailoring views to meet your own needs and ensuring stakeholder engagement with the model.

1. www.thalesgroup.com
OPEN
Tailoring Arcadia
Making the views work for you,
an approach from ISR UK
By Andrew Pemberton & Alex Laing

2. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
2 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Outline of the talk
▌Acknowledging Arcadia
▌Why Tailor?
▌Culture Shift in Thales
▌Where the model fits in the design
▌Approach at SA level
▌Approach at PA level
▌Modeling Pitfalls
▌Summary
▌Questions

3. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
3 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Acknowledging Arcadia
▌We are using the Arcadia framework as a
starting point, providing us with the model
elements and views to capture our design;
i.e. the ‘What’
▌Arcadia does not prescribe the ‘How’. Hence
the need to further tailor to meet the specific
needs of a project.
▌Arcadia is a heavyweight approach to
architectural design if followed fully.

4. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
4 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Why Tailor?
1. Stakeholder Engagement
Collaborate with stakeholders to understand their need
Iterative approach to design; model  present  review  update  repeat
Deliver the views that are necessary for the stakeholders
Ease of navigation within Capella
2. Only model what is needed
Evolution of existing Product/Design (i.e. not ‘green field’ project)
3. Support publication of documents using information within Capella
Understand which model elements need to be presented, and in what format

5. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
5 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
MBSE Supports Culture Shift in Thales
Culture Shift in Thales
(www link)

6. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
6 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Solution level Model
Logical Architecture
(LA)
System
Analysis (SA)
Physical
Architecture (PA)
Where the Capella model fits in the Solution level design
System Level
Requirements
Subsystem Level
Requirements
Subsystem Level
Requirements
Subsystem Level
Requirements
Reqtify Links
DOORS Links
satisfies
System Analysis level of
Capella model based on
previous Product and
updated.
No Logical Architecture.
System ‘child’ Functions
transitioned – unmodified.
Complete Physical
Architecture including further
Functional Decomposition
and Behavioural Analysis.
SA level model artefacts (e.g.
Functions) linked back to
System Level Requirements
generates
Includes detailed design
Includes detailed design
information from current
‘manually created’ SSDD
and other sources.
Other Design Artefacts
Design information
assembled to
produce SSDD.
Subsystem
Requirements
Linked to Design.
Budget
Spread-
sheets
System
ICD (pin
level)
Detailed
Design
Fragments
Design
Document
(SSDD)
Assemble
Design
Document

7. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
7 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Keep a ‘tidy’ & structured Project Explorer
▌‘Package’ structures used in Project Explorer
structure
Model elements grouped using ‘Package’ structures.
▌Partly driven by the design document perspective
Missions exploit ‘N’ Capabilities.
Capabilities are realised by a number of ordered
Functions.
Functions grouped by Actor/Component.

8. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
8 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
SA Level Tailoring – Use Contextual views rather than ‘Blanks’
▌Contextual Capability/Mission views
used instead of MB/MCBs
Supports navigability within model;
- Contextual diagrams collocated with
applicable model element.
- Allows contextual navigation to views
‘owned’ by the model element.
Note: ‘Full’ MB/MCB views only used by modellers (for the ‘big
picture’ views; i.e. working / unpublished views) to support
validation of the design.

9. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
9 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
SA Level Tailoring – Functional Views are Capability focussed
▌The functionality provided by each
Capability is represented using one or more
SAB views; this allows management of the
complexity for each Capability.
▌SABs used in preference to SDFBs for the
following reasons:
Functional allocation to ‘Structure’ elements is
visible.
Allocation of Functional Exchanges to
Component Exchanges is also visible.
BUT…
- (to support document generation) the SAB name
needs to be considered.

10. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
10 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
SA Level Tailoring – Exchange Scenarios used only if needed
▌Each Exchange Scenario represents a single
Functional Chain.

11. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
11 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Maintain Functional ‘Big Picture’ View
▌At the SA level we maintain a ‘big picture’ view of
the complete System Functions.
NO Functions or Functional Exchanges are hidden on
the view.
This supports a visual identification of unused Functions
/ Functional Exchanges.
Provides users with the ability to visualise where
Functions fit in to the overall System.
‘Parent’ System Functions shown in darker green.
▌Number of Functions are appropriate at SA level;
i.e. not too many.

12. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
12 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Enhancing view understanding by Colour / Annotation
▌System Context view created using SAB,
with ‘coloured’ Component Exchanges
(and no Functions).
▌‘Title Blocks’ utilised where appropriate to
provide additional context / clarification
for views by showing related model
elements.

13. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
13 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Example Document Publication
▌Documentation added in model to ‘key’ model elements AND views.
Mission
description
Contextual
Mission
View
Contextual
Mission
View
description
Capability
description
Contextual
Capability
View
Capability
based SAB
View
Functional Chain
description
Functional
Chain
description

14. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
14 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Focussed PAB views
▌Pretty much anything from a Physical Architecture
perspective can be put on a PAB view. While this is
useful, a customised set of PAB views (each with
their own purpose) has been defined and captured
on a Wiki page to make it easier for users to
interpret what they are presented with; e.g.
Views capturing specific Physical Architecture design
aspects of the system.
Views showing the physical context of each Physical
Component.
Views showing specific behavioural aspects of the
system.
Views showing the functional context relating to a
Physical Component.

15. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
15 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Physical Architectural design aspects
▌Views of ‘key’ aspects of the physical
architecture captured using PABs; e.g.
power / network / clock
architectures, etc
Physical Paths show how specific types
of data are routed between the Physical
Components.
Physical Port names (representing
physical connector designations) are
also visible.
The names of the model elements are
made to be identical to those managed
in the System ICD spreadsheet to support
auto-generation of ICDs using model +
detailed interface information.
Clock Architecture
routing (part)
Power Architecture
routing (part)

16. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
16 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Component Context Views
▌Multiple (2) views of the context for a
Physical Component have been
created to serve different purposes.
More will be created in time when
Physical Function modelling is done.
Simple context view showing Physical
Ports and Component Exchanges only
(e.g. for inclusion in a Requirements
Specification).
Detailed context view showing Physical
Ports / Links and Component Exchanges
+ allocation (e.g. for inclusion in a
Design Document).

17. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
17 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Modelling Pitfalls
▌Modelling at an inappropriate level (i.e. too deep too early, modelling
‘white box’ instead of ‘black box’).
▌Lack of a clearly defined ‘Modelling Plan’; i.e. scoping what to model, how
it should be modelled.
▌Thinking that a modelling approach is the solution for all design.
▌Modelling the bits of the system which are understood, rather than
focussing on less well understood areas.

18. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
18 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Summary
▌Continuous engagement with stakeholders
▌Developing the culture
▌Importance of understanding your Data Model
▌Importance of a ‘style’ guide for the tailored views
used to help with their interpretation

19. This
document
may
not
be
reproduced,
modified,
adapted,
published,
translated,
in
any
way,
in
whole
or
in
part
or
disclosed
to
a
third
party
without
the
prior
written
consent
of
Thales
-
©
Thales
2020
All
rights
reserved.
19 Revision 1, 19 January 2023
Name of the company / template : 87211168-DOC-GRP-EN-005
OPEN
Questions