Hi,
I did a quick draft of mapping proposal between CESAM Architectural visions and Arcadia levels.
My goal is to go further and compare more precisely model elements and diagrams, but I am already interested in any feedbak
Pascal
Hi Pascal,
Seems like we end up with the same mapping
Indeed, there is no direct equivalent to the Arcadia Operational Analysis level in the CESAM architecture framework. The analyses are system-centered from the start, even if some model elements such as Missions (see the CESAM pocket guide) can be mapped to Operational Capabilities or Operational Activities. But the objective the Operational vision in CESAM is more to address the interactions between the system of in interest and its environment, basically an external functional analysis.
The Functional vision aims at elaborating the Functional Breakdown Structure of the system and related descriptive elements such as functional requirements and dynamic scenarios. It naturally maps onto the System Analysis/LogicalArchitecture/Physical Architecture levels of Arcadia since functions in CESAM means in turn system functions, logical functions or physical functions.
The Constructional vision is more straightforward in terms of mapping: Logical & Physical Architectures.
In a next post, I will share the envisioned model for our next systems engineering step
Joel
Thanks Pascal for this work, I mostly agree, except that I share Joël view of no correspondence between Arcadia Operational Analysis and CESAM Operational Vision.
Joël, if you consider going further and elaborating on the subject, I would be interested in the way you would consider addressing (or discarding if not relevant in your context), using CESAM, other pointed possible differences, that I mentioned above:
Quote:
No separation and explicit formalization of Need Vs Solution seem to exist in CESAM : there is only one kind of functions, for example - are they need functions or solution functions? same for states and behavior. In Arcadia, - need is explicitly defined by OA and SA (along with informal requirements) - from which you would produce your specification documents (SSS, IRS, OCD…) - solution is separately defined by LA, PA, BS - from which you would produce your solution design documents (SSDD, ICD, PIDS, sub-systems SSS, SRS…). Consequently, Arcadia defines several so-called functional/non functional analyses (encompassing similar concepts as CESAM states, static elements and dynamic behavior), separately for need and solution, so as to define and differentiate expected behavior (in OA and SA), and designed solution behavior; this way, solution can be challenged against need, and support impact analysis, checking compliance with the need.
Arcadia enforces separation of behavioral structure and hosting resources, so as to support complete interface definition (e.g. differentiating communication contents, communication interactions carrying them, and underlying physical connections being their communication media; same principle applies to components). I did not find this in CESAM, maybe I missed it.
Arcadia defines several abstraction levels and synthesis capabilities (such as LA Vs PA, System Vs sub-systems models articulation, functional automatic synthesis…), especially useful to master complexity, large models engineering, alternatives, different lifecycles etc.
Jean-Luc