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

2. 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. 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. STAGE 1 (A1) C4ISR Architecture Framework Elements, Organizations,
Connections
Analyze
Operational
Operational
Concept
(AV1 and D1)
Concept
A11
Create
High Level
Operational
Concept
High Level Operational
Concept Graphic (OV1)
Graphic
Graphic
A12
Text
Create
Textual
Description
A13

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

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

7. 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. 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
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
Financial Institution
Driver
Operate FastPass
GasStation System
Validate
Operate
Pre
pare
Accounts
Pump
Billing
Retrieve
Sense
Validate
Request
Print
Update
Driver
FastPass
Receipt
Credit
Charge
Accounts
Information
Receive
Dispense
Compute
Authorization
Gas
Cost of
Sale

9. 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.
Organization
Assets
OilCo
FastPass Central Data Base
Gas Station
Pump, Gas, Ledger, Office Database
Financial Institution
Financial Account Database
Driver
FastPass Account, Credit Account, FastPass Device

10. 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 Node
Operational Elements
Driver
Gas Station
Pump, Gas Station Office
OilCo
Financial Institutions
Financial Institution

11. 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. Transition Description (OV6b )
STAGE 3
Textual Description of
Doctrine, Tactics and
Operational Procedures (D5)
Functional
Decomposition
(IP21)
Need Lines (IP-31)
Initial Physical
Architecture
(IP-32)
Develop
Activity
Model
A31
P. 6
Dynamics
A32
Determine
Need Lines
A36
Define
System
Nodes
A33
C4ISR Architecture Framework
Organizational
Intermediate
Products (IP-22)
Systems,
Elements,
and
Components
A34
Allocate
Activities
A35
P. 7
Define Links
A37
Systems/Functions
(D8)
System Descriptions
(D12)
Activity Model
Products
Operational State
Transition Description (OV6b )
Activity Allocations
(IP-33)
System Nodes
Elements, and
Links
Operational Elements
Operational Nodes
Operational Nodes and
Organizational Assets
and Nodes
States and Events
(D7)

13. 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. 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)
Perform
Driver
FastPass_Device
Authorization_Transaction
Activities
A-01
Operate
Display
Selection
FastPass
Financial_Transaction
System
Bank_Transaction A0
Receipt
Provide
Financial
Services
A-02
Purpose: To describe the operations of the Speed Pass System
View Point: System Architect

15. CONTEXT DIAGRAM
Easily derived if the External System Diagram is used

16. A0 DIAGRAM
Matches the Functional Decomposition

17. A1 DIAGRAM - VALIDATE ACCOUNTS

18. A2 DIAGRAM – OPERATE PUMP
Authorization_Transaction
Receive
Display
Authorization
Authorization_Transaction
A21
Dispense
“on”, grade, gallons
Gas
Dispensed_Gas_Data
Selection
A22
"off", grade, gallons
Compute
Cost of Sale
Gas_Pricing
Dispensed
A23
_Gas_Data

19. A3 DIAGRAM – PREPARE BILLING

20. LOGICAL DATA MODEL (IDEF1x) (OV-7)
FastPass_ID (FK)
SPEEDPASS_DEVICE 1
FastPass_ID
Name
Receipt_Option
Drive_Credit_Acct_Number (FK)
DRIVER_INFORMATION
Defines
Drive_Credit_Acct_Number
DRIVE_CREDIT-ACCOUNT
Quantity_Control
Grade
Transaction_Number (FK)
SELECTION
Cost_of_Sale
Date_Time (FK)
Gas_Station_Information (FK)
Quantity_Control (FK)
Grade (FK)
DISPENSED_GAS_DATA
Cost_of_Sale (FK)
RECEIPT
Used_to_compute
Used_For
Included-in
Display-ID
Display_Content
DISPLAY
Triggers
Date_Time
Gas_Station_Information
Pricing
GAS_PRICING
Used to Compute
Transaction_Number
FINANCIAL_TRANSACTION P
Transaction_Type
Approval
AUTHORIZATION_TRANSACTION
Enables
Required_For
Used_In
Provides_Data_For
BANK_TRANSACTION
Purpose: To describe the data structure of the Fast Pass System

21. 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. 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.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. 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. OPERATIONAL STATE TRANSITION DIAGRAM (OV-6b)
Start
OPERATIONAL STATE TRANSITION DIAGRAM (OV-6b)
car arrival
[Non FastPass
Driver]
Pump Is Idle
Car arrival[FastPass Driver] c
/Sense FastPass
Validating Credit
Credit
disapproved
Do: Retrieve Driver
Information, Validate
Credit
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
Credit approved
/Activate Pump
Dispensing Gas
Do: Dispense Gas
Finish Fueling/
Deactivate pump
Computing Cost of Sale
Do: Compute Cost of Sale
Receipt printed
Cost of Sales calculated
Printing Receipt
Do: Print Receipt

25. ALLOCATE ACTIVITIES
Decide which activities the operational elements you selected will perform the leaf activities of the functional decomposition
Operational Element
Activities
Financial Institution
(Update Account)
(Validate Credit)
Gas Station Office
Update Accounts
OilCo
Retrieve Driver Information
Pump
Sense FastPass
Request Charge
Receive Authorization
Dispense Gas
Print Receipt
Compute Cost of Sale
Validate Credit

26. SYSTEMS, ELEMENTS, AND FUNCTIONS
The following type of information is used to allocate operational activities to system functions S
ystem
Element
Functions
Driver
FastPass Tag
Provide FastPass Tag
Select Option
FastPass Sensor
Sense FastPass Tag and Decode
FastPass ID
Pump Control Unit
Control Operation Mode
Request Authorization
Request Charge
Message Display (at Pump)
Disp
lay Message
Receipt Printer
Print Receipt
Calculator
Compute Cost of Sale
Throttle Valve
Dispense Gas
Pump
Communication Unit
Receive/ Transmit Signal
Sales Database
Record Transaction
Gas Station Office
Database
Receive/ Transmit
Signal
FastPass Central Database
Retrieve Driver Information
FastPass Central
Database (OilCo)
Account Database
Issue Authorization
Manage Database
Financial
Institutions’
Receiv
e/ Transmit Signal

27. 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
Activities
System Functions
Sense FastPass
Prov
ide FastPass Tag
Sense FastPass Tag and Decode FastPass ID
Retrieve Driver Information
Retrieve driver Information
Validate Credit
Request Authorization
Display Message
Issue Authorization
Receive Authorization
Dispense Gas
Sense Selectio n
Compute Cost of Sale
Request Charge
Print Receipt
Update Account
Record Transaction
Manage Database

28. 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. 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. INITIAL PHYSICAL ARCHITECTURE
Driver
Radio link
Gas Station
Office Database
Pump
SpeedPass
Central Database
Lan
Wan
Wan
Financial
Institution
Database

31. STAGE 4 (A4) Define Operational Information Elements
Need Lines
(IP-31)
Initial Physical
Architecture
(IP-32)
Define
Operational
Information
Elements
A41
Create Operational
Node
Connectivity
Description
A42
Create
Exchange
Matrix
A43
Activity to System
Function Traceability
A44
Systems
Activity
Models
A45
P. 9
C4ISR Architecture Framework
Activity Allocations
Activity Model
Products
Activities vs
System
Functions
Logical Data Model
System Activity
Model Products
Operational Node
Connectivity Description (OV2)
Operation
Elements (IP-41)
Operational Information
Exchange Matrix (OV3)
Operational Activity to
System Function
Traceability Matrix (SV5)
Elements (D6)

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

33. 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 Data
Pump
Display
Authorization_Transaction (request)
Driver Information
OilCo
Grade of Gas (Selection)
Driver
FastPass Device
Quantity Control (Selection)
Receipt
Bank_Transaction (request)
FastPass ID

34. 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
Pump
OilCo
Activities
Retrieve Driver
Information
Gas Station Office
FastPass
Selection
Display
Receipt
FastPass ID
Driver Information
Dispensed
Gas_Data
Bank Transaction
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
(Validate Credit)
(Update Accounts)
Authorization_Transaction (Request)
Bank_Transaction (request)

35. 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. 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. CONTEXT DIAGRAM Financial Driver Institution Operate FastPass System
s Device
Authorization_Transa
ction
Financial
Driver
Selection
Bank_Transaction
Institution
Operate
Authorization_Transaction
Display
FastPass
System
Bank_Transaction
Receipt
Purpose: To describe the System Functions of the FastPass System
View Point: System Architect

38. DFD OF PUMP FUNCTIONS

39. 0 - DIAGRAM
Aggregate lower level pages to form 0 - Diagram

40. OPERATIONAL ACTIVITY TO SYSTEM FUNCTION TRACABILITY MATRIX (SV-5)
Documents operational activity allocation

41. PHYSICAL DATA MODEL (SV-11)
Specifies Messages, Data Store Records, Display Content, etc.

42. PHYSICAL DATA MODEL (CONT’D)

43. STAGE 5 COMPLETE SYSTEM ARCHITECTURE VIEW PRODUCTS
Descriptions (D12)
System Evolution
Description (SV8)
System Interface
Description (SV1)
Initial Physical
Architecture (IP-32)
Define
Information
Elements
A51
Communications
Systems
A53
P. 11
Create
Interface
Description
A54
Evolution
A55
Performance
Parameter Set
A56
Create System
Parameter
Matrix
A57
C4ISR Architecture Framework
System Activity
Model Products
Activity
Allocations (IP-32)
System Communications
Description (SV2)
System2 Matrix (SV3)
System Information
Exchange Matrix (SV6)
System Performance
Parameter Matrix (SV7)
Attributes (D10)
Migration
System (D11)
Exchange
A52
Operation
Elements (IP-41)
(IP- 51)
Operational Node Connectivity
Description (OV2)
Operational Information
Exchange Matrix (OV3)
Communication Systems
Description (D9)

44. 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. 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
Radio
link
Wan
56K/T -
1 Link
Lan
Gas Station
Pump
TCP/IP
FastPass Central
Office Database
Database
10 Mbps
TCP/IP
Wan
56K/T -
1 Link
TCP/IP
Financial
Institution
Database

46. 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. SYSTEM INTERFACE DESCRIPTION (SV-1)
Gas
Station
Office
Database
FastPass
Central T -
1 link
Banking
Support
Node
LAN
(10 Mbps,
TCP/IP)
56K link
Gas Station
FastPass Service
Pump
Financial Institutions
ATM Backbone
(TCP/IP)
Devi ce
Driver Node
Microwave

48. SYSTEM COMMUNICATIONS DESCRIPTION (SV-2)
Packet Switch (X.25)
ATM/Frame Relay
Router
56K
Ethernet
Gas Station
Office
Database
Financial
Institution
FastPass
Central
Terminal
Pump 1 T -
1 link
TCP/IP
Microwave
Device

49. SYSTEM2 MATRIX (SV-3) Driver Pump C1 M1 Gas Station Office Database
FastPass
Central
Financial
Institution
Status
Existing Interface S1
Security Classification
Public Key C1
Plain C2
Means
Radio M1
56 K link X.25 M2
T1 Link Frame Relay/ATM M3
10/100 MBPS LAN M4
S1 C1
M2, 3, 4
C1 M2, 3, 4
M2, 3, 4

50. SYSTEM INFORMATION EXCHANGE MATRIX (SV-6)

51. SYSTEM INFORMATION EXCHANGE MATRIX (CONT’D)
Note: This is not the complete matrix. The columns that specify the parameters of the system information elements have been omitted

52. SYSTEM PERFORMANCE PARAMETER MATRIX (SV-7)
Essential for Evaluation

53. SYSTEM EVOLUTION DESCRIPTION (SV-8)

54. SYSTEM TECHNOLOGY FORECAST (SV-9)
Area
& Capabilities -
6 Months 6 12
Months
18 Months
18+ Months
Security
Public key
algorithm
Distributed
Heterogeneous
Database
Middleware and/or proprietary
interface
Dynamic
active
DBMS
Satellite
Communication
World wide DAMA (Demand Access Multiple
Access) ground terminal migra
te into WAN
OilCo
Subscriber
Roaming
System wide roaming across the boundary of
home service area
International roaming
across the boundary of
domestic service area
Heterogeneous DBMS

55. OPERATIONAL ARCHITECTURE VIEW PRODUCTS

56. SYSTEM ARCHITECTURE VIEW PRODUCTS

57. 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. EXECUTABLE MODEL
SYNTHESIS OF EXECUTABLE MODEL FROM STRUCTURED ANALYSIS BASED ARCHITECTURE
(Demonstration)
LEE W. WAGENHALS
DAESIK KIM

59. 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. 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 t1 t2

61. CPN MODEL TOP LEVEL: CORRESPONDS TO CONTEXT DIAGRAM Controls Inputs
Outputs Do HS
CondAAW#3
Inputs
Scenario
Driver HS
Scenario#7
TOP LEVEL: CORRESPONDS TO CONTEXT DIAGRAM

62. EXTERNAL SYSTEM DIAGRAM
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
Purpose: To describe the operations of the FastPass System
View Point: System Architect

63. DESIGN/CPN CONTEXT DIAGRAM
Initial Marking
ColorSet
Place Name

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

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 L

66. DESIGN/CPN FIRST LEVEL DECOMPOSITION

67. DATA MODEL DEFINES COLORSETS
FastPass_ID (FK)
FASTPASS_DEVICE 1
FastPass_ID
Name
Driver_Credit_Acct_Number (FK)
DRIVER_INFORMATION
Defines
Driver_Credit_Acct_Number
DRIVER_CREDIT-ACCOUNT
Quantity_Control
Grade
Transaction_Number (FK)
SELECTION
Enables
Cost_of_Sale
Date_Time (FK)
Gas_Station_Information (FK)
Quantity_Control (FK)
Grade (FK)
DISPENSED_GAS_DATA
Cost_of_Sale (FK)
RECEIPT
Required_For
Used_to_compute
Used_For
Included-in
Display-ID
Display_Content
DISPLAY
Triggers
Approval
AUTHORIZATION_TRANSACTION
Status
BANK_TRANSACTION
Provides_info_to
Date_Time
Gas_Station_Information
Pricing
GAS_PRICING
Transaction_Number
FINANCIAL_TRANSACTION P
Transaction_Type
Used_in
Provides_data
Used_to_Compute
Purpose: To describe the data structure of the FastPass System

68. COLORSETS FROM ENTITIES
GLOBAL DECLARATION NODE
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;
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
DOMAINS
ATTRIBUTES

69. 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. 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
OUTPUTS
INPUTS
DRIVER ACTIONS L

73. 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. 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 FASTPASSL

77. VALIDATING CREDIT L

78. AUTHORIZATION RETURNEDL

79. CREDIT VALIDATED DISPLAY SAYS START PUMPING

80. DRIVER STARTS PUMPING L

81. DRIVER FINISHES PUMPINGL

82. RECEIPT PRINTED; FINANCIAL TRANSACTION INITIATED

83. DRIVER LEAVES; BANK TRANSACTION RETURNED

84. NO MORE ENABLED TRANSITIONS

85. 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 user’s requirements

86. 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
OCCURRENCE GRAPH OF FASTPASS
Transition
State space analysis tool of Design/CPN
Verifies behavior
No undesired dead locks
Single Final State means consistent behavior L

88. 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