Date post: | 27-Mar-2015 |
Category: |
Documents |
Upload: | natalie-adkins |
View: | 217 times |
Download: | 0 times |
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 [email protected]
Introduction
Interfaces
INCOSE North Star ChapterApril 16, 2009
• Definitions
• Value
• Good Properties
• Types
• Elements
• Capture Forms
• Specifying Via Systems Design Methodology
• Managing Interfaces
• Questions
Agenda
Interface 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
Definitions
Interface 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.
Value
INCOSE Handbook:
Value
Interfaces let teams work with “Controlled Independence”
Lets project managers “squash” schedule
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
Good Interface 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
Good Properties
Interface Types, Elements, Capture Forms
Types: External, InternalMan-Machine, Machine-Machine
Message Passing, Shared Memory, Network
Elements: Electrical, ElectromagneticHydraulic, PneumaticOpticalMechanicalChemical, BiologicalSense-Based (audible, tactile, visual)Physical, FunctionalSynchronization, Coding, Channel
EqualizationFlow Control, Arbitration, Error
Detection/Correction
Capture Forms: N-Squared ChartsInterface Control Documents,
StandardsProtocols & Protocol ArchitecturesApplication Programming Interfaces
(APIs)
Types, Elements, Capture Forms
There are MANY different ways to categorize and describe interfaces.Here’s just some…
Interface Types
Types
ICD/IPG
Programmer
Medtronic System
External System InterfaceInternal System Interface
External, Internal:
Types
ICD/IPG
Programmer
Medtronic System
External System InterfaceInternal System Interface
External, Internal:
TxRx
TxRx
TelemetrySubsystem
Types
ICD/IPG
Programmer
Medtronic System
Man-Machine Interface• Visual, Graphical• Tactile• Audible• Biological, Chemical
Machine-Machine Interface• Electromagnetic
Man-Machine, Machine-Machine:
Types
Message Passing, Shared Memory, Network:
Real World Examples (Buede)
Message Passing:
Predictable deliveryImmediate or delayed readingLarge volume possible
Shared Memory:
One speaker at a timeCompact messagesAll hear what is saidNo other work occurs
Network:
Varying length messagesInstigated any timeReal-time transferMany forms of this type
Interface Elements
Electrical, Mechanical:
Elements
HDMI
USB
115 VAC
Cable TV
Hydraulic, Pneumatic:
Elements
Schrader Valve
PrestaValve
Pneumatic
Hydraulic
Optical, Mechanical:
Elements
Chemical, Biological:
Elements
Protein-Protein
Biosensors
Sign Language
Sense-Based:
Elements
Virtual Reality
Fighter Pilot Helmets
Physical, Functional
Synchronization, Coding, Channel Equalization
Flow Control, Arbitration, Error Detection/Correction
We’ll treat these aspects of interfaces shortly….
Elements
Interface Capture Forms
N-Squared Charts:
Good for capturing all the interfaces of a system…either external or internal!
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
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, EncapsulationConnection Control & Ordered DeliveryFlow & Error ControlAddressing & Multiplexing
Value: Separation Of Purpose – Layer To Layer Effects Are MinimizedModularScaleableFlexible
Capture Forms
Transport Network
SourceEntity
DestinationEntity
Network
Data Link
Physical
Network
Data Link
Physical
Network
Data Link
Physical Physical
Data Link
Network
Transport Transport
Application
Presentation
Session Session
Presentation
Application
IntermediateNode
IntermediateNode
SourceNode
DestinationNode
Capture Forms
Network Layer OverheadData 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 DataApplication Data (Payload)
Open Systems Interconnection (OSI) 7-Layer Model:
Transport Layer Overhead
PhysicalMedia
PhysicalMedia
PhysicalMedia
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
Transport Network (think UPS)
SourceEntity
DestinationEntity
Capture Forms
Open Systems Interconnection (OSI) 7-Layer Model:
Open Systems Interconnection (OSI) 7-Layer Model:
Capture Forms
Don’t worry about layers 4-7 now…
…think of them as your Internet browser application
ApplicationPresentationSessionTransportNetworkData LinkPhysical
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
Specifying InterfacesIn A
Systems 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
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.
Specifying I/Fs In A Design Methodology
Specifying I/Fs In A Design Methodology
RequirementsR1) 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
F1User 1 User 2
User 3
F2
F2
F1
F1 F2
Shared Media
Shared Media
Functions F1 & F2 needed (R1)3 instances of F1 & F2 needed (R2)Shared media (R6)
Functional Analysis (Functional Architecture):
application_data() application_data()
ap
plic
atio
n_
da
ta()
Specifying I/Fs In A Design Methodology
Layer Protocol
Rationale
Application application_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:
Specifying I/Fs In A Design Methodology
RequirementsR1) 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
F1User 1 User 2
User 3
F2
F2
F1
F1 F2
F3 F3
F3
Shared Media
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):
Specifying I/Fs In A Design Methodology
Layer
Protocol
Rationale
Application
application_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
Function F3:Transmission Control Protocol (TCP)
Error Recovery (R6)Flow Control (R2)Congestion Avoidance (R3)
Network
Data Link
Physical
Internal Interface Specification:
Specifying I/Fs In A Design Methodology
RequirementsR1) 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
F1User 1 User 2
User 3
F2
F2
F1
F1 F2
F3 F4 F4 F3
F3F4
Shared Media
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):
Specifying I/Fs In A Design Methodology
Layer
Protocol
Rationale
Application
application_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
Function F3:Transmission Control Protocol (TCP)
Error Recovery (R6)Flow Control (R2)Congestion Avoidance (R3)
Network Function F4:Internet Protocol (IP)
Routing (R2, R3)Fragmentation
Data Link
Physical
Internal Interface Specification:
Specifying I/Fs In A Design Methodology
RequirementsR1) 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
F1User 1 User 2
User 3
F2
F2
F1
F1 F2
F3 F4 F5 F5 F4 F3
F3F4F5
Shared Media
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):
Internal Interface Specification:
Specifying I/Fs In A Design Methodology
Layer
Protocol
Rationale
Application
application_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
Function F3:Transmission Control Protocol (TCP)
Error Recovery (R6)Flow Control (R2)Congestion Avoidance (R3)
Network Function F4:Internet Protocol (IP)
Routing (R2, R3)Fragmentation
Data Link
Function F5:Point-To-Multipoint Protocol (PTMP)
Point-To-Multipoint Topology (R3)Error Detection (R6)
Physical
Specifying I/Fs In A Design Methodology
RequirementsR1) 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
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)
P1 P2
P3
Architectural Synthesis (Physical Architecture):
P4 P4
P4
Internal Interface Specification:
Specifying I/Fs In A Design Methodology
Layer
Protocol
Rationale
Application
application_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
Function F3:Transmission Control Protocol (TCP)
Error Recovery (R6)Flow Control (R2)Congestion Avoidance (R3)
Network Function F4:Internet Protocol (IP)
Routing (R2, R3)Fragmentation
Data Link
Function F5:Point-To-Multipoint Protocol (PTMP)
Point-To-Multipoint Topology (R3)Error Detection (R6)
Physical Physical P4:802.11b
11 Mbit/s Throughput (R4, R5)
Functional To Physical Mapping (Operational Architecture):
Specifying I/Fs In A Design Methodology
RequirementsR1) 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.
F1User 1 User 2
User 3
F2
F2
F1
F1 F2
F3 F4 F5 F5 F4 F3
F3F4F5
Shared Media
Shared Media
P1 P2
P3
P4 P4
P4
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
Specifying I/Fs In A Design Methodology
Protocol Layer Options:
Managing Interfaces
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
Managing Interfaces
Group Discussion & Personal Experiences:
Questions, Comments???
Thanks!!!