To Complete Viewpoint SPV01b - Physical Context Exchange about saf-specification HOT 18 CLOSED

I still think the example is reveals too much internals and therefore prevents focus on the "context exchange" with is the core of the adressed concerns for this viewpoint. I totally agree to the description and definition of the viewpoint, but the example IMHO misses to capture to idea of the viewpoint. But maybe I miss something. Can't we hide the internal and just show the SoI in different physical contexts?

from saf-specification.

Wenn wir nur proyx-ports in den zweiten Systemebene exemplarisch anwenden, erwecken wir das Gefühl, dass SAF solche Vorgehensweise impliziert. Ich würde proxy-ports auch auf der ersten Systemebene im Beispiel modellieren.

from saf-specification.

"A Context Interface Table...": Ich würde nicht Interface Tabellen Fall zu Fall in den Viewpoints beschreiben, sondern zu einer allgemeinen ICD mich beziehen, die im Kontext der... (in diesem Fall "Physischer Kontext") zu bauen ist. Damit vereinfachen wir unsere Arbeit.

from saf-specification.

Purpose and Applicability

Why opening a second level of decomposition in this Viewpoint? and not three? or none? To me it implies that either there are only two levels of decomposition in SAF, or that the SOI is only contextualizing the underlying level. What do we expect for even lower levels? A nested contextualization? I'd avoid this discussion completely and only display one level of decomposition: either SOI only or the underlying level.
We seem to imply that this Viewpoint is also including the "Physical Internal Exchange Viewpoint"
We are mixing definition of interaction points within and over the system boundaries in this Viewpoint. I'd rather not do that. For a small system it may be ok, but as systems become larger, the Viewpoint will become messy.
We should not mix different decomposition levels in one single ICD either. I'd rather keep one ICD per decomposition level.
The Physical Internal Exchange Viewpoint supports the "indentifies the system context and system interfaces" activity included in the INCOSE SYSTEMS ENGINEERING HANDBOOK 2015 [§ 4.1.1.4] (The physical interfaces of interoperating systems are usually known in the Business or Mission analysis)
The Physical Internal Exchange Viewpoint supports the "Identify constraints on the solution (imposed by agreements on interfaces with legacy or interoperating systems)" activity included in the INCOSE SYSTEMS ENGINEERING HANDBOOK 2015 [§ 4.2.1.4]
The Physical Internal Exchange Viewpoint supports the "Specify system requirements, consistent with stakeholder requirements, functional boundaries" activity included in the INCOSE SYSTEMS ENGINEERING HANDBOOK 2015 [§ 4.3.1.4]

Concern

"How does the system or a system element interact with the test environment?"
"How to connect the system or a system element to a test equipment?"
Same coments regarding HW/SW Interfaces and partners as in "Physiscal Internal Exchange Viewpoint"

from saf-specification.

First of all I think we should place a "pure" physical context diagram here (one system/product with external interfaces. In this specific case the focus gets placed on the decomposition, which is clearly on the SPV02 viewpoints. (I know the world is not black and white, but we are mixing views here).

from saf-specification.

I am not really getting warm with the "logical" interfaces on the physical layer. Physical is really tangible for me (in opposition to logical views), i.e. I get what I see - and these are physical connectors in the first place. That is what I would focus on in the first place. That we then allow place certain logical structuring in form of nested ports is fine for me.

Removing the connector and placing the power, TCP/IP,... interfaces directly on the phycical component is a tad too logical for me (yes, those TCP/IP are implementations, I know). I understand the approach and in the beginning it might be quite acceptable, while connectors are not yet known or defined. But only as an intermediate state.

from saf-specification.

CONCERNS:

1. How does the system or a system element interact with the test environment? --> delete "test", or we need to name all
2. How to connect the system or a system element to a test equipment? --> delete "test", or we need to name all
3. What are the Interface Requirements regarding bandwidth, data throughput and latency? --> visiblke here? Or better to say what are the requirements regarding a specific physical interface?
4. What are the external physical entities the system interacts with in the respective context? --> better! covers 1) as well
5. What are the protocols for exchanging items on an interface? --> merge with 3 in abstract manner.

• Which HW interfaces are necessary?
• Which SW interfaces are necessary?
• Which interface partners does a HW item have?
• Which interface partners does a SW item have?
  The 4 above are tricky. SW/HW items may be understood as elements of the HW/SW architecture, we would not make visible here (I hope).

from saf-specification.

from saf-specification.

Am 2. Oktober 2023 11:03:41 MESZ schrieb Sascha Ackva @.>:
I am not really getting warm with the "logical" interfaces on the physical layer. Physical is really tangible for me (in opposition to logical views), i.e. I get what I see - and these are physical connectors in the first place. That is what I would focus on in the first place. That we then allow place certain logical structuring in form of nested ports is fine for me. Removing the connector and placing the power, TCP/IP,... interfaces directly on the phycical component is a tad too logical for me (yes, those TCP/IP are implementations, I know). I understand the approach and in the beginning it might be quite acceptable, while connectors are not yet known or defined. But only as an intermediate state. -- Reply to this email directly or view it on GitHub: #16 (comment) You are receiving this because you were assigned. Message ID: @.>
The physical architecture is not only for 'tangible' things, as connectors (And has never been) Connectors with their Pins(e.g. subd 9pin), electrical Signals definitions (e.g rxd/txd ) as well as Messages with their Attributes (e.g an nmea gps Position String) are Not of conceptual Nature, but Part of the Interface Design. The same applies to other layered protocols in the Interface Design. The conceptual Aspect of abovementioned example would be reduced to the fact that a Position information is passed, with certain quality characteristics. This approach allows analysis and comparision of solution architectures, a well known practise in SE. Mixing solution into the conceptual layer breaks this. However It is practical to Split e.g. mechanical, electrical and message aspects in several ibds or use color coding to distinguish those disciplines / layers in physical Diagramms.
…
-- Gruß, Alexander

Hello Alex,
be sure, I am not reducing physical interfaces to connector types and positions...
As discussed on Friday, it is not practical to model ISO layers as nested ports over multiple layers. The same way I am concerned of the other extreme, if we are now allowing to place ports side by side as we wish for whatever (electrical, mechanical, protocol,....) concern and the only thing that shows that we actually talk about the same is a weak dependency.
Your suggestion of splitting into multiple IBDs basically implies multiple (sub) ViewPoints and dedicated port and connector types (so color coding could be used as a representation).
Don't get me wrong. All the ports/concerns that you plasced in the example are fine for me. I just wondered if it would not be practical to give the VP a bit more structure, by adding a physical connector first and to enhance this connector with the proxy ports that you have in mind, covering the differnt concerns.
Cheers, Sascha

from saf-specification.

from saf-specification.

1. As already discussed please rework the example.
2. The ProtocolLayerRelationship is used to establish a traceability between different aspects of the same interface. The Interface Definition VP however propagates association blocks. What is the common concept?

from saf-specification.

I still think the example is reveals too much internals and therefore prevents focus on the "context exchange" with is the core of the adressed concerns for this viewpoint. I totally agree to the description and definition of the viewpoint, but the example IMHO misses to capture to idea of the viewpoint. But maybe I miss something. Can't we hide the internal and just show the SoI in different physical contexts?

I agree. We should honour recursivity and thus stay on one level. Otherwise Viewpoints become too large and difficult to fathom.

from saf-specification.

I've updated the concerns, descriptions, example and have set the vp to released, since i believe we have the basics covered.

Especially, the concerns were reworked to have them more abstract. Some of the details went into the rationales which connect stakeholders to concerns.

from saf-specification.

Bad timing for me I just want to raise that I am not fully happy with the naming of the Stereotype ProtocolLayerRelationship, because we do not only model relationships between software protocol layers, but instead more general relationships between interface aspects like pin <-> wire, pin <-> signal, valve <-> fluid etc. Can we find a more generic name for it?

from saf-specification.

from saf-specification.

If we want to express layering concept then we can just remove the "Protocol" and name it InterfaceLayerRelationship. I would prefer allow any relationship between interface specification aspects and hence would like to propose InterfaceAspectRelationship.

Gruß,
Jan

from saf-specification.

We can call it SAF_InterfaceLayerRelationship.

from saf-specification.

I agree.

from saf-specification.