Presentation is loading. Please wait.

Presentation is loading. Please wait.

© A. H. Levis INCOSE L. 4 - 1 C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES LECTURE 4 A C4ISR ARCHITECTURE FRAMEWORK IMPLEMENTATION PROCESS CASE.

Similar presentations


Presentation on theme: "© A. H. Levis INCOSE L. 4 - 1 C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES LECTURE 4 A C4ISR ARCHITECTURE FRAMEWORK IMPLEMENTATION PROCESS CASE."— Presentation transcript:

1 © A. H. Levis INCOSE L C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES LECTURE 4 A C4ISR ARCHITECTURE FRAMEWORK IMPLEMENTATION PROCESS CASE STUDY LEE WAGENHALS ALEXANDER H. LEVIS

2 © A. H. Levis INCOSE L INTRODUCTION This illustrative example of the implementation process is based on a relatively new product developed by the Mobil Corporation called the Mobil SpeedPass. It is not an accurate description of the system – it has been created for the express purpose of illustrating the architecture design process – Highlights the case where a new information technology providing a new capability is grafted on existing large legacy information systems. – Assumes that some oil company (OilCo) has implemented a new system called FastPass. This example has been chosen in lieu of a DoD example because of its familiarity to a large audience. We start with a description of the goal of the system and proceed through the five stages presented in Chapter 3.

3 © A. H. Levis INCOSE L STAGE 0 INPUTS AND OPERATIONAL CONCEPT We assume that all of the initial research of Stage 0 has been completed and the input documents collected. Part of this process is the gathering of information about the Operational Concept. In this example, we assume that OilCo has been informed about a new technology that allows information to be encoded in a small device and be retrieved by a small radio signal. OilCo believes that such technology can be incorporated in gasoline pumps to make it more convenient for drivers to purchase gasoline via a credit card account. – Drivers would need to sign up for the FastPass service and provide to OilCo the standard information contained on the credit card they normally use to purchase gasoline. – OilCo would store this information in a Central database and issue the driver a FastPass device in the form or a rear window mounted tag or a key chain. – The device would contain a unique code that OilCo could match to the credit card information in the central data base.

4 © A. H. Levis INCOSE L STAGE 1 (A1) Operational Concept (AV1 and D1) High Level Operational Concept Graphic (OV1) Analyze Operational Concept A11 Create High Level Operational Concept Graphic A12 C4ISR Architecture Framework Create Textual Description A13 Elements, Organizations, Connections Graphic Text

5 FASTPASS: OPERATIONAL CONCEPT SYSTEM BOUNDARY Driver enters bay Drive Activates FastPass with device After Permission, driver selects grade of gas and fuels car Driver leaves Gas Pump LAN WAN Check credit information Authorize credit purchase Update credit information Turn on FastPass Light to show process is working Issue Permission to fuel Print Receipt Turn off FastPass Light FastPass light Gas Station Office OilCo Central Data Base Retrieve Driver Information L Financial Institution Driver

6 © A. H. Levis INCOSE L STAGE 2 (A2) Organization List (D3) Organizational Relationships (D4) High Level Operational Concept Graphic (OV1) Functional Decomposition (IP21) Create Functional Decomposition A21 Select Organizations A22 Determine Organizational Relationships A23 C4ISR Architecture Framework Determine Assets A24 Define Operational Elements A25 Define Operational Nodes A26 Organizational Intermediate Products (IP-22) Organizations Operational Elements Organizational Assets Operational Nodes Operational Concept (AV1 and D1) Command Relationship Chart (OV4) Universal Joint Task List (UJTL-D2)

7 © A. H. Levis INCOSE L STAGE 2 INPUTS Universal Joint Task List (UJTL) – The architect selects the appropriate tasks from UJTL and constructs the hierarchy that is appropriate to the domain and that is consistent with the UJTL High Level Operational Concept Graphic and Narrative Operational Concept and Descriptions Organizational Lists and Descriptions – Includes standard assets that typical organizations have Organizational Relationships – Standard line and staff relationships

8 © A. H. Levis INCOSE L FUNCTIONAL DECOMPOSITION UJTL 1. Validate Accounts 1.1 Sense FastPass 1.2 Retrieve Driver Information 1.3 Validate Credit 2. Operate Pump 2.1 Receive Authorization 2.2 Dispense Gas 2.3 Compute Cost of Sale 3. Prepare Billing 3.1 Request Charge 3.2 Print Receipt 3.3 Update Accounts Operate FastPass GasStation System Validate Accounts Operate Pump Prepare Billing Sense FastPass Retrieve Driver Information Validate Credit Compute Cost of Sale Request Charge Update Accounts Print Receipt Dispense Gas Receive Authorization Driver enters bay Drive Activates FastPass with device After Permission, driver selects grade of gas and fuels car Driver leaves Gas Pump LANLAN WANWAN Check credit information Authorize credit purchase Update credit information Turn on FastPass Light to show process is working Issue Permission to fuel Print Receipt Turn off FastPass Light FastPass light Gas Station Office OilCo Central Data Base Retrieve Driver Information Financial Institution Driver

9 © A. H. Levis INCOSE L ORGANIZATIONS Four organizational entities are considered as shown the table Each organizational entity has assets that are the basis for systems in the systems view: – The FastPass central data base is maintained by OilCo that manages the FastPass system; – The Gas Station has a pump, gas, and the electronic ledger for recording sales of gasoline; – The Financial Institution that issue the credit cards used by the Drivers through the FastPass system, and the Driver. OrganizationAssets OilCoFastPass Central Data Base Gas StationPump, Gas, Ledger, Office Database Financial InstitutionFinancial Account Database DriverFastPass Account, Credit Account, FastPass Device

10 © A. H. Levis INCOSE L OPERATIONAL NODES AND ELEMENTS The architect determines operational nodes and elements. They will be used to create the Operational Node Connectivity Description (OV – 2) Operational Nodes and Elements are determined with the help of the organizations and the operational concept graphic Operational Nodes contain one or more Operational Elements Operational NodeOperational Elements Driver Gas StationPump, Gas Station Office OilCo Financial InstitutionsFinancial Institution

11 © A. H. Levis INCOSE L COMMAND RELATIONSHIP CHART (OV-4) The Command Relationship Chart depicts direct control and coordination relationships between the organizations selected OilCo provides a franchise to the Gas Station and provides the FastPass account to the Driver. Both the Driver and the Gas Station have accounts with the Financial Institution. The Driver and the Gas Station Interact with each other. These relationships are depicted in the Command Relationship Chart Driver Gas Station Interacts Financial Institution OilCo Provides FastPass Provides Account Provides Franchise

12 © A. H. Levis INCOSE L STAGE 3

13 © A. H. Levis INCOSE L STAGE 3 INPUTS Doctrine, tactics, procedures, and practices (Domain) Functional Decomposition (Stage 2) States and Events that exist in the operational concept (Domain) System Descriptions including descriptions of System Functions for the types of systems (from the assets) that the organizations have (or will have) Organizational Descriptions and Intermediate Products from Stage 2 –Operational Elements –Operational Nodes –Assets

14 © A. H. Levis INCOSE L CREATE THE ACTIVITY MODEL (OV-5) External System Diagram can be used to capture the interactions of the system with the externalities as described in the Operational Concept Helps define the Context Diagram (A-0) Operate FastPass System A0 Authorization_Transaction FastPass_Device Selection Display Receipt Purpose: To describe the operations of the Speed Pass System View Point: System Architect Perform Driver Activities A-01 Provide Financial Services A-02 Financial_Transaction Bank_Transaction

15 © A. H. Levis INCOSE L CONTEXT DIAGRAM Easily derived if the External System Diagram is used

16 © A. H. Levis INCOSE L A0 DIAGRAM Matches the Functional Decomposition

17 © A. H. Levis INCOSE L A1 DIAGRAM - VALIDATE ACCOUNTS

18 © A. H. Levis INCOSE L A2 DIAGRAM – OPERATE PUMP Authorization_Transaction Selection Display Dispensed _Gas_Data Receive Authorization A21 Dispense Gas A22 Compute Cost of Sale A23 Authorization_Transaction Dispensed_Gas_Data on, grade, gallons "off", grade, gallons Gas_Pricing

19 © A. H. Levis INCOSE L A3 DIAGRAM – PREPARE BILLING

20 © A. H. Levis INCOSE L LOGICAL DATA MODEL (IDEF1x) (OV-7)

21 © A. H. Levis INCOSE L OV-6a: OPERATIONAL RULE MODEL Activation Rules are created for each activity that is at the lowest level of the decomposition 1. Validate Accounts 1.1 Sense FastPass(A11)) R111: If FastPass present then FastPassID = decode(FastPass) and Display = Welcome to FastPass; 1.2 Retrieve Driver Information(A12) R121: If FastPassID = DriverInformation.FastPassID then select(DriverCreditAccount) and Display Validation Credit; 1.3 Validate Credit(A13) R131: If DriverCreditAccount present and Authorization Number present then Financial Transaction = Type = 1, Driver Credit Account, Authorization Number, false) and Authorization Number = Authorization Number + 1;

22 © A. H. Levis INCOSE L RULE MODEL (CONTINUED) 2. Operate Pump 2.1 Receive Authorization (A21) R211: If Authorization Transaction.approval = True Then send Authorization Number and Display = Select Grade and Start Pumping Else Display = Please See Attendant; 2.2 Dispense Gas R221: If Authorization Transaction.approval = true and Selection =on Then (DispensedGasData. id = Authorization Transaction.driver credit number DispensedGasData.Grade = Selection.Grade; DispensedGas.QuantityControl = Selection.QuantityControl ) And Display = The Grade of Gas is + DispensedGas.Grade, The dispensed Quantity of Gas is + DispensedGas.QuantityControl, When Done, Turn off Pump; 2.3 Compute Cost of Sale R231: If Selection = off and DispensedGasData present Then (DispensedGasData. id = Authorization Transaction.driver credit number DispensedGasData.Grade = Selection.Grade; DispensedGasData.QuantityControl = Selection.QuantityControl DispensedGasData.cost = If grade = 1 then QuantityControl * price_Regular Else if grade = 2 then Quantity Control * price_Midgrade Else QuantityControl * price_HiTest) And Display = Please Wait for Receipt

23 © A. H. Levis INCOSE L RULE MODEL (CONTINUED) 3. Prepare Billing 3.1 Request Charge R321: If CostOfSale > 0 And Driver-Information.Pump-id = DriverCreditAccount Then Financial Transaction = GasStationAccount + DriverCreditAccount + Cost of Sale; 3.2 Print Receipt R321: If DispenseGasData present Then Receipt = Date + Gas Station ID + Gas Station Name + Gas Station Address + + Cost of Sale; Print Receipt 3.3 Update Account R331: If Bank Transaction present Then Update GasStation Account

24 © A. H. Levis INCOSE L OPERATIONAL STATE TRANSITION DIAGRAM (OV-6b) Created for the overall system Indicates basic states of the system and the events that causes the system to change states Describes the desired behavior of the system per the Operational Concept Pump Is Idle Validating Credit Do: Retrieve Driver Information, Validate Credit Dispensing Gas Do: Dispense Gas Computing Cost of Sale Do: Compute Cost of Sale Printing Receipt Do: Print Receipt c Car arrival[FastPass Driver] /Sense FastPass Credit approved /Activate Pump Finish Fueling/ Deactivate pump Receipt printed Cost of Sales calculated Start Credit disapproved car arrival [Non FastPass Driver]

25 © A. H. Levis INCOSE L ALLOCATE ACTIVITIES Decide which activities the operational elements you selected will perform the leaf activities of the functional decomposition Operational ElementActivities Financial Institution (Update Account) (Validate Credit) Gas Station OfficeUpdate Accounts OilCoRetrieve Driver Information Pump Sense FastPass Request Charge Receive Authorization Dispense Gas Print Receipt Compute Cost of Sale Validate Credit

26 © A. H. Levis INCOSE L SYSTEMS, ELEMENTS, AND FUNCTIONS The following type of information is used to allocate operational activities to system functions

27 © A. H. Levis INCOSE L ALLOCATION OF OPERATIONAL ACTIVITIES TO SYSTEM FUNCTIONS For each leaf activity of the functional decomposition, decide which system element function(s) will be used to perform the activity

28 © A. H. Levis INCOSE L CREATE NEEDLINES Needlines are directed arcs between operational nodes. They represent the need for the flow of operational information between operational nodes. Using the activities that have been allocated to operational nodes and the flow of information between those activities expressed in the IDEF0 model, indicate the operational nodes and needline flows on the following partially completed Operational Node Connectivity Description Driver Gas Station Mobil Financial Institution

29 © A. H. Levis INCOSE L INITIAL PHYSICAL ARCHITECTURE The system components and elements that will be used have been determined; assign them to system nodes. Using the knowledge gained from defining the needlines, create an initial physical architecture diagram showing the elements and components in system nodes and the communications links between those system elements, components and nodes. – These links must be consistent with the allocation of activities to system functions and the operational information flows between the activities to be performed by the system functions you determined previously.

30 © A. H. Levis INCOSE L INITIAL PHYSICAL ARCHITECTURE Driver Financial Institution Database SpeedPass Central Database Gas Station Office Database Radio link Lan Wan Pump Wan

31 © A. H. Levis INCOSE L STAGE 4 (A4)

32 © A. H. Levis INCOSE L STAGE 4 INPUTS Operational Information Elements (Domain) Activity model products (IDEF0, IDEF1x, Rule Model) Activity Allocations Needlines Initial Physical Architecture

33 © A. H. Levis INCOSE L OPERATIONAL INFORMATION ELEMENTS From the Allocation of Activities to Operational elements, and the flow of information captured in the IDEF0 model, create a table that identifies the Operational Element that is producing the Operation Information. Each Operation Information Element is a flow of information captured in the IDEF0 diagram at the leaf activity level. Operational Information Element Producing Operational Element Authorization_Transaction (Approval) Financial institutions Bank_Transaction (complete)Financial Institutions Dispensed Gas DataPump DisplayPump Authorization_Transaction (request)Pump Driver InformationOilCo Grade of Gas (Selection)Driver FastPass DeviceDriver Quantity Control (Selection)Driver ReceiptPump Bank_Transaction (request)Pump FastPass IDPump

34 © A. H. Levis INCOSE L OPERATIONAL NODE CONNECTIVITY DESCRIPTION (OV-2) The Operational Node Connectivity Diagram can be completed by adding the data flows from the Activity Model to the needlines and the activities to the operational nodes Provide FastPass Select Option Driver Gas Station PumpOilCo Activities Retrieve Driver Information Gas Station Office FastPass Selection Display Receipt FastPass ID Driver Information Dispensed Gas_Data Bank Transaction Activities Update Accounts Sense FastPass Receive Authorization Dispense Gas Compute Cost of Sale Request Charge Print Receipt Validate Credit For GSO For Pump Authorization_Transaction (approval) Bank_Transaction Financial Institution Activities (Validate Credit) (Update Accounts) Authorization_Transaction (Request) Bank_Transaction (request)

35 © A. H. Levis INCOSE L OPERATIONAL INFORMATION EXCHANGE MATRIX (OV-3) Using the activity model and OV 2 as a guide, complete the Operational Information Exchange Matrix. Note that the type and size (in bytes) of information or data and the media are indicated. This information is used to define messages in the Systems Architecture View

36 © A. H. Levis INCOSE L SYSTEM FUNCTIONALITY DESCRIPTION (SV-4) Activity Model based on system functions Either IDEF0 or Data Flow Diagrams can be used; we will illustrate DFD (advantage, explicit Data Stores) Suggest first creating the Context Diagram Then work bottom up – Develop DFD of the system functions at the leaf level – Aggregate these at an intermediate level and then aggregate the intermediate level into the context diagram

37 © A. H. Levis INCOSE L CONTEXT DIAGRAM Operate FastPass System FastPass Device Selection Display Receipt Purpose: To describe the System Functions of the FastPass System View Point: System Architect Driver Financial Institution Authorization_Transaction Bank_Transaction Authorization_Transaction Bank_Transaction

38 © A. H. Levis INCOSE L DFD OF PUMP FUNCTIONS

39 © A. H. Levis INCOSE L DIAGRAM Aggregate lower level pages to form 0 - Diagram

40 © A. H. Levis INCOSE L OPERATIONAL ACTIVITY TO SYSTEM FUNCTION TRACABILITY MATRIX (SV-5) Documents operational activity allocation

41 © A. H. Levis INCOSE L PHYSICAL DATA MODEL (SV-11) Specifies Messages, Data Store Records, Display Content, etc.

42 © A. H. Levis INCOSE L PHYSICAL DATA MODEL (CONTD)

43 © A. H. Levis INCOSE L STAGE 5 COMPLETE SYSTEM ARCHITECTURE VIEW PRODUCTS

44 © A. H. Levis INCOSE L SYSTEM INFORMATION ELEMENTS The following table is derived from the DFD and the systems that perform the functions in the DFD. It will be used to complete the System Information Exchange Matrix

45 © A. H. Levis INCOSE L LAN/WAN SELECTION Using the initial physical architecture and domain knowledge about message size and frequency, determine the type of communication service needed to provide the needed flow of information between system elements, components, and nodes Driver Financial Institution Database FastPass Central Database Gas Station Office Database Radio link Lan Wan Pump Wan 10 Mbps TCP/IP 56K/T - 1 Link TCP/IP 56K/T - 1 Link TCP/IP

46 © A. H. Levis INCOSE L DEFINE INTERFACE TYPES Status Existing Interface S1 Security Classification Public Key C1 Plain C2 Means Radio M1 56 K link X M2 T1 Link Frame Relay/ATM M3 10/100 Mbps LAN M4

47 © A. H. Levis INCOSE L SYSTEM INTERFACE DESCRIPTION (SV-1) Gas Station Office Database FastPass Central Database T-1 link Banking Support Node LAN (10 Mbps, TCP/IP) 56K link Gas Station Support Node FastPass Service Support Node Pump Financial Institutions Database T-1 link ATM Backbone (TCP/IP) FastPass Device Driver Node Microwave

48 © A. H. Levis INCOSE L SYSTEM COMMUNICATIONS DESCRIPTION (SV-2)

49 © A. H. Levis INCOSE L SYSTEM2 MATRIX (SV-3)

50 © A. H. Levis INCOSE L SYSTEM INFORMATION EXCHANGE MATRIX (SV-6)

51 © A. H. Levis INCOSE L SYSTEM INFORMATION EXCHANGE MATRIX (CONTD) Note: This is not the complete matrix. The columns that specify the parameters of the system information elements have been omitted

52 © A. H. Levis INCOSE L SYSTEM PERFORMANCE PARAMETER MATRIX (SV-7) Essential for Evaluation

53 © A. H. Levis INCOSE L SYSTEM EVOLUTION DESCRIPTION (SV-8)

54 © A. H. Levis INCOSE L SYSTEM TECHNOLOGY FORECAST (SV-9)

55 OPERATIONAL ARCHITECTURE VIEW PRODUCTS

56 SYSTEM ARCHITECTURE VIEW PRODUCTS

57 © A. H. Levis INCOSE L CONCLUSION The six stage process has been illustrated using the FastPass example –A simple example for classroom purposes –Illustrates important features of typical C4ISR Architectures It is one approach to developing the architecture products specified by the C4ISR Architecture Framework Alternative approaches are possible; the six stage process can serve as a template to ensure that the alternative approaches cover all needed steps and produce a complete architecture description

58 © A. H. Levis INCOSE L SYNTHESIS OF EXECUTABLE MODEL FROM STRUCTURED ANALYSIS BASED ARCHITECTURE (Demonstration) LEE W. WAGENHALS DAESIK KIM EXECUTABLE MODEL

59 © A. H. Levis INCOSE L CONSTRUCTION OF THE COLORED PETRI NETS To each IDEF0 model page corresponds a CPN model page. –The CPN model has the same hierarchical structure as the IDEF0 model The activities in the IDEF0 diagram are converted to transitions: –Decomposed activities are represented by substitution transitions that represent the CPN model page corresponding to the IDEF0 page of the decomposition ICOMs are converted to places with the corresponding color set associated with them

60 © A. H. Levis INCOSE L CONSTRUCTION OF THE COLORED PETRI NET Connect places to transitions with arcs, e.g., Self loops may be introduced to account for: –Data that are on a longer time scale than others –Updates,... A1 A2 Data t1t2

61 © A. H. Levis INCOSE L CPN MODEL TOP LEVEL: CORRESPONDS TO CONTEXT DIAGRAM Inputs Controls Outputs Do HSCondAAW#3 Scenario Driver HSScenario#7 Inputs

62 © A. H. Levis INCOSE L EXTERNAL SYSTEM DIAGRAM Purpose: To describe the operations of the FastPass System View Point: System Architect Operate FastPass System A0 P. 2 Authorization_Transaction FastPass_Device Selection Display Receipt Perform Driver Activities A-01 Provide Financial Services A-02 Financial_Transaction Bank_Transaction

63 © A. H. Levis INCOSE L DESIGN/CPN CONTEXT DIAGRAM ColorSet Place Name Initial Marking

64 © A. H. Levis INCOSE L FAST PASS IDEF0 PROCESS MODEL Purpose: Illustrate IDEF0 and the relationships between the different types of models: process, data and rule Viewpoint: System Architect CONTEXT DIAGRAM Bank_Transaction Selection FastPass_Device Authorization_Transaction Display Financial_Transaction Receipt Operate FastPass System A0 P. 2

65 FIRST LEVEL OF DECOMPOSITION Authorization_Transaction FastPass_Device Selection Display Receipt Validate Accounts A1 P. 3 Operate Pump A2 P. 4 Prepare Billing A3 P. 5 Dispensed _Gas_Data Financial_Transaction Bank_Transaction Authorization_Transaction L

66 DESIGN/CPN FIRST LEVEL DECOMPOSITION L

67 © A. H. Levis INCOSE L DATA MODEL DEFINES COLORSETS

68 © A. H. Levis INCOSE L COLORSETS FROM ENTITIES Data Model contains the following entities FastPass Device Selection Financial Transaction Authorization Transaction Bank Transaction Display Receipt Driver Information Dispensed Gas Data Gas Pricing Driver Credit Account color Int = int; color Boolean = bool; color String = string; (* Inputs in "Operate FastPass System" *) color FastPass_Device = Int; color Selection = product Boolean * Int * Int; color Financial_Transaction = product Int * Int * Int * Int * Int * Boolean; color Authorization_Transaction = Financial_Transaction; color Bank_Transaction = Financial_Transaction; (* Outputs in "Operate FastPass System" *) color Display = product Int * String; color Receipt = product String * Int * Int * Int; (* Colors in A1 -- Validate Accounts*) color Driver_Information = product Int * Int; (* colors in A2 -- Operate Pump *) color Dispensed_Gas_Data = product Int * Int * Int * Int * Int; color Gas_Pricing = product Int * Int * Int; color Accounts = product Int * Int; color Credit_Card_Accounts = product Int * Boolean; DOMAINS ATTRIBUTES GLOBAL DECLARATION NODE

69 © A. H. Levis INCOSE L RULE IMPLEMENTATION Rules in Rule Model are implemented using arc inscriptions, guard functions, and code segments Example: Rule for Activity A21: Receive_Authorization R21: If Authorization_Transaction.approval = true – Then Display.Content = Select grade and start pumping, – Else Display.Content = Credit is not authorized; see attendant And Authorization_Transaction=nil,

70 RULES IMPLEMENTATION Rule A21 L

71 © A. H. Levis INCOSE L MODELING EXTERNAL SYSTEM The Executable Model can be run manually without explicit models of the external systems –Analysts provides appropriate markings as the simulation runs Alternatively, Design/CPN nets of the external systems can be included to automatically stimulate and respond to the system –This can speed up the analysis –Derived with the help of the Dynamics Model

72 DRIVER CP NET INPUTS OUTPUTS DRIVER ACTIONS L

73 © A. H. Levis INCOSE L EVALUATION USING THE EXECUTABLE MODEL Once the executable model has been constructed, it can be used in three forms of evaluation: Logical, Behavioral, and Performance The first step is to validate the logic of the model. –The static views describe the structure, data and rules that manipulate that data to accomplish tasks. We need to verify that the combination of rules data and structure works, e.g. the the rules are consistent and complete –This can be accomplished by executing the model to be sure that it runs properly –In a sense we are debugging the architecture –Any errors found must be corrected in the appropriate static views to preserve traceability

74 © A. H. Levis INCOSE L EXECUTION OF THE MODEL TO VERIFY ITS LOGIC A single thread is tested in the model and each step of the execution is examined to ensure that the model is following the logic desired. Any flaws will result in either an incorrect response or a deadlock The execution should match the dynamics model

75 DRIVER ARRIVES L

76 DRIVER PRESENTS FASTPASS L

77 VALIDATING CREDIT L

78 AUTHORIZATION RETURNED L

79 CREDIT VALIDATED DISPLAY SAYS START PUMPING L

80 DRIVER STARTS PUMPING L

81 DRIVER FINISHES PUMPING L

82 RECEIPT PRINTED; FINANCIAL TRANSACTION INITIATED L

83 DRIVER LEAVES; BANK TRANSACTION RETURNED L

84 NO MORE ENABLED TRANSITIONS L

85 © A. H. Levis INCOSE L BEHAVIORIAL EVALUATON We now know that the executable model runs. We know that the rules, structure, and data logically work together. Next we can examine the behavior of the architecture; this is an examination of the functionality of the architecture The behavior of the executable model and the dynamics model should correlate The behavior evaluation has several facets: –Does the architecture produce all the correct output for a given stimulus? –Does the information arrive at the right functions in the right sequence, I.e., are the inputs processed in the required way? The behavior of the architecture can be compared to the users requirements

86 © A. H. Levis INCOSE L TECHNIQUES FOR BEHAVIOR EVALUATION Simulation –The behavior of the architecture can be examined by running the executable model in simulation with inputs consistent with the operational concept State Space Analysis –Colored Petri Nets in general (and Design/CPN in particular) allow behavioral properties to be verified by analysis without resorting to simulation –The technique can compliment the multiple running of the model in simulation to reveal overall properties –These techniques can reveal dead locks (conditions in which the architecture stops executing), infinite cycles (generally not desirable) and maximum number of tokens (queues) that can occur in any place in the architecture.

87 OCCURRENCE GRAPH OF FASTPASS State space analysis tool of Design/CPN Verifies behavior –No undesired dead locks –Single Final State means consistent behavior State Transition L

88 © A. H. Levis INCOSE L OBSERVATIONS Some behavioral evaluation can be accomplished using an executable model derived only from the functional (or operational) architecture view. –Single stimulus/response analysis can show that the architecture does what it is supposed to. –Once the architecture has the desired behavior for single stimulus/response it can be evaluated with abnormal behaviors on the part of the external systems. This can reveal errors/omissions in the model. Additional behavioral evaluation can be accomplished with some aspects of the physical architecture are included. –Processors, communications links, etc. may effect the behavior of the architecture (e.g. sequencing of events) –The impact of time delays and processing times can be evaluated


Download ppt "© A. H. Levis INCOSE L. 4 - 1 C4ISR ARCHITECTURES AND THEIR IMPLEMENTATION CHALLENGES LECTURE 4 A C4ISR ARCHITECTURE FRAMEWORK IMPLEMENTATION PROCESS CASE."

Similar presentations


Ads by Google