System Architecture Representation - FINSE

System Architecture RepresentationDr. Dinesh VermaAssociate Dean and ProfessorThe SDOE ProgramStevens Institute of Technology, USACopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Architecture Definition?Copyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Purpose of a C4ISR Architecture“ The purpose of C4ISR architectures is to improvecapabilities by enabling the quick synthesis of “go-towar”requirements with sound investments leading tothe rapid employment of improved operationalcapabilities, and enabling the efficient engineering ofwarrior systems.”- Adapted from: C4ISR Architecture Framework, Version 2.0Copyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Components of the Framework♦ Common Definitions♦ Common Productsand Data♦ Common ReferencesNodeA1999 +StandardOperationalActivity 1 Activity 2IERActivity 3NodeAIERSystemXSystemYNodeCSystemYSystemXNodeBSystemsSystemXSystemSystem YZTechnical1998StandardIERActivity 1Activity 2NodeCNodeBUJTLCADMJOALISIDDDSLISITRMCOESHADEJTADDDSCADMLISICOECopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Inter-relationshipsrelationships – JTA RepresentationOperationalViewSystemsViewProcessing and Inter-NodalLevels of InformationExchange RequirementsRelates Capabilities and Characteristicsto Operational RequirementsSystems Associationsto Nodes, Activities,Needlines andRequirementsIdentifies WarfighterRelationships and Information NeedsSpecific CapabilitiesIdentified to SatisfyInformation-ExchangeLevels and OtherOperational RequirementsProcessing and Levels ofInformation ExchangeRequirementsBasic TechnologySupportability andNew CapabilitiesTechnical Criteria GoverningInteroperable Implementation/Procurement of the SelectedSystem CapabilitiesTechnicalViewPrescribes Standards andConventionsCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

System Architectures - Classical RepresentationFunctional DeficiencyOperational DeficiencyTechnology FusionTechnology BreakthroughBehavior AnalysisAccidental Discovery1. Need/OpportunityIdentification2. ImplementationApproachIdentification ofStakeholdersIdentification ofStakeholder RequirementsGeneration, Evaluation, &Selection of Concepts1. ImplementationApproach2. StakeholderPriorities3. System ScopeOperational ViewDevelopment of aContext DiagramIdentification ofSystem ObjectivesDevelopment of UseCase Scenarios1. Originating Requirements2. Feature Priorities3. External InterfacesFunctional ViewDevelopment of aFunctional DiagramIdentification ofInternal InterfacesClustering of SystemFunctions/SubsystemsPhysical ViewDevelopment of aPhysical Block DiagramIdentification ofPhysical InterfacesSelection ofTechnologies/SubsystemsPrimary Functional SystemDevelopment and Production SystemValidation and Testing SystemOperationalModelService and Maintenance SystemCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with AttributionDetail Design6

Architecture DefinitionUser’s/Operator’s View• Elements– People• External Users• Internal Operators• Maintainers– Human Machine Interface Devices• Displays• Keyboards• Mice/Joysticks• Headsets• Printers– Interconnectivity• Vision• Audio• Touch/Feeling• User’s/Operator’s/Maintainer’s Environment• System Impacts– Equipment Configuration and Location– Training Requirements - Level of Expertise– Cost of Operation• Number of People Required• ProductivityCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Architecture DefinitionApplication (Functional) View• Elements– Capabilities• For Example:– Interface Management– Organic Tracker DB– In-Organic Tracker DB– Target Motion Analysis– All Source Contact Management– Launch Control– Interconnectivity• Messages Passed BetweenCapabilities to Perform an End toEnd Function• System Design Impacts– Resource Requirements• Bandwidth• Processing Throughput• Storage– System ComplexityESMRADARSonarOff-BoardInterface InterfaceManagementManagementStatic ViewIn-organic In-organicTracker Tracker DB DBOrganic OrganicTracker TrackerDB DBAll All Source SourceContact ContactManagementManagementCommon CommonServices ServicesTarget TargetMotion MotionAnalysis AnalysisLaunch LaunchControl ControlCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Architecture DefinitionApplication (Functional) ViewDynamicInterfaceManagementOrganicTrackDB DBInorganicTrack DB DBTargetMotionAnalysisAll All SourceContactManagementLaunchControlESMRADARSONARTracker DataTracker DataTracker DataTime Series Tracker DataTime Series Tracker DataCalculate ContactRange RateCalculate ContactBearing RateCalculate ContactRangeContact Info to theOperatorOFF-BOARDSensor DataTime Series Sensor DataAdditional Contact InfoCombine Additional ContactInfo with Existing DataAssociate Contact InfoSelect Target forProsecutionPermission toProsecutionTarget Information to WeaponOrder GenerationCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Architecture DefinitionData ViewInboundfeedsCIR ExtractStaging DBSourceDBTeamCatalogTeamSiteASync.BatchServerUCOutboundfeedsCOREDpropProductionDBProductionCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

• Elements– Configuration ItemsArchitecture DefinitionPhysical View• Subsystems• Units• HWCI’s and CSCI’s• Replaceable Assemblies– Interconnection• Physical Links– Networks– Point to Point• System Design Impacts– Performance Limitations– Inability to UpgradeESMRADARSonarOff-BoardHP743Unix Operating SystemHP743Unix Operating SystemHP743Unix Operating SystemHHP744Unix OperatingSystemATMTCP/IPOC-3HHP744Unix OperatingSystemHP743Unix Operating SystemHP743Unix Operating SystemCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Architecture Definition• A Complete SystemDescription Includes AllThree Views of theArchitecture– The People and WhereThey Interact with theSystem–The Capabilities Withinthe System and theMessages that FlowBetween Capabilities–The Hardware,Software, and PhysicalLinksESMRADARSonarOff-BoardInterface ManagementHP743Unix Operating SystemContact DataAll Source ContactManagementHP743Unix Operating SystemCorrelatedContactDataTarget Motion AnalysisHP743Unix Operating SystemTargetPositionalDataOrganic Target DBHP744Unix OperatingSystemContact DataTargetDataATMTCP/IPOC-3In-organic Target DBHP744Unix Operating SystemContact DataLaunch ControlHP743Unix Operating SystemCommon ServicesHP743Unix Operating SystemCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Documenting a System ArchitectureCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Capturing an Architecture BaselineFunctionalArchitectureRefinementPhysicalArchitectureRefinementOperationalArchitectureRefinementDefine BusinessRequirementsBaseline (1)DefineFunctionalAreasDefineDefineApplication LandscapeDiagrams (2a, 2b)Define Use Cases (4)= SE= ApplicationDevelopers= Test TeamDefine SystemRequirementsAllocateRequirements toFunctional AreasData Initialization andMigration (3)AllocatePhysical ApplicationDiagrams byFunctional Area (5)Links (7)Messages (8)VerifyInteractionDiagrams (6)DeriveAllocate DerivedRequirements toApplicationsAllocateApplication LevelArchitectureDevelopmentTestScenarios (9)RequirementsVerificationMatrix (10)VerifyVerifyFunctionalVerification TestSITExecuteTestCasesCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Capturing an Architecture Baseline• Why Is Capturing the Baseline Important– Clear, Concise Problem Definition to theDevelopment Team• Build What the Customer Wants– Test Planning• Definition of the Test Environment• Data Migration and Initialization– Reduce Learning Curve for IndividualsComing onto the Project• Future UpgradesCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

(1) Technical Scope DocumentApplicationS/W Impact Data LinkSchedule InformationReqm'tAffectedApplication S M L N M N M Requirement DescriptionTarget motionLocalization to within 10% of actual in both bearingAnalysis X Xand range for contacts held by organic sensors1All Source ContactMulti-sensor correlation of contacts held on2 Management Xorganic sensorsContact association across 5000 contacts fromAll Source Contactin-organic sensors within 15 minutes of receipt3 Management X X X of dataAll Source Contact4 Management X X Contact association across all sensorsFull operational capability with 4 or less5 All X X operators5.1 Common Services X All Operators shall receive the same training0.995 Operational Availability for a 90 day6All X X X missionHorizontal launch of ADCAP and Tomahawk7 Launch Control Xweapons8 Launch Control X X X Vertical launch of Tomahawk weaponsDesign/Code/TestDates7/1/02 -10/1/028/1/02 -10/1/027/1/02 -12/1/028/15/02 -12/1/029/1/02 -11/1/0210/1/02 -11/15/029/1/02 -12/1/029/1/02 -12/1/027/1/02 -11/15/02SWIT/Unit TestDatesDeliveryto SystemTest10/1/02 -12/1/02 12/5/200210/1/02 -11/15/02 11/15/200212/1/02 -2/1/03 2/3/200312/1/02 -2/1/03 2/3/200311/1/02 -12/1/02 12/5/200211/15/02 -12/1/02 12/5/200212/1/02 -2/1/03 2/3/200312/1/02 -2/1/03 2/3/200311/15/02 -2/1/03 2/3/2003Copyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

(2b) Application LandscapeRole orApplicationAcronym/NameCapabilitiesVersionTechnical InfrastructureCommon Services(CS)Display formattingAuto PlotsPerformance MonitoringDiagnostics1.0aUnix Operating System onHP743 Single BoardComputerTarget MotionAnalysis (TMA)MATE, KAST, and PolarCoordinate Ranging Algorithms1.0Unix Operating System onHP 743 Single BoardComputerOrganic SensorDatabaseStorage and Retrieval of contacttime series information (contact id,bearing, base frequency, D/E angle)4.11aUnix Operating System onHP777 ServerCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Enterprise Systemxxx Easy Access368Easy Access 1.3 Landscape EnvironmentNorth AmericaHWPIMS 275MMLCEA1311321,561HWWWASWWPRTWings/ExecEdgeSRTSEA1304CPMLEA1306EDI166,386UN CodesWebSitewww.unspsc.org318EA1308EA1310EA1316AspectEA1307ProductManagerPartnerCommerce(PCOM)IPDOPICME-CIMOPICM DTEA1303EA1315370167SuperDG326MMLC RDH342365EA1309315PromotionsWCCSEA1313EA1312EA1305WIZARDEA1318IBMRegistrationECIM Dev327243SCPDPBIDSEA1317ESATEA1319LocalCatalogFTP Site158491CommerceControlCenter367EA1326CEDSHLVC144246DSPEA1314515CMRCMR RepEA1323MPP RepEA1322MPPI2EA1352EA1351341EA1353EMLSGDMFieldProfit Tool492CatalogStagingServerLENA81344516EA1331244343320339239399EA1321MPPRDHEA1320470EA1350P2LEA1302CustomerBrowserEA1325387SlingshotCommerceEngine494,543 66298InfosourceFODS238Taxware466,578340240ATP468FLC241EA1349MHSPortal369493324SAP PAriba BuyereProcurement29,537TxnHub455298,459465,541249SAPHW138,473EA1333488479, 463478PEWAribaCommerceNetworkCustomerB2BGatewayGatewayAdministratorS&D IWSMSEA1336GreenockIMCIR 451PaymentSystems134EA1327Service ToolPakEA1354EA1328EA1329EDICoCSAP GUI137EA1335EA1332DSGFDS131ELITDDBCCSDB11651LPSIDMEA1337IDDEEA1339EA1338Genesis/XSNDEA1334GuadSAPEA1340119,257472EA1341EA1342EA1343DFCEA1347E-Warehouse EA1348GWS EA1346EA1345126 STP EA1344E-ReportsE-SolomonPreloadImageSAP Order DeskCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Easy Access 1.3 LandscapeEnvironmentNorth AmericaECIM DevE-CIMPromotionsEnterprise SystemEA1316WWPRTxxx Easy AccessHWPIMS 275PPRDS321,561MMLC318EA1303EA1311HWWWAS370EA1310368Wings/Exec EdgeEA1313SRTSEA1312EA1304UN CodesWebSitewww.unspsc.orgIPDOPICMOPICM DTCPMLEA1306ProductManagerEA1307IPDIBMRegistrationPartnerCommerce(PCOM) 166,386EA1315EDISuperDG326MMLC RDH342327243CustomerDataMPP Rep315341SCPDPBIDS365WCCSEA1308EA1305EA1309WIZARDAspectEA1318ECCOCECCOCIT/FTPSiteFieldProfit Tool492491158CommerceControlCenterCatalogStagingServer387EA1352DSPEA1351CEDS144515CMR RepEA1322EA1314MPPEA1323HLVC246CMRI2339LENA 399516320244MPP239RDH344343470 EA1353EA1320EA1350EA1317EMLSGDMP2LEA1319 ESATEA1302PlanningCustomerBrowserEA1325SlingshotCommerceEngine16766494,543298EA1326 81 324InfosourceFODS238Taxware466,578340240ATPFLC468241EA1349MHSPortalSAP PAriba BuyereProcurement29,537TxnHub455298,459465,541SAPHWEA1333488138,473479, 463478PEWAribaSupplierNetworkB2BGatewayFulfillmentEA1327 249CIR 451EA1328134137CCSDBDSG51IDMEA1337EA1338EA1334GuadSAP472EA1347E-WarehouseEA1348E-ReportsCustomerGatewayAdministratorCommerceEnginesSMSEA1336S&D IWGreenockIMWarehouseSAP Order DeskService ToolPakSAP GUIEA1329EDICoCEA1332EA1335EA1354EA1331FDSPaymentSystemsFinancialELITDDB131IDDE116DistributionSystemsGenesis/XSNDEA1339LPSEA1340119,257EA1341EA1342EA1343DFC126GWSEA1345STPEA1346EA1344E-SolomonPreloadImageManufacturing andDistributionCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

(3) Data Initialization and MigrationRequirementData TypeData SourceAttributeNeededTest Requires AttributeToggle/Change?1ContactPositionTMARangeYes2ContactPositionOff-BoardSensors viaInterfaceManagementX,Y,Z positionand time ofYesCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

(4) Use Cases7. CommonServices1. CollectOrganicSensor Data2. PerformLocalization4. CollectIn-OrganicSensor Data5. AssociateIn-organicContactData3. ProsecuteTarget6. AssociateAll ContactDataSystemUseCase IDSystemUse CaseNameSystem CapabilitySystemTestScenarioInvokedby:Predecessor(s)AverageRatePeakRateHyperlink1CollectOrganicSensor DataStore Time Series Datafrom Organic SensorTrackersTestOrganic DBStore/SchemaDataflowNone12 Hz percontact12 Hzpercontact2PerformLocalizationCalculate contact bearingrate, range, and range rateTestLocalizationDataflowCollect OrganicSensor DataCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

(5) Functional Area Physical DiagramsESM1Tracker Data9 10RADAR2Tracker DataTracker DataContact Data7Contact DataContact DataSonar3In-OrganicSensor Data11Weapon DataWeaponsInterfaceExternalCommunications4Display Data5CorrelatedContactDataTargetData126Display DataTargetPositionalData 8ATMTCP/IPOC-313SystemAdministrationDataCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Architecture DefinitionLogical (Functional) ViewDynamicInterfaceManagementOrganicTrackDB DBInorganicTrack DB DBTargetMotionAnalysisAll All SourceContactManagementLaunchControlESMRADARSONARTracker DataTracker DataTracker DataTime Series Tracker DataTime Series Tracker DataCalculate ContactRange RateCalculate ContactBearing RateCalculate ContactRangeContact Info to theOperatorOFF-BOARDSensor DataTime Series Sensor DataAdditional Contact InfoCombine Additional ContactInfo with Existing DataAssociate Contact InfoSelect Target forProsecutionPermission toProsecutionTarget Information to WeaponOrder GenerationCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

(7) LinksI/FNo.SourceDestinationNMEProtocolPhysicalCapacityAverageUtilizationPeakUtilizationOwner1ESMInterfaceManagementNRequest/AcknowledgeNTDSFast667Kbytes/Sec30%60%2RADARInterfaceManagementNRequest/AcknowledgeNTDSFast667Kbytes/Sec20%25%3SonarInterfaceManagementNRequest/AcknowledgeNTDSFast667Kbytes/Sec40%75%45TMAUserMTCP/IPATM155Mbytes/Sec10%20%Copyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

(8) MessagesMessageNameMessage DescriptionLinkNMESystem UseCase IDSize (Bytes)ESM_Track_DataESM Contact Tracker Data (contact id, bearing)1N1128 BytesRADAR_Track_DataRADAR Contact Tracker Data (contact id,bearing)2M164 BytesSonar_Track_DataSonar Contact Tracker Data (contact id,bearing, base frequency)3M1256 BytesCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

(9) Test ScenariosSystemUse CaseNameTest ScenarioNameTest Scenario DescriptionTest Case NamesDrivingApplicationCollectOrganicSensor DataTest Organic DBStore/ SchemaUsing simulated or real data fromESM, RADAR, and Sonar provideinputs to Interface Management tobe forwarded to the OrganicSensor Database for storage andretrieval.Test ESM InputsTest RADAR InputsTest Sonar InputsPerformLocalizationTest LocalizationUsing tracker data informationcontained in the Organic SensorDatabase, validate therequirements for contact range andbearing localizationTest MATETest KASTTest PolarCoordinatesCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

(10) Requirements Verification MatrixRequirementCapabilitySWITUnitTestFactoryAcceptanceTestInstallationSea Trials1TMATDD2ASCMTDD3ASCMDT455.1678Copyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Documenting an Architecture• 10 Elements are Required to Document an Architecture– 1. Requirements Baseline – Technical Scope– 2a. Physical View– 2b. Functional Description– 3. Data Initialization and Migration– 4. Use Cases– 5. Allocation of Requirements to Physical/FunctionalView– 6. Interaction Diagrams (Data Flow)– 7. Links– 8. Messages– 9. Test Scenarios– 10. Requirements Verification Matrix (RVM)Copyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

Research Being Conducted by Christopher Carlsen(Masters – Stevens Institute)• Problem Statement:Problem Statement:– Current market trends in the commercial defence market• Reduced development cost• Increased use of sub-suppliers• Increased use of COTS components• Higher turnover rate in development department– …suggest that traditional architectural and system designdocumentation during product development may no longer besufficient for current and future long-term (and low volume) productsustainment.– The objective is to develop a system capable of being produced insmall volumes the coming 30 years, and capable of being maintainedeven longer,– In light of constantly evolving functional capabilities, changingphysical implementation and changing workforce– In a cost effective mannerCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

The Architecture and Systems Model– The systems model – shall be a product of the entiredevelopment effort, and shall contain what was kept aswell as what was discarded– The systems model will act as the product’s collectivememoryIf the systems model is unknown (undocumented), itwill be impossible to cope with future changes withreasonable resources given our production volumeCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

System Model – Information structures• The following structures realize the system model:• Requirements hierarchy– All contract requirements – with requirement breakdown are internallyordered in a traceable structure– Analyses performed as part of requirement breakdown are attached to allinfluenced requirements– Test- and verification information are attached directly to the requirements• System hierarchy– All systems are ordered in a stringent hierarchy (a stingent hierarchy isdefined as a hierarchy in which each object can have only one parent (asopposed to the requirement hierarchy, where one requirement can havemultiple parents))– Textual infromation used in specifications and similar, are attached directly tothe system• Functional hierarchies– All functions are ordered in a set of stringent hierarchies– Each function shall be allocated to one system (applies to the leaf-nodefunctions)– All functional requirements are allocated to the function– Data- and control flow between functions are given by their internal relationsCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

System Model – Information structures• System physical hierarchies– Models the physical architecture for each subsystem– System functions are allocated directly to the parts– Non-functional requirements are allocated to the part• Assembly hierarchy– One stringent hierarchy containing all parts organized inassemblies– Physical requirements following from the ”packaging process” areallocated to on applicable levels– Failure modes are attached to the component– Testpoints are identified in the structure– Signal tracing are given by the relations among the parts /assemblies, and their functional counterpart are given by theralations to the functional hierarchiesCopyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution

If you are interested in this research, and would be willing toshare your thoughts in a telephonic interview/discussion,please give us your contact information:Name:Phone:Email:Copyright – Stevens Institute of Technology - Dinesh Verma; dverma@stevens-tech.edu; (210) 216-8645; Use Allowed with Attribution