Presentation is loading. Please wait.

Presentation is loading. Please wait.

Mark Elpers 23-year career has spanned the engineering disciplines of test, continuation, HW, SW and systems design Mark was graduated from the U Of Mn.

Similar presentations


Presentation on theme: "Mark Elpers 23-year career has spanned the engineering disciplines of test, continuation, HW, SW and systems design Mark was graduated from the U Of Mn."— Presentation transcript:

1 Mark Elpers 23-year career has spanned the engineering disciplines of test, continuation, HW, SW and systems design Mark was graduated from the U Of Mn in 1985 with a BSEE Mark has worked in the telecommunications, semiconductor, defense and medical industries Mark is the current INCOSE North Star chapter treasurer and president elect for 2010 Mark holds 9 US patents Mark is currently working as a Principle Product Engineer in the HW architecture group of the CRDM division of Medtronic mark.elpers@medtronic.com Introduction

2 Interfaces INCOSE North Star Chapter April 16, 2009

3 Definitions Value Good Properties Types Elements Capture Forms Specifying Via Systems Design Methodology Managing Interfaces Questions Agenda

4 Interface Definitions

5 INCOSE: The specifically defined physical or functional juncture between two or more configuration items Buede: Connection for hooking to another system (external) or for hooking one system component to another (internal) The interface of a system contains both a logical and a physical element that are responsible for carrying items (energy or information) from one component or system to another. Webster: The place at which independent and often unrelated systems meet and act on or communicate with each other The means by which interaction or communication is achieved at an interface Definitions

6 Interface Value

7 INCOSE Handbook: Without early definition and strict control of interfaces between system elements, the individual elements, while performing their task, would not operate in the overall system. While some programs recognized this from the outset, others did not. This resulted in chaos during integration tests, as teams worked round the clock to fix the incompatibilities. At times, it was too late, resulting in major program delays or outright cancellations. Value

8 INCOSE Handbook: Value Interfaces let teams work with Controlled Independence Lets project managers squash schedule

9 Value Faster time-to-market: concurrent development smoother integration/test Change is managed easier: does interface need to change or not? more flexible systems due to modularity system can be more scalable Easier to schedule and manage: tasks are more modular modular systems provide risk mitigation

10 Good Interface Properties

11 Documented using layered notation: Defines hierarchy of peers and peer-peer communication Allows easy delegation of interface processing responsibility within systems Separation of Concern allowing interfaces to be extended, changed Thin: Specifies form and sequence of data exchanged, not meaning Isnt prescriptive about behavior of systems sharing interface Doesnt expose internal behavior of systems sharing interface Units of measure and frames of reference are well understood Configuration controlled - initial version and changes are: Proposed Reviewed Negotiated Agreed To …by anyone sharing the interface Good Properties

12 Interface Types, Elements, Capture Forms

13 Types: External, Internal Man-Machine, Machine-Machine Message Passing, Shared Memory, Network Elements: Electrical, Electromagnetic Hydraulic, Pneumatic Optical Mechanical Chemical, Biological Sense-Based (audible, tactile, visual) Physical, Functional Synchronization, Coding, Channel Equalization Flow Control, Arbitration, Error Detection/Correction Capture Forms: N-Squared Charts Interface Control Documents, Standards Protocols & Protocol Architectures Application Programming Interfaces (APIs) Types, Elements, Capture Forms There are MANY different ways to categorize and describe interfaces. Heres just some…

14 Interface Types

15 Types ICD/IPG Programmer Medtronic System External System Interface Internal System Interface External, Internal:

16 Types ICD/IPG Programmer Medtronic System External System Interface Internal System Interface External, Internal: Tx Rx Tx Rx Telemetry Subsystem

17 Types ICD/IPG Programmer Medtronic System Man-Machine Interface Visual, Graphical Tactile Audible Biological, Chemical Machine-Machine Interface Electromagnetic Man-Machine, Machine-Machine:

18 Types Message Passing, Shared Memory, Network: Real World Examples (Buede) Message Passing: Predictable delivery Immediate or delayed reading Large volume possible Shared Memory: One speaker at a time Compact messages All hear what is said No other work occurs Network: Varying length messages Instigated any time Real-time transfer Many forms of this type

19 Interface Elements

20 Electrical, Mechanical: Elements HDMI USB 115 VAC Cable TV

21 Hydraulic, Pneumatic: Elements Schrader Valve Presta Valve Pneumatic Hydraulic

22 Optical, Mechanical: Elements

23 Chemical, Biological: Elements Protein-Protein Biosensors Sign Language

24 Sense-Based: Elements Virtual Reality Fighter Pilot Helmets

25 Physical, Functional Synchronization, Coding, Channel Equalization Flow Control, Arbitration, Error Detection/Correction Well treat these aspects of interfaces shortly…. Elements

26 Interface Capture Forms

27 N-Squared Charts: Good for capturing all the interfaces of a system…either external or internal! Capture Forms

28 Interface Control Documents & Standards: Interface Control Documents: Communicates all inputs to & all outputs from a system for all possible system users Not always a document: Model-based ICDs use UML sequence diagrams to capture interaction Database definitions also serve this purpose Application Programming Interface (API) Standards: Much quicker than writing your own…use them when you can! ISO18000 (RFID) ANSIT1.105 (SONET, old Bellcore GR-253) ITUITU-T G.707, G.781-3 (SDH, European SONET) IEEE802.3 (Ethernet) EIA RS-232 …many, many more Capture Forms

29 Protocols & Protocol Architectures (Stallings): Protocol: A set of rules governing the exchange of data between two entities Architectures: Structured set of modules that implements the protocol Types: OSI (Open Systems Interconnect, ISO) Useful for educational purposes TCP/IP (Transmission Control Protocol/Internet Protocol, DARPA) Commercially Available Interoperable Products Functions: Segmentation & Reassembly, Encapsulation Connection Control & Ordered Delivery Flow & Error Control Addressing & Multiplexing Value: Separation Of Purpose – Layer To Layer Effects Are Minimized Modular Scaleable Flexible Capture Forms

30 Transport Network Source Entity Destination Entity Network Data Link Physical Network Data Link Physical Network Data Link Physical Data Link Network Transport Application Presentation Session Presentation Application Intermediate Node Intermediate Node Source Node Destination Node Capture Forms Network Layer Overhead Data Link Layer Overhead Provides transparent transfer of data between end systems. Provides end-to-end error recovery and flow control. Breaks the data into packets, assigns sequence #s and sends them. Path Of Data Application Data (Payload) Open Systems Interconnection (OSI) 7-Layer Model: Transport Layer Overhead Physical Media Physical Media Physical Media Provides switching and routing (addressing), internetworking, error handling, congestion control and packet sequencing, creating logical paths for transmitting data from node to node. Frames are encoded and decoded into bits and handles errors in the physical layer, flow control and frame synchronization. Adds bits at the beginning and checksum at the end for error detection. Conveys the bit stream through the network at the electrical and mechanical level. It provides hardware means of sending and receiving data on a carrier, including defining cables, cards and physical aspects, amplitudes, frequencies, phases for 0s, 1s, bit rates, clock transmission and recovery

31 Transport Network (think UPS) Source Entity Destination Entity Capture Forms Open Systems Interconnection (OSI) 7-Layer Model:

32 Capture Forms Dont worry about layers 4-7 now… …think of them as your Internet browser application Application Presentation Session Transport Network Data Link Physical Provides transparent transfer of data between end systems and end-to- end error recovery and flow control. Breaks the message into smaller packets, assigns sequence number and sends them. Provides switching and routing (addressing), internetworking, error handling, congestion control and packet sequencing, creating logical paths for transmitting data from node to node. Frames are encoded and decoded into bits and handles errors in the physical layer, flow control and frame synchronization. Adds bits at the beginning and checksum at the end for error detection. Conveys the bit stream through the network at the electrical and mechanical level. It provides hardware means of sending and receiving data on a carrier, including defining cables, cards and physical aspects, amplitudes, frequencies, phases for 0s, 1s, bit rates, clock transmission and recovery

33 Specifying Interfaces In A Systems Design Methodology

34 Remember The Basic System Design Methodology: Requirements Analysis Functional Analysis (creates functional architectures) Architectural Synthesis (creates physical architectures) Mapping Functional To Physical (creates operational architectures) Performance Analysis & Trade Studies Sub-System Interface & Requirements Specifying I/Fs In A Design Methodology

35 Requirements Analysis: R1) The system shall provide F1/F2 conversion of data between any two users. R2) The system shall allow 3 concurrent users. R3) The system shall provide full-duplex point-multipoint transfer between users. R4) The system shall provide 10 Mbits/sec full-duplex data transfer between users. R5) The system shall provide 10 Mbits/sec Ethernet ports to the user. R6) The system shall provide error-free communication between users over air with an error rate of 1ee-6. Specifying I/Fs In A Design Methodology

36 Requirements R1) The system shall provide F1/F2 conversion of data between any two users. R2) The system shall allow 3 concurrent users. R3) The system shall provide full-duplex point-multipoint transfer between users. R4) The system shall provide 10 Mb/s full- duplex data transfer between users. R5) The system shall provide 10 Mb/s Ethernet ports to the users. R6) The system shall provide error free communication between users over shared media with an inherent error rate of 1ee-6. Functional Architecture F1 User 1 User 2 User 3 F2 F1 F2 Shared Media Functions F1 & F2 needed (R1) 3 instances of F1 & F2 needed (R2) Shared media (R6) Functional Analysis (Functional Architecture): application_data()

37 Specifying I/Fs In A Design Methodology LayerProtocolRationale Applicationapplication_data()The control/data flow, functional flow, activity or sequence diagrams would define the message traffic between our F1 and F2 functions. These messages would populate this layer of the interface specification. Presentation Session Transport Network Data Link Physical Internal Interface Specification:

38 Specifying I/Fs In A Design Methodology Requirements R1) The system shall provide F1/F2 conversion of data between any two users. R2) The system shall allow 3 concurrent users. R3) The system shall provide full-duplex point-multipoint transfer between users. R4) The system shall provide 10 Mb/s full- duplex data transfer between users. R5) The system shall provide 10 Mb/s Ethernet ports to the users. R6) The system shall provide error free communication between users over shared media with an inherent error rate of 1ee-6. Functional Architecture F1 User 1 User 2 User 3 F2 F1 F2 F3 Shared Media Functions F1 & F2 needed (R1) 3 instances of F1 & F2 needed (R2) Shared media (R6) Function F3 needed to provide for error recovery (R6) Function F3 needed to provide flow control & congestion avoidance (R2, R3) Functional Analysis (Functional Architecture):

39 Specifying I/Fs In A Design Methodology LayerProtocolRationale Applicationapplication_data()The control/data flow, functional flow, activity or sequence diagrams would define the message traffic between our F1 and F2 functions. These messages would populate this layer of the interface specification. Presentatio n Session TransportFunction F3: Transmission Control Protocol (TCP) Error Recovery (R6) Flow Control (R2) Congestion Avoidance (R3) Network Data Link Physical Internal Interface Specification:

40 Specifying I/Fs In A Design Methodology Requirements R1) The system shall provide F1/F2 conversion of data between any two users. R2) The system shall allow 3 concurrent users. R3) The system shall provide full-duplex point-multipoint transfer between users. R4) The system shall provide 10 Mb/s full- duplex data transfer between users. R5) The system shall provide 10 Mb/s Ethernet ports to the users. R6) The system shall provide error free communication between users over shared media with an inherent error rate of 1ee-6. Functional Architecture F1 User 1 User 2 User 3 F2 F1 F2 F3F4 F3 F4 Shared Media Functions F1 & F2 needed (R1) 3 instances of F1 & F2 needed (R2) Shared media (R6) Function F3 needed to provide for error recovery (R6) Function F3 needed to provide flow control & congestion avoidance (R2, R3) Function F4 needed to provide traffic routing (R2, R3) Functional Analysis (Functional Architecture):

41 Specifying I/Fs In A Design Methodology LayerProtocolRationale Applicationapplication_data()The control/data flow, functional flow, activity or sequence diagrams would define the message traffic between our F1 and F2 functions. These messages would populate this layer of the interface specification. Presentatio n Session TransportFunction F3: Transmission Control Protocol (TCP) Error Recovery (R6) Flow Control (R2) Congestion Avoidance (R3) NetworkFunction F4: Internet Protocol (IP) Routing (R2, R3) Fragmentation Data Link Physical Internal Interface Specification:

42 Specifying I/Fs In A Design Methodology Requirements R1) The system shall provide F1/F2 conversion of data between any two users. R2) The system shall allow 3 concurrent users. R3) The system shall provide full-duplex point-multipoint transfer between users. R4) The system shall provide 10 Mb/s full- duplex data transfer between users. R5) The system shall provide 10 Mb/s Ethernet ports to the users. R6) The system shall provide error free communication between users over shared media with an inherent error rate of 1ee-6. Functional Architecture F1 User 1 User 2 User 3 F2 F1 F2 F3F4F5 F4F3 F4 F5 Shared Media Functions F1 & F2 needed (R1) 3 instances of F1 & F2 needed (R2) Shared media (R6) Function F3 needed to provide for error recovery (R6) Function F3 needed to provide flow control & congestion avoidance (R2, R3) Function F4 needed to provide traffic routing (R2, R3) Function F5 needed to provide point to multipoint connectivity (R2, R3) Functional Analysis (Functional Architecture):

43 Internal Interface Specification: Specifying I/Fs In A Design Methodology LayerProtocolRationale Applicationapplication_data()The control/data flow, functional flow, activity or sequence diagrams would define the message traffic between our F1 and F2 functions. These messages would populate this layer of the interface specification. Presentatio n Session TransportFunction F3: Transmission Control Protocol (TCP) Error Recovery (R6) Flow Control (R2) Congestion Avoidance (R3) NetworkFunction F4: Internet Protocol (IP) Routing (R2, R3) Fragmentation Data LinkFunction F5: Point-To-Multipoint Protocol (PTMP) Point-To-Multipoint Topology (R3) Error Detection (R6) Physical

44 Specifying I/Fs In A Design Methodology Requirements R1) The system shall provide F1/F2 conversion of data between any two users. R2) The system shall allow 3 concurrent users. R3) The system shall provide full-duplex point-multipoint transfer between users. R4) The system shall provide 10 Mb/s full- duplex data transfer between users. R5) The system shall provide 10 Mb/s Ethernet ports to the users. R6) The system shall provide error free communication between users over shared media with an inherent error rate of 1ee-6. Physical Architecture User 1 User 2 User 3 Shared Media 10 Mb/s Ethernet external system interfaces needed (not shown) (R5) 3 physical components P1-3 needed to provide for 3 concurrent users (R2) 802.11 physical layer P4 needed to provide 10 Mb/s throughput (R4) 802.11 physical layer P4 needed to provide air interface (R4) 802.11 physical layer P4 needed to accommodate air error rate 1ee-6 (R6) P1P2 P3 Architectural Synthesis (Physical Architecture): P4

45 Internal Interface Specification: Specifying I/Fs In A Design Methodology LayerProtocolRationale Applicationapplication_data()The control/data flow, functional flow, activity or sequence diagrams would define the message traffic between our F1 and F2 functions. These messages would populate this layer of the interface specification. Presentatio n Session TransportFunction F3: Transmission Control Protocol (TCP) Error Recovery (R6) Flow Control (R2) Congestion Avoidance (R3) NetworkFunction F4: Internet Protocol (IP) Routing (R2, R3) Fragmentation Data LinkFunction F5: Point-To-Multipoint Protocol (PTMP) Point-To-Multipoint Topology (R3) Error Detection (R6) PhysicalPhysical P4: 802.11b 11 Mbit/s Throughput (R4, R5)

46 Functional To Physical Mapping (Operational Architecture): Specifying I/Fs In A Design Methodology Requirements R1) The system shall provide F1/F2 conversion of data between any two users. R2) The system shall allow 3 concurrent users. R3) The system shall provide full-duplex point-multipoint transfer between users. R4) The system shall provide 10 Mb/s full- duplex data transfer between users. R5) The system shall provide 10 Mb/s Ethernet ports to the users. R6) The system shall provide error free communication between users over shared media with an inherent error rate of 1ee-6. F1 User 1 User 2 User 3 F2 F1 F2 F3F4F5 F4F3 F4 F5 Shared Media P1P2 P3 P4

47 Specifying I/Fs In A Design Methodology Performance Analysis & Trade Studies: Performance Analysis: Simulation on operational architecture confirms protocol choices at each layer allow system to meet performance requirements (R4, R5) given: Point-to-multipoint transfer scenarios Handshaking overhead Retransmissions Queuing theory tools like Opnet Modeler are useful here Trade Study: Error recovery and flow control are not yielding satisfactory performance, explore alternatives to TCP at the transport layer Because of layered interface: Solutions for poorly performing layers can be evaluated during simulation and inserted into product without affecting adjacent layers For example: One could substitute RS-232 for 802.11 while waiting for 802.11 transceiver chipset (P4) to arrive from vendor

48 Specifying I/Fs In A Design Methodology Protocol Layer Options:

49 Managing Interfaces

50 Weve seen how to define interfaces during system design… …how about monitoring compliance during: Concept Exploration Program Definition & Risk Reduction Engineering & Manufacturing Development Production, Deployment & Operational Support Managing Interfaces Group Discussion & Personal Experiences:

51 Questions, Comments???

52 Thanks!!!


Download ppt "Mark Elpers 23-year career has spanned the engineering disciplines of test, continuation, HW, SW and systems design Mark was graduated from the U Of Mn."

Similar presentations


Ads by Google