Giters

GfSE / SAF-Specification

The Specification for the System Architecture Framework (SAF)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

To Define Viewpoint SPV05a - Physical Interface Definition

parkaneric opened this issue · comments

commented

Please specify the viewpoint Physical Interface Definition (SPV05a)

Assumed priority: highest

Acceptance Criteria:

  • viewpoint page (*.md) is available under /GfSE/SAF-Specification/tree/main/developing-saf/viewpoints
  • page includes at least concern, presentation, concept and profile
  • maturity is in state released
commented

created https://github.com/GfSE/SAF-Specification/blob/main/developing-saf/viewpoints/Physical-Interface-Definition-Viewpoint.md

Concerns und Stakeholder
Are missing, please elaborate concerns with rationale and stakeholders.

Concept
Was already available, reviewed it and put it into viewpoint spec. It is similar to the conceptual interface definitions

Example
Added preliminary Example Diagram with some notes to FFDS Model, we'll strip it down when the viewpoint is stable.

Applicability
Is based on SE HB 5. Contains also reference to method chapter.

commented
  1. Parallel interface concept is good (e.g. for several domain specialists). However, increased traceability effort assumed ...
  2. Is there a need for an additional and separat stereotype to highlight an interface identification ("ARDUINO MEGO R3 Interface Design") as per ISO15288? This would avoid the impression that a nesting is recommended ...
  3. Using proxy ports in the physical domain implies that no real-world interfaces such as sockets, valves or mechanical hooks are not part of any BOM? Is the concept to establish separate physical elements with the interfaces assigned (as recommended by MBSE4U)?
  4. Stakeholder: all domain experts w/ Safety Specialist should be mentioned here (assuming specialists for hydraulics etc are covered by hardware ...).
commented

I believe we have 2) covered.
3): we should use only Proxy Ports, and only Blocks for specification of parts.
If one wants to generate BOM from model, they could dump also the ports and types.

We could support this by linking an engineering discipline to ports, but users could get a similar result by superclassing the interface blocks and dumping that selectively to BOM.

The same pattern can be applie to blocks. By that we could get rid of the hardware/ software block stereotypes and leave this classifcation to framework users.

But we should standardize the stereotype the discipline super blocks get.

commented

imo the vp is good enough.
there is a proposal for more concerns in the dev documentation, we can merge that in later.