1 / 52

Introduction

Introduction. 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

tamber
Download Presentation

Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction 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

  2. Interfaces INCOSE North Star Chapter April 16, 2009

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

  4. Interface Definitions

  5. Definitions 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

  6. Interface Value

  7. Value 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.

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

  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. Good Properties • 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 • Isn’t prescriptive about behavior of systems sharing interface • Doesn’t “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

  12. Interface Types, Elements, Capture Forms

  13. Types, Elements, Capture Forms There are MANY different ways to categorize and describe interfaces. Here’s just some… • 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)

  14. Interface Types

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

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

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

  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. Elements HDMI 115 VAC Cable TV Electrical, Mechanical: USB

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

  22. Elements Optical, Mechanical:

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

  24. Elements Sense-Based: Virtual Reality Fighter Pilot Helmets

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

  26. Interface Capture Forms

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

  28. Capture Forms • 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! • ISO 18000 (RFID) • ANSI T1.105 (SONET, old Bellcore GR-253) • ITU ITU-T G.707, G.781-3 (SDH, European SONET) • IEEE 802.3 (Ethernet) • EIA RS-232 • …many, many more

  29. Capture Forms • 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

  30. Capture Forms Source Entity Destination Entity Path Of Data Application Data (Payload) Application Application Transport Layer Overhead Network Layer Overhead Presentation Presentation Data Link Layer Overhead Session Session Transport Transport Network Network Network Network Data Link Data Link Data Link Data Link Physical Physical Physical Physical Physical Media Physical Media Physical Media Source Node Intermediate Node Destination Node Intermediate Node Transport Network Open Systems Interconnection (OSI) 7-Layer Model: 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. 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. Provides switching and routing (addressing), internetworking, error handling, congestion control and packet sequencing, creating logical paths for transmitting data from node to node. 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. Capture Forms Source Entity Destination Entity Transport Network (think UPS) Open Systems Interconnection (OSI) 7-Layer Model:

  32. Capture Forms Open Systems Interconnection (OSI) 7-Layer Model: Application Presentation Session Transport Network Data Link Physical Don’t worry about layers 4-7 now… …think of them as your Internet browser application 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. Specifying I/Fs In A Design Methodology • 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

  35. Specifying I/Fs In A Design Methodology 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.

  36. Specifying I/Fs In A Design Methodology Functional Analysis (Functional Architecture): F1 F2 Shared Media User 2 User 1 application_data() application_data() F2 F1 Requirements application_data() Functional Architecture 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. Functions F1 & F2 needed (R1) 3 instances of F1 & F2 needed (R2) Shared media (R6) F1 F2 User 3

  37. Specifying I/Fs In A Design Methodology Internal Interface Specification:

  38. Specifying I/Fs In A Design Methodology Functional Analysis (Functional Architecture): F1 F3 F3 F2 Shared Media User 2 User 1 F2 F1 Requirements Functional Architecture 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. 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) F3 F1 F2 User 3

  39. Specifying I/Fs In A Design Methodology Internal Interface Specification:

  40. Specifying I/Fs In A Design Methodology Functional Analysis (Functional Architecture): F1 F3 F4 F4 F3 F2 Shared Media User 2 User 1 F2 F1 Requirements Functional Architecture F4 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. 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) F3 F1 F2 User 3

  41. Specifying I/Fs In A Design Methodology Internal Interface Specification:

  42. Specifying I/Fs In A Design Methodology Functional Analysis (Functional Architecture): F1 F3 F4 F5 F5 F4 F3 F2 Shared Media User 2 User 1 F2 F1 F5 Requirements Functional Architecture F4 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. 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) F3 F1 F2 User 3

  43. Specifying I/Fs In A Design Methodology Internal Interface Specification:

  44. Specifying I/Fs In A Design Methodology Architectural Synthesis (Physical Architecture): P1 P2 P4 P4 Shared Media User 2 User 1 P4 P3 Requirements Physical Architecture 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. 10 Mb/s Ethernetexternal 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) User 3

  45. Specifying I/Fs In A Design Methodology Internal Interface Specification:

  46. Specifying I/Fs In A Design Methodology Functional To Physical Mapping (Operational Architecture): P1 P2 F1 F3 F4 F5 P4 P4 F5 F4 F3 F2 Shared Media User 2 User 1 F2 F1 P4 F5 P3 Requirements F4 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. F3 F1 F2 User 3

  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. Managing Interfaces Group Discussion & Personal Experiences: • We’ve 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

More Related