Dear all,
The logical architecture is a concept which I have met a couple of times in the engineering community and has remained unclear to me all through the years. If I interpret correctly, it is mostly useful for the design of software intensive systems. The complexity of a nuclear power plant comes from (1) the various situations which it is designed to withstand and (2) the tight coupling between its parts (from the reactor core to the electric grid). This is due mainly to physics, not the software. Considered as a whole, a nuclear power plant is not a software intensive system (although this can be debated in the detail since some components are software intensive, but as a whole keep mind that a NPP is a powerful boiler, not a software intensive system). As a consequence, we do not need the logical architecture stage (Ockham’s razor principle: unnecessary notions should be avoided).
However, we do need to recursively split the plant into elements which each can be specified clearly. This can be done by collecting requirements at NPP level, performing an external functional analysis (black box), then an internal functional analysis (white box) pursuing this functional breakdown to a level of detail such that the NPP system can be broken down into its system elements and the elementary functions can be allocated to system elements. Then we can repeat this process, starting from each of the system elements (subsystems). Many system elements are known in advance because our designs are conservative: nuclear island, turbine island, electrical power supply…
All this is quite classical SE.
In terms of data model our requirement is definitely basic. All we need is the following (removing all that is linked to requirements as I understand requirements are outside the scope of Arkadia/ Capella):
-Objects: Functions, System elements
-Tree structures: Breakdown of functions into more detailed functions (FBS), Breakdown of systems into smaller system elements (SBS or PBS, whichever you choose to call it)
-Links: Allocation of functions to system elements, Flows between functions (functional interfaces), Flows between system elements (physical interfaces). It must be possible to draw such flow diagrams at any level of the FBS and PBS, and these diagrams should remain consistent with each other.
Any other representation would be nice to have but not essential (e.g. activity diagrams, sequence diagrams, …).
If we are obliged to strictly follow the Arkadia 4-stage process, this could be a problem. It is difficult enough to make people comfortable with functional architecture and physical architecture for a start. I am not eager to urge people to use notions which I do not feel comfortable with, or understand the necessity of, myself. What is more I think this is bound to be rejected by our engineering population.
As Jean-Pierre wrote, keep it simple. I hope this is posible.