Eclipse Community Forums: Arcadia » Why are functions not common across the ARCADIA levels?

Home » Polarsys » Arcadia » Why are functions not common across the ARCADIA levels?(Why are functions not common across the ARCADIA levels?)

Why are functions not common across the ARCADIA levels? [message #1820841]

Thu, 30 January 2020 04:07

Eclipse User

Can anyone please explain the rationale in the design of the ARCADIA method for having unique sets of functions at the different levels, rather than functions (and their decomposition) being common across all levels?

I understand that the allocation of functions will be different at each of the levels. With high level functions allocated at the System Analysis level and low level leaf functions are allocated to individual components at the Physical Architecture level.

However, it makes sense to me that it would be better if functions and their decomposition into leaf functions could be done in a centralised place that is common to all ARCADIA levels. Then the appropriate level function could be allocated in the appropriate place.

At the moment, with each transition between ARCADIA levels, we end up with lots of copies of functions (and realisation links to the level above), which feels messy. It means there is no single place where you can get the top to bottom view of the decomposition.

Was this design choice deliberate and for a particular reason?

Thanks!

Re: Why are functions not common across the ARCADIA levels? [message #1820972 is a reply to message #1820841]

Mon, 03 February 2020 12:20

Eclipse User

Hello,

Each one of the Arcadia perspectives has its own objective and is a particular way to analyze the system of interest and its life-cycle context. On each of these you can perform a functional analysis, which may be materialized by the breakdown of functions (or operational activities).

But each one of these functional analysis has a different justification and meaning, e.g. the breakdown of System Functions in Systems Analysis perspective will be driven by the refinement of what the system is intended to do, while the breakdown of Physical Functions in Physical Architecture perspective may be driven by the use of a given technology.

If there was a unique functional breakdown across perspectives, it would be quite confusing to identify the rationale behind the breakdown of functions at each node of the tree structure. By having a dedicated functional breakdown, each perspective provides a complete view of a given engineering objective (e.g. elicitate the needs of the system in System Analysis).

Hope it helps.

Re: Why are functions not common across the ARCADIA levels? [message #1823884 is a reply to message #1820972]

Fri, 03 April 2020 09:04

Eclipse User

Yes, to add a little explanation:
- Functions at SA level are "need" functions, understood by customers and users
- Functions at LA and PA levels are "solution" functions, created by technical people to answer the need
They may be very different, and we need the Realization links to describe traceability between both!

Re: Why are functions not common across the ARCADIA levels? [message #1829222 is a reply to message #1823884]

Mon, 29 June 2020 03:05

Eclipse User

I think that the question is about the "proximity" we want to have between the three functional analysis SA, LA and PA. And remenber that we shall keep the consistency between the layers (realization links)!
I don't want to perform independent functional analysis SA, LA an PA and after to manage "manually" realization links", it will be not maintainable ... furthermore complete independant functional analysis inside each layer lead to difficulties of understanding the links between layers (different names for instance without justification)...

I want to keep a complete view of my refining work from SA to PA (agree with James, it seems very useful for me)

My proposition today is to :
- transit always the full functional tree between two layers without modifying the names;
- refine always "inside the box" with a dedicated data flow diagram that explains the refinement
- keep the consistency with capella transition mechanism and native validation rules

advantages:
- auto-maintain of the realization links
- very easy to understand the refinement from one layer to another
- view of complete functional analysis in PA layer

Re: Why are functions not common across the ARCADIA levels? [message #1829739 is a reply to message #1829222]

Thu, 09 July 2020 16:53

Eclipse User

emmanuel hiron wrote on Mon, 29 June 2020 07:05

...
- refine always "inside the box" with a dedicated data flow diagram that explains the refinement ...

This is good also for turning explicit functions that are derived:

The so called "derived functions" (which are proxy for 'derived requirements') are not traceable to higher level functions because they appear (by definition) because of some design decision or constraint at that level.

For example: enabling functions such as "generate electricity" on an aircraft are not expected to be on the SA level since they are not the Value-related when considering the system as a whole. This would appear maybe on PA or on a sub-model.

If you follow the rule of always tracing refining functions "inside the box" of functions transitioned from upper perspectives, all functions that are not inside these will be easily recognizable as derived.

Previous Topic:	Mission, Capabilities and Functions
Next Topic:	Depiction of continuous flows

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Nov 08 04:26:42 EST 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter