mark elpers 23-year career has spanned the engineering disciplines of test, continuation, hw, sw and...

Post on 27-Mar-2015

217 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

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

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!!!

top related