1. Interface Concepts Modeling Core Team Marc Sarrel Steve Hetfield June 23, 2016

2. Objectives Establish a set of requirements for a comprehensive concept model of interface as defined in the SEBoK: 1.A shared boundary between two functional units, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics. (ISO/IEC 1993) 2.A hardware or software component that connects two or more other components for the purpose of passing information from one to the other. (ISO/IEC 1993) 3.To connect two or more components for the purpose of passing information from one to the other. (ISO/IEC/IEEE 2009) 2016-06-23Interface Concepts2

3. Starting Point 2016-06-23Interface Concepts3

4. Limitations Lack of clear distinction between interface specification and interface realization. requirement vs. implementation distinction The inability to easily show different abstraction levels and views of the interface. Don’t want to carry redundant information in model. one-wire diagram from pin-to-pin information. “Level” (inferable) Inability to specify how an interface is decomposed in to layers that work together to meet the specification. logical vs. physical distinction, or protocol stack. “Layer” (not inferable) The ability to capture mechanical/geometric interconnections using an IBD is difficult and the result is not very intuitive. Limited ability to specify and enforce compatibility constraints between interface-ends. Internal Connectors – There is a need to be able to show a connector that connects two external ports of a component within the component. 2016-06-23Interface Concepts4

5. Specification vsRealization 2016-06-23Interface Concepts5

6. Specification vsRealization 2016-06-23Interface Concepts6

7. Levels of Abstraction 2016-06-23Interface Concepts7 Possible to automatically create higher levels based on lower levels. High Level Low Level

8. Discussion - Levels of Abstraction Two ways to approach model inference for levels of abstraction. Infer and create elements in the model Use Viewpoints to generate views, not in the model First approach would require mechanism to clearly distinguish between user-asserted elements, and inferred elements. Like OWL. Rule based. SysML standard inference rules. User-definable rules. Inferred elements read only. Allows users to make assertions related to inferred elements. Regular re-validation to identify inferred elements that are no longer valid. Manage case where user starts at high level, and then works down. Don’t create inferred element if user has already asserted the result. 2016-06-23Interface Concepts8

9. Layers of an Interface 2016-06-23Interface Concepts9 User must create all layers. No automatic creation possible.

10. Discussion - Layers Unlike levels, there is no inference possible between layers. Just because the lower level is Ethernet, doesn’t imply higher level is TCP/IP, and vice versa. Allows intermediate systems to exist at lower layers, but not upper. Hope to extend to kinds of interfaces other than software Mechanical, thermal, etc. 2016-06-23Interface Concepts10

11. Discussion - Other Re-use of blocks would be improved if there were a robust system of context-specific values for context blocks. Could re-use block for a router, and specify different values for the IP address value property. Serial number is another example application. Neither stereotype tagged values nor default values of properties work for this. Block specific type approach addresses problem, but doesn’t work well for re-use. CSVs could then appear on IBDs, PARs, etc. Base on UML instances – good tool support needed. Another idea would be better instance management tooling and instance diagrams equivalent to IBDs. Instances constrained to BDD/IBDs and validated regularly. Allows multiple designs that conform to BDD/IBDs. 2016-06-23Interface Concepts11

12. Driving Requirements 2016-06-23Interface Concepts12

13. Derived Requirements 2016-06-23Interface Concepts13

14. References 2016-06-23Interface Concepts14