Code Monkey home page Code Monkey logo

Comments (4)

haarer avatar haarer commented on June 26, 2024

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.

from saf-specification.

parkaneric avatar parkaneric commented on June 26, 2024
  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 ...).

from saf-specification.

haarer avatar haarer commented on June 26, 2024

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.

from saf-specification.

haarer avatar haarer commented on June 26, 2024

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

from saf-specification.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.