210609-davies-interface-management.pdf - INCOSE

Welcome!

We’re glad you’re here.

INCOSE Enchantment Chapter Monthly Meeting

We respectfully request:• Mute your audio when you are not speaking • *6 toggle or in GlobalMeet left-side, your name

Discussion and questions are encouraged!

Put questions in the chat box or unmute yourself to speak up.

Meeting Materials

Slide presentations can be downloaded prior to start of the meeting from the Meeting Materials page of our website:

https://www.incose.org/incose-member-resources/chapters-groups/ChapterSites/enchantment/resources/meeting-materials

If recording is authorized by speaker, the video will be posted at the link above within 24 hours.

https://www.incose.org/incose-member-resources/chapters-groups/ChapterSites/enchantment/resources/meeting-materials

SEP Training

CSEP Courses by Certification Training International:CTI currently is offering online course offerings, see https://certificationtraining-int.com/incose-sep-exam-prep-course/

Our chapter has two SEP mentors: Ann Hodges [email protected] Hahn [email protected]

https://certificationtraining-int.com/incose-sep-exam-prep-course/

mailto:[email protected]

mailto:[email protected]

Upcoming meetings• July 14, 2021: Dr. Dave Peercy, Education as a System of Systems• August 11, 2021: Pat Foley, WBS Integration with an Effective

Schedule• September 8, 2021: Brian Kennedy, Leveraging Set-Based Practices to

Enable Efficient Concurrency in Large Systems and Systems-of-Systems Engineering

Introductions

• Please type your name, position, and organization in the Chat window

Photo by Adam Solomon on Unsplash

https://unsplash.com/@solomac?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText

https://unsplash.com/s/photos/introduction?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText

Survey

The link for the online survey for this meeting is• www.surveymonkey.com/r/2021_06_MeetingEval

Your feedback is important!

Enchantment Chapter Monthly Meeting

Interface Management, The Neglected Orphan of Systems Engineering

Abstract: Every Interface is an opportunity to lose information, time, control and / or money through contention between stakeholders at either end. There are many issues surrounding Interface management, which are relatively unexplored in the engineering literature. Interface management is perceived as a critical skill in the engineering of successful systems (INCOSE TP-2018-002-01.0), but finding useful material on the subject proves elusive. It is not that there is a gap in the collective Body of Knowledge (BoK) – but there is definitely a gap in the documented BoK. This paper explores some of the characteristics of this gap, and outlines some of the key concepts in best practice. Along the way, the differences between best practice for interfaces and best perceived practice for architecting systems are noted, and recommendations for changes in approach are given.

Download recording from the Library at www.incose.org/enchantment

NOTE: This meeting will be recorded

Speaker Bio

Paul Davies supposedly retired in early 2014, but soon realized he needed to give something back to the systems engineering community and help mentor the next generation of practitioners. An experienced systems engineer with a sound track record in delivering successful projects over thirty years in the defense and aerospace industry, six years in the nuclear industry, and a couple of years in rail, he has a wealth of diverse experience to call on. Paul has conducted training courses and workshops in requirements, interface management, verification and validation, systems engineering management, competence assessment, and SE return on investment, with very positive feedback.

Interface Management –The Neglected Orphan of

Systems Engineering

Paul [email protected]

Copyright © 2019 by Paul Davies. Published and used by INCOSE UK Ltd and INCOSE with permission.

Aims and Outline

• To challenge the perception of an engineer as someone who ignores the world outside their System Element

• To remove the excuse “There’s no training or guidance on interfaces”

• To left-shift the consideration of interfaces in architecting

1. What’s in the literature2. The SEP field3. Elements of best practice4. Left-shifting – an example5. Common problems6. Lifecycle considerations7. Conclusions and questions


What’s in the Literature


The “Somebody Else’s Problem” field


7 Samurai battle the SBS


Why does it matter?System of Interest A System B

IFAB IFAB

ICAB

Mandated InterfaceBearer X

“System A shall interface to System B via bearer X”

System Req’m’t

s

Sub-System

1 Req’m’t

s

Sub-System

2 Req’m’t

s

Sub-System

3 Req’m’t

s

External Interfaces

External Interfaces

External Interfaces

External Interfaces

Interfaces 1 <> 2

Interfaces 2 <> 3

Interfaces 1 <> 3

ChangeControl

Design

Requirements Test


Electrical voltage + current (+ spikes)Vertical forces (time-varying)Longitudinal forces due to frictionHeatFlash arcingElectromagnetic field flux (+RFI)Vibrational forces (resonance?)Shock (at joints)

Moisture & salt depositionCarbon deposits, rust, crud

It’s not just software


Best Practice 1: the Separation Principle

Notional ‘Plane of the interface’

What is passed across the interface,

the formof the interface

AB Interface docSystem A Spec

System A behaviour

What System A has to do in response to the interface

System B Spec

System B behaviour

What System B has to do in response to the interface

System A System B

IFAB IFAB

ICAB


Best Practice 2: the Context Diagram

ATC SystemAir TrafficControl System

ADS-B

Aircraft

Emergency Services

Heat/Dust

Power

Weather

Air Ops Command

EM Signals

2

3

456

7

8

9 1

WAN


Best Practice 3: the Sequence Diagram

SystemExt Sys 3Ext Sys 2Ext Sys 1

Mass, energy or information exchanges across nominal planes of each interface, in logical sequence

time

System BoundaryCopyright © 2019 by Paul Davies. Published and used by INCOSE UK Ltd and INCOSE with permission.

Best Practice 4: layered models as patterns

7. Application

6. Presentation

5. Session

4. Transport

3. Network

2. Data Link

1. Physical

High-level Applications I/F

Character encoding, encryption

Manage connections

Quality of Service, error control

Addressing, routing, traffic control

Flow control protocol

Pins, voltages, impedance, modes

7. Application

6. Presentation

5. Session

4. Transport

3. Network

2. Data Link

1. Physical

High-level Applications I/F

Character encoding, encryption

Manage connections

Quality of Service, error control

Addressing, routing, traffic control

Flow control protocol

Pins, voltages, impedance, modes

Load balancing

Power switching

Safety trips

Wiring/connectors

Power delivery

Load balancing

Power switching

Safety trips

Wiring/connectors

Power usage

ElectricalPower System

Train Electro-Motive System

Overhead Lines

Cabling +Power bus

Pantograph Arm etc

means an Interfaceto be documented


Best practice 5: black box N2 chart

IN

IN

OUT

OUT

A -SystemOf Interest

B requires of AA provides to B

C requires of AA provides to C

D requires of AA provides to D

E requires of AA provides to E

A requires of BB provides to A B - Users C requires of B

B provides to CD requires of BB provides to D

E requires of BB provides to E

A requires of CC provides to A

B requires of CC provides to B

C - PhysicalEnvironment

D requires of CC provides to D

E requires of CC provides to E

A requires of DD provides to A

B requires of DD provides to B

C requires of DD provides to C

D - External System 1

E requires of DD provides to E

A requires of EE provides to A

B requires of EE provides to B

C requires of EE provides to C

D requires of EE provides to D

E ExternalSystem 2

…etcCopyright © 2019 by Paul Davies. Published and used by

INCOSE UK Ltd and INCOSE with permission.

Best practice 6: white box N2 chart

Control Inputs

(e.g.) HCI Outputs

Consider only inputsTo System Elements From the outside world

Consider only outputsFrom System Elements To the outside world

Don’tcare

Don’tcare

ConsiderCell by Cell

ConsiderCell by Cell

Don’tcare

Don’tcare

Don’tcare

Don’tcare

Don’tcare

Don’tcare


Best practice 7: optimised N2 chart


Best practice 8: phased implementation N2

Time

Lega

cy

Syst

em

Depl

oyed

Syst

emM

odes

CS1 CS2 CS3 CS4Intermediate configuration states


Left-shifting…

Requirements Physical DesignLogical / Functional DesignArchitecting

{Interface design at successive levels of analysis}

Requirements Physical DesignLogical / Functional DesignArchitecting

Interface constraints

{Interface analysis feedback loops}

Becomes…


Pantograph example againElectrical voltage + current (+ spikes)Vertical forces (time-varying)Longitudinal forces due to frictionHeatFlash arcingElectromagnetic field flux (+RFI)Vibrational forces (resonance?)Shock (at joints)Moisture & salt depositionCarbon deposits, rust, crud

The flows across the interface drive extra functionaland non-functional requirements on the System Elementsat each endCopyright © 2019 by Paul Davies. Published and used by

INCOSE UK Ltd and INCOSE with permission.

Residual architecting decision patterns for interfaces

Power

Control

Comms BIT

Resiience


Lifecycle of interface-based architectingDraw the context

Identify theexternal I/Fs

Current vsFuture

Agree way forward

Trial decompositioninto subsystems

Evaluate effect oninterface decompositionsOK?

N

Y

GenerateSpecification tree

Get onwith it!

OrganisationsComplexityNumberRisk

Phasedtesting

SubsystemA

B requires of AA provides to B

C requires of AA provides to C

D requires of AA provides to D

X requires of AA provides to X

A requires of BB provides to A

SubsystemB

C requires of BB provides to C

D requires of BB provides to D

X requires of BB provides to X

A requires of CC provides to A

B requires of CC provides to B

SubsystemC

D requires of CC provides to D

X requires of CC provides to X

A requires of DD provides to A

B requires of DD provides to B

C requires of DD provides to C

SubsystemD

X requires of DD provides to X

A requires of XX provides to A

B requires of XX provides to B

C requires of XX provides to C

D requires of XX provides to D

ExternalSystems


The requirement from hell, and future-proofingSystem of Interest A System B

IFAB IFAB

ICAB

Mandated InterfaceBearer X

“System A shall interface to System B via bearer X”

Bearer X in service;System B to be

accepted

System A envisaged

, with interfaces

IDD published

for X;IRS created for A<->B

System B accepted; ITT for System A

uses IRS + IDD

System A procured at lower cost

& risk

Negotiations between suppliers

for A and B brokered -> ICD


Conclusions

• We have looked at gaps in the literature, and started to overcome the lack of a lifecycle-oriented view of interface evolution.

• We have outlined some key principles associated with interfaces, and looked at some best practice methods of representing and elaborating them.

• We have stressed the use of interface analysis in architecting Systems throughout their lifecycle.

• We have encouraged engineers to look outside the box.


-1-Copyright©2019byPaulDavies.PublishedandusedbyINCOSEUKLtdandINCOSEwithpermission.

InterfaceManagement–theNeglectedOrphanofSystemsEngineering

PaulDavies,[email protected]

Categorisation

• Accessibility:PRACTITIONER• Application:GOODPRACTICE• Topics:Architecture,SystemsEngineeringManagement

Abstract

EveryInterfaceisanopportunitytoloseinformation,time,controland/ormoneythroughcontentionbetweenstakeholdersateitherend.TherearemanyissuessurroundingInterfacemanagement,whicharerelativelyunexploredintheengineeringliterature.Interfacemanagementisperceivedasacriticalskillintheengineeringofsuccessfulsystems,butfindingusefulmaterialonthesubjectproveselusive.ItisnotthatthereisagapinthecollectiveBodyofKnowledge(BoK)–butthereisdefinitelyagapinthedocumentedBoK.Thispaperexploressomeofthecharacteristicsofthisgap,andstringstogethersomeofthekeyconceptsinbestpractice.Alongtheway,thedifferencesbetweenbestpracticeforinterfacesandbestperceivedpracticeforarchitectingsystemsarenoted,andrecommendationsforchangesinapproacharegiven.

Introduction

Typically,itisanunpopulartaskonaprojecttobeasked“Justresolvetheinterfaces”;andwhatevereffortisallocated,itgenerallyhappenstoolateandisseentobearootcauseofprojectfailures.Theseareofcoursesweepinggeneralisations,yetthere isagrainoftruthhere;anditbecomesaviciouscircleofblamewaitingforthenextprojecttodothesame.

Aimsofthepaper

• Tochallenge theperceptionofanengineeras someonewhoconcernshimself (orherself)solelywiththerealisationofthefunctionalityoftheirelementofthesystem,totheexclusionofallinteractions.Goodsystemsengineersdon’tdothis.

• To remove the excuse “I’ve never been trained on this, and there is no useful referencematerialonhowtodoit.”

• Tochangethewaywegoaboutarchitectingsystems;left-shiftingthetreatmentofinterfacesratherthanleavingituntilafterthephysicaldesignneedsintegrating.

LiteratureSurvey

We start with a survey of what is documented. Mostly this consists of the usual standards onstructuringinterfacedocumentation,someprocessstandards,plusthereareafewgoodbooksonthearchitectingofsystemswithatleastsomerelevantcontent.


Standards

• One of the first standards on Systems Engineering, [IEEE 1220] starts with a SystemBreakdownStructure(SBS)devoidofinterfacesasearlyaspage3.Admittedlytherearebetterfigures,andprocessrequirementstospecifyinterfacesateachlevelofsystemdecomposition,laterinthestandard,butineachcasethetreatmentofinterfacesisasanadjuncttotheactofspecificationatthatlevel.No“how-to”processdetailisoffered.

• Amoreusefulstandard,[EIA-632]containsagrandtotalof7linesoninterfacedefinition,oneof which is now generally agreed to be bad practice; plus one table on recommendedprocessesforsystemdecompositionwhichisalmostacopyoftheprocessin[IEEE1220].

• Furtherdomain-specificstandards,[DI-IPSC-81434],[DI-IPSC-81436],[FAA-STD-025e],[NASA1997] and [NIST 2002] are significantly better, and for some types of interface (mainlysoftwareandcommunications)givegoodguidanceoninterfacespecificationcontent–butstillhaveshortcomingsinotherengineeringfieldsanddomains.

• TheINCOSESystemsEngineeringHandbook(SEH)[INCOSETP-2003-002-04],inturnbasedonISO15288, is better still, and considers interfaceanalysis aspartof theprocesson systemarchitecturedefinition.ThereisanothershortsectiononInterfaceManagementasacross-cuttingtechnology,butdetailislight.

• TheINCOSESystemsEngineeringBodyofKnowledge(SEBoK)[SEBoK2018]hassomegoodcontent, particularly in the sections on “Synthesizing possible solutions”, “Systemarchitecture”, “Logical and Physical architecture model development”, and “SystemIntegration”.Therearealsoseveral interestingexamplesandcasestudiesofgoodandbadpracticeandoutcomes.Takenasawhole, itavoidsmostof the shortcomings listedunder“Gapanalysis”below,butitlacksanintegratedlifecycle-basedtreatmentofinterfaces.

• TheINCOSECompetencyFrameworks[INCOSETP-2018-002-01.0]andits2010predecessoridentifyInterfaceManagementasanessentialcompetencyinitsownright.Therearesomebriefpointsongoodpractice,andhowtospotit,butnoend-to-endnarrative.

Booksonsystemarchitecting

[Hitchins1992],[Grady1994]and[Sillitto2014]allhavegoodtreatmentsonN2charts(or“CouplingMatrices”asusedbyGradyandbytheSEH),andontheiruseinchangingoroptimisingarchitectures.However,theyarequitehardtofollowinsomecases,andarenotfullyintegratedwithotherinterfaceconceptsdescribedbelow.Allarerecommendedreadinganyway,fortheaspiringsystemarchitect!

Gapanalysis

Insummary,thedocumentedbodyofknowledgeisdeficientinthefollowingareas:

• It’sallaboutthe“what”mustbedone,andinwhatformat,butthereisnotenoughusefulinstructiononthe“how”.

• Itmostlyconcernssoftwareandcommunicationsinterfaces,particularlytheStandards.• Itisfocusedondecompositionofsystemsintosystemelementsinthestrictlyfunctional,then

physicalorder,withinterfacesasadjunctsateachlevel.Verylittleconsiderationisgiventoarchitectingbyminimisationofinterfacecomplexity,ortousinginterfaceanalysisiterativelywithotherarchitectingmethods.


• Interfaceanalysisateachlevelofdecompositionistreatedasasnapshotactivity,withnoend-to-endtimelineofprojectpracticesininterfacemanagement.

The“Somebodyelse’sproblem”field

Douglas Adams, in his novel “Life, the Universe, and Everything” [Adams 1982] described theSomebodyElse’sProblem(SEP)fieldas“somethingwecan'tsee,ordon'tsee,orourbraindoesn'tletussee,becausewethinkthatit'ssomebodyelse'sproblem.Thebrainjusteditsitout,it'slikeablindspot.” InterfacescaneasilybesubjecttotheSEPfield,asengineersarepre-programmedtoworryaboutinternalfunctionalityofasystemorsystemelement.

Consider the Seven Samuraimodel of a system development – see Figure 1, reproduced by kindpermissionof JamesMartin [Martin2004]. It implies the interactionbetween the systemand theproblemspace,andthereareinteractionswithallothersystemsdepicted,overatimeline.Andyet,thetemptationforanengineeristoleapstraighttosolutionspace,andatleastmentallytodrawaSystemBreakdownStructure,seeFigure2,withinafewseconds.

ComparingFigure1withFigure2–where have all the interfacesgone? In the SBS, we cannot seetheblack-boxexternalinterfacesatsystem level, nor the white-boxinterfaces between systemelements. We have successfullycreated the SEP field. And now aWorkBreakdown Structure (WBS)will be created tomatch the SBS,again deferring any considerationofinterfaces.

Does it really matter? Can’t weallocate responsibility for theinterfaces to the engineerresponsible for each systemelement? Here are some reasonswhynot:

• Every interface connects atleast two systems or systemelements.Inthemajorityofcases,there is no single span of controloverbothends–sotheinteractionbetweenthemneedsatleasttwo-partynegotiationandagreement.

Figure1-SevenSamurai

Figure2-SystemBreakdownStructure


• Integrating across interfaces takes longer than integrating the functionality of a systemelement.Sodesigningandtestingtheinterfaceshastohappenearlier.

• Assystemsaredecomposedintosystemelements,thenumberofpotentialinterfacesgrowsmuch faster than thenumberofelements. In theSBSexampleatFigure2, if each systemelementisconnectedtoeveryother,andto2externalsystems,that’spotentially14interfacestomanage.Andtherewillbemanymoreatthenext levelofdecomposition.Thenumbersmaybeanexaggeration,buttheprincipleholdstrue.

• Traceability–interfacerequirementsmayneedtotracetothespecificationsateachend,aswellastotheparentsystem.

Hencetheeffortneededisseentooutstriptheeffortallocatedtoasinglesystemelement,inanon-linearmanner.Systemsengineersneedtofocusattentiononinterfaces,particularlyinearlyplanningandestimatingstagesofprojects,toovercometheSEPfield.

Elementsofbestpractice

Inthissection,thekeyconceptsofinterfacemanagementarebrieflydescribed,andlogicallychainedtogether.Spaceheredoesnotallowthispapertoprovidefullexplanations,andarchitectinginvolvinginterfacesdoestakesignificanttimetomaster.Itishopedthatthesystemsengineerswillmostlybefamiliarwithalltheseconcepts,butrepeateddeliveriesbytheauthorofatutorialonthistopicwouldsuggestthatthismaynotbethecase.Ifthereaderisindeedunfamiliar,tryreading[Davies2019]forhelp.SeeFigure3forthekeyconcepts.

Figure3-UsefulconceptsinInterfaceManagement:Separationprinciple(topleft),Contextdiagram(topright),Sequencediagram(bottomleft),layeredinstantiationofinterfaces(bottomright).

Theseparationprinciplesimplysaysthatinterfacespecificationsshouldnotcontaindescriptionsofinteractionfunctionality.Theyshouldgointhefunctionalspecificationsoftheinteractingentities;theboundsofexchangesequencescouldgoinahigher-order(e.g.containingsystem)specification.


Black-boxandwhite-boxmodelsareessentialitemsinanysystemsengineer’sarmoury.Blackbox-theviewofthesystemfunctionsandinteractionobservableatthesystemboundary,withoutknowinganythingaboutitsinternals.Whitebox–extendingthemodeltoincludethesysteminternalsandalltheirinteractions.

Contextdiagramsareaconvenientrepresentationofablackboxmodel,showingasystemboundaryseparatingwhatisinsidethescopeofthesystemfromwhatisoutside;theexternalsystems,actorsandenvironmentswithwhichitinteracts;andenumeratingthoseinteractions.

Scenarios& sequence diagrams are helpful pictures in eliciting interface requirements, by turningstakeholder descriptions of interaction sequences into pictorial sequences of exchange of mass,energyandinformation.Firstatblackboxlevel,thenextendingtowhitebox.

Layeredmodelsofinterfaces,forexamplethe“OSI7-layer”modelforsystemsinterconnection,isausefulmetaphorfordealingwiththemigrationfromblackboxtowhiteboxlevel.System-to-systeminteraction can be represented as an interface at the “application” layer, which can later beinstantiatedby‘interactions”downwardsintothesystemelementhierarchyandthenbetweenthevariouswhiteboxelements;evenwhentheinteractionisnotjustsoftwareorcommunications.

Thefinalkeyweaponinthesystemsengineer’sarmouryistheN2chart(seeFigure4).Thispaperdoesnotprovidefullexplanations–see[Davies2019],orindeed[SEBoK2018],[Sillitto2014],[INCOSEUKw22012]or[Grady1994]whichallgiveatleastpartialcoverage.

Figure 4 - Uses of N-squared charts in interface management: Black box (top left), white box (top right), optimalarchitecture(bottomleft),phasedtimeline(bottomright).

N2chartsmaybeusedsuccessivelyatblackbox level,whitebox level,and iterativelywithsystemarchitectingtominimisenumberandcomplexityof interfaces intrialdecompositions.Someofthetextsquotedcallthis“reorganisationofcouplingmatrices”,butthosetreatmentsdonotattempttore-definesystemelementstochange theentries in theN2charts.Finally inFigure4,wenotethatthereisnotjustoneN2chartinthelifeofaproject,therearemany:foras-isandto-besystems,phased


integration setups, intermediate delivery configuration states, and configurations to supportdeployment,maintenance,in-servicetest,replacementandupgrade.

Left-shiftinginarchitectingsystems

Theuseofinterfaceanalysisasanup-fronttoolinarchitecting,ratherthanasacapturemechanismfor managing a design that has already been decomposed, is illustrated with several recurrentarchitectingproblemsrequiringthismodifiedapproach.Thusweachievebetterintegrationoflogicalandphysicalarchitecture.

Example-OverheadLineElectrification(OLE)inrail

Considerapantographarmmountedontopofanelectrictrain(Figure5). Itsmechanical interfacewiththeoverheadlineelectrificationcablemaybemovingatmorethan100mph,slidingfromsidetosideofthepantographarm,andelectricalconnectivitymaybeinterruptedforshortperiodsoftime.Andyetwecanstillthinkofitasasingleplaneoftheinterface,acrosswhichanumberofmass,energyandinformationflowstakeplace.

Some of these are interfaceswith other systems or systemelements; some are interfaceswith the environment.However, in each case oursystem (the train) must dosomething in response towhatis happening across theinterface.

If, at the requirements andarchitectingstages,wewere tofocus only on the intendedusageoftheinterface(electricalenergy transfer), we wouldmiss all the (undesirable)

aspectsoftheotherissuesintheinteraction.Bythetimethesewereconsidered,wemightalreadyhavemadedesign choiceswhichmade thehandlingof theundesirable characteristics impossible,over-expensiveorunmaintainable.So,byconsiderationoftheeffectsoftheinterfaceatthephysicalinstantiation, we collect a set of additional system requirements and design drivers, in a timelymanner.Incidentally,inanexerciselefttothereader,thisisalsoanexcellentexampleoftheuseofalayeredmodelofinterfacesinresolvingthetransferofelectricalpowerfromgenerationcapabilitytoelectromotivecapabilityofthetrain.

Commonresidualarchitectingproblemsinvolvinginterfaces

There are some recurring patterns in system design that impact on architecting decisions aboutinterfaces,alladdingtothecaseforincludinginterfaceissuesmuchearlierthanincommonpractice.

Power–Assumingthereisasingleexternalsourceofpowerforthesystem,whetheritbegenerator,mains,oraircrafthigh-voltageDC,howbesttosupplypowertooursystemelements?Shouldeach

Figure5-OverheadLineElectrification


unitdoitsownconversionfromtheexternalsource(somultipleexternalinterfaces),orhaveasinglepower supply unit downconverting to the voltages and currents required by all the other units(multiple internal interfaces)? The formermay be harder to organise, and carries potential safetyissues.Thelatteris“easier”,inthesensethatthemultipleInterfacesareundersinglespanofcontrol,butgivesasinglepointoffailure.

Communications–Likewise,iseachsystemelementgoingtocommunicatewithexternalsystems,orwilltherebeasingle“concentrator”systemelementornodalpoint?Theformerallowsdesignteamsto proceed independently – perhaps faster to implement, but potentially leading to integrationheadaches. The latter allows a global overview of all the external interfaces, but centralises apotentiallyheavyworkload.

Control – For a systemwith diverse functionality in response to either external conditions, or tooperatorinput,controlofthebehaviourofeachsystemelementcanbecentralisedordistributed.Ifdistributed,itcanbedifficulttoguaranteecoherenceoftheintegratedsystem.Ifcentralised,thereisstillachoicebetweenhigh-levelandlow-levelcontrolsignalsormessages.Theformer(“Dothis,youwork out how”) makes for a simpler interface but a more complex design task and integrationsequence.Thelatter(“Doexactlythis,I’veworkedouthow,herearethecontrolsignals”)makesformorecomplexinterfaces,perhapsasimplerintegrationsequence,andahighercentralisedworkload.Thisisamoreacuteproblemifthesystemhasmultiplestatesandmodes.

Built-InTest(BIT)–This isexactlyanalogoustothecontrolproblemabove.“Testyourself, tellmewhetherornotyou’reOK”(simpleinterfaces,distributeddesign,riskyintegration)or“Herearethetestsignals,I’llinterprettheresults”(complexinterfaces,singlecomplexsystemelementdesign)?

Environmentalandmechanicalresilience–Forasystemwithgroupsofco-locatedsystemelementsexposed to a harsh environment, shouldwedesign and test each systemelement to survive thatenvironment?Orshouldwedesignaprotectivecasingthatinsulatesthecontainedsystemelementsfromthatenvironment?Ifthereareexistingdesignsfortheformerarchitecturethatmeet,orcanbemodifiedtomeet,theenvironmentalrequirements,thatisprobablysimplest.However,ifthisisnotthe case, or we wish to reduce costs by using commercial equipment not designed to resist theenvironment,thenthelatterisprobablybest.Beware,however,thatnoprotectivecasingisperfect,particularlyforshockandvibration.Wewillhaveanumberofderivedenvironmentandmechanicalinterfacesforeachcontainedsystemelement,whichmaybedifficulttocalculateandtest.

Theseareallexampleswheretheimpactoftheinterfacesneedstobetreatedasamajordriverinarchitecting,ratherthanasafollow-onactivitytofunctionalandphysicaldecomposition.


Lifecycleconsiderations

Havingacceptedtheprincipleofincludingblack-boxandwhite-boxinterfacesinsystemarchitectingchoices,aflowdiagramfortheprocessissuggestedatFigure6.

Figure6-Lifecycleofinterface-basedarchitecting

Thereisakeyarchitectingloopclearlyshown.Candidatesystemdecompositionsareevaluatedbasedon the organisations involved (and perceptions of their willingness to negotiate and adapt to asatisfactoryinterfaceagreement),andthenumber,complexityandriskoftheinterfacesderived.Thefundamentalchangeinphilosophyfrommosttextsisthatthearchitectingstageisnotconcludeduntiltheinterfacesaredeemedsatisfactory.Noteagainthebottomright-handquadrantofFigure4,anditssupportingdescription:thefinalsystemconfigurationisnottheonlysetofinterfacestobeanalysedandincludedinthearchitectingloop.Integrationandtestsetups,intermediateconfigurationstates,andconsiderationsfromtheDeploymentandSupportConcepts[INCOSETP-2003-002-04]allaffectthearchitectureacceptability.

Lastly,welookatfuture-proofingofinterfacestoandfromsystemsyettobeimplemented,orlegacysystemsnotunderclientcontrol.

Figure7-Atypicalinterfacerequirement

This is a requirement with a huge hidden risk attached, and this author has suffered from it onnumerousoccasions.WhatiftheinterfacetoBearerXisunpublishedorimmutable?WhatifSystemBhasaproprietaryinterface,anditsdesignauthorityrefusestocooperate?IftheacquirerofSystemAhasnoauthorityoverthesuppliersofBearerXorSystemB,thisrequirementisaskingtheSystemAsuppliertosignablankcheque.Thereisarecommendedmethodfordealingwiththissituationgivenin[Davies2019],basedonforeseeingthefuturerequirementandinsistingonatleastdraftInterfaceRequirementSpecificationsatthetimeofentryintooperationsofXandB;oratleastagreedbetweentheacquirerandtheowner-operatorsofXandB.

Theremaybenotrulyoptimalarchitecturetakingalltheforegoingaspectsintoaccount,butusingtheprinciplesoutlined,weshouldatleastimproveoncommonpractice.Nobodysaiditwouldbeeasy.


Conclusions

• Theimportanceoflookingbeyondsystemelementfunctionalitytoincludeinterfaceshasbeenoutlined. Those interfaces need to be resolved: lift up your head, pick up the phone, andresolvethem!

• Youarenowarmedwithsuitablemodelstodealwithdifficultinterfacescenarios,coveringthewholelifecycleofboththesystemanditsinterfaces.

• Argumentshavebeenpresentedforleft-shiftingthetreatmentofinterfacesinarchitecting.

References

[Adams1982] Adams,Douglas,“Life,theuniverse,andeverything”,PanBooks,1982

[Davies2019] Davies P.R., “Don’t Panic! The Absolute Beginner’s Guide to InterfaceManagement”,INCOSEUK,2019

[DI-IPSC-81434] US Department of Defense ‘Data Item Description: Interface RequirementsSpecification’,USDoD,RevisionA,1999

[DI-IPSC-81436] US Department of Defense ‘Data Item Description: Interface DesignDescription’,USDoD,RevisionA,1999

[EIA-632] ‘EIA-632: Processes for Engineering a System’, Electronic Industries Alliance,Philadelphia,PA,USA;2003

[FAA-STD-025e] “Federal Aviation Administration Standard: Preparation of InterfaceDocumentation”,USDepartmentofTransportation,2002

[Grady1994] “SystemsIntegration”,BocaRaton,FL,USA,CRCPressInc.,1994

[Hitchins1992] Hitchins,D.K.‘PuttingSystemstoWork’,JohnWiley&Sons,1992

[IEEE1220] ‘IEEE 1220-2005: Standard for Application andManagement of the SystemsEngineering Process’, Institute of Electrical and Electronic Engineers, 2005(superseded[?]byISO24748)

[INCOSETP-2003-002-04] INCOSESystemsEngineeringHandbook,FourthEdition,2015

[INCOSETP-2018-002-01.0] INCOSESECompetencyFramework,Issue012018;arevisededitionsupersedingIssue032010[theversionoriginatedbytheUKChapter]

[INCOSEUKw22012] INCOSE UK Omega 2 Guide ‘N-Squared: brief guide’, Issue 1.0, 2012 –availableonlinetoINCOSEUKmembersonly.

[Martin2004] Martin, J. ‘The seven Samurai of systems engineering’, Proceedings of theINCOSEInternationalSymposium,2004

[NASA1997] NASAReferencePublication1370 ‘TrainingManual forElementsof InterfaceDefinitionandControl’,1997

[NIST2002] NationalInstituteofStandardsandTechnology(NIST)TechnicalNote1447‘AFunctional Basis for Engineering Design: Reconciling and Evolving PreviousEfforts’,2002

[SEBoK2018] “GuidetotheSystemsEngineeringBodyofKnowledge(SEBoK)Version1.9.1[online].Availableatsebokwiki.org,accessed21stMay2019.

[Sillitto2014] Sillitto, H. ‘Architecting Systems: Concepts, Principles and Practice’, CollegePublications,2014

210609-davies-interface-management.pdf - INCOSE

Documents