SDM 5001 SYSTEMS ARCHITECTURE

LECTURE 3
SYSTEMS ARCHITECTURE CREATION AND DESIGN

© LGChan
SDM 5001 SYSTEMS ARCHITECTURE

LECTURE 3.1
CREATING A SYSTEMS ARCHITECTURE

To create architecture is to put in order.

Put what in order? Function and objects
Le Corbusier © LGChan
 Architecture Form
Form

Functions
Analysis of Systems Creation of
Architecture Functions Systems
(Reverse Architecture
Engineering) Requirements (Forward
Engineering)
Processes
Viewpoints

Operands/
Stakeholders
Elements

3
© LGChan
 Stakeholders

needs
Requirements

satisfies

Elements Form
comprises decides

values
Economics
interact maps

Processes Functions
perform

Systems Architecture
Engineering
Design

4
© LGChan
Creation of Systems Architecture is an Iterative Process

comprises
Elements Form

interact maps

perform
Processes Functions

Systems Architecture Engineering

Feedback Loop in Design

Design of Form

5
© LGChan
Feedback Loop Creation of Systems
Stakeholders

needs
Economics
Requirements Feedback Loop

satisfies

decides

values
Economics

Systems Architecture

6
© LGChan
OVERVIEW OF CREATION PROCESS

7
© LGChan
Scope of Activities in Creating Systems Architecture
1. Elicitation from Stakeholders
Define the architecture purpose, value, constraints, and decisions it will
support
2. Needs and Requirements
Obtain system requirements in order to define and identify architectural
viewpoints
3. CONOPS
Create the Concept of Operations
4. Viewpoints
Identify upstream and downstream views of stakeholders
5. Functional Analysis
Logical sequencing/interaction of functions or logical elements
6. Partitioning
Determine functions and decompose/layer into models and subsystems
7. Functional Allocation
Allocate functionality to models, interfaces, subsystems
Mapping and allocating physical architecture to functional architecture
using specifications in technical architecture
8
© LGChan
Scope of Activities in Creating Systems Architecture
8. Architecture Creation
Analyze and Evaluate the Architecture
9. Iteration
Refine, update and evaluate alternative design solutions in an iterative
way throughout various viewpoints
10. Integration
Integrate the selected architectural solutions (architecture descriptions)
into an architecture framework
11. Architecture Description
Document and Maintain the Architecture
12. Technical Performance Measures
Ensure system integrity and consistently during implementation and
quality of the system to be delivered
13. Validation and Verification
Establish traceability between requirements and system elements
Ensure solution meets client requirements

9
© LGChan
 Iteration
Architectural View 3

Architectural View 2

Architectural View 1

Elicitation Analysis Functional

Architecture
SA View 3
SA View 2
Needs Operational Architecture Architecture
Requirements Systems Architecture Description Framework
Architectural
Views

Physical
Partition Testing
CONCOPS Architecture
Validation

Integrate

Systems Architecture

10
© LGChan
IN THE BEGINNING …

11
© LGChan
 What I want the systems to do ? Need/Requirements to Functions
What results/ Results/Performance to Goals
performance to obtain?

System Architect role is to

Stakeholders need to
interpret and satisfy the
articulate what they want
stakeholders by designing
from the system
a system architecture

Elicitation is soliciting, collecting and exploring requirements from stakeholders

o Interviews, focus groups, Delphi techniques, questionnaires, user observation, workshops,
brainstorming, use cases, role playing
o Early prototyping : realistic user interaction, discovery, and feedback, understanding of requirements
o Quality Function Deployment (QFD) – a design tool use to understand user requirements and systems
functionality

12
© LGChan
 Needs and Requirements
Needs and Requirement
Requirements provide an overall view of the purpose and mission of the system

Two Types of Requirements

a) Stakeholders requirements and business or mission requirements
b) System requirements, which describe the functions which the system as a whole
should fulfill in order to satisfy the stakeholder requirements and are expressed in an
appropriate set of viewpoints, and non-functional requirements expressing the
required levels of safety, security, reliability, etc.

Viewpoints
o Use appropriate architecture views for various stakeholders in creating systems
architecture because their requirements and needs may be different

Classification of Needs - MOSCOW How to translate

oMust Have o requirements to functions?

Should Have o
Could Have
o Would Not Have

13
© LGChan
 Establishing Goals with Problem Statement
Problem Statement
Problem statement defines the boundary and clarifies the requirements of the systems

To … [achieve a solution goal] …

By …. [performing a function}
Using … [a form]
Example: To [solve traffic congestion] by [limiting number of cars] using [COE pricing]

The problem statement is revised several times to make requirements and goals clearer

Problem
Statement
Elicitation
Requirements
Identify
Requirements and
Goals
Requirements
Analysis Systems
Architecture 14
© LGChan
 Concept of Operations
Concept of Operations (CONOPS) describes
o systems properties of the system from a user's perspective
o high level mapping of function to form as a way to conveniently and concisely
visualize the systems (without too much details)

How to find out the Concept?

o Who are the stakeholders
o What are the desired functions to satisfy requirements
o What are internal processes to enable these functions

CONCOPS Diagram
conceptual description of the systems
(preliminary functional block diagram or
operational architecture) which shows
top-level functions in the proposed
systems definition of critical, top-level,
performance requirements or objectives
US Customs CONOPS

15
© LGChan
Iridium Satellite Phone Concept of Operations

16
© LGChan
 A Framework to Build Functions and Forms
Example: Urban Transportation System
Problem
Society Needs: People need to travel everyday - go to work, school, shopping, leisure
Expected Results: Good Service - Transport, Regular, Fast, Comfortable, Reasonable Price

Factors General Problem Specific Problem

Viewpoint? Users of Transport Worker in CBD Location
Beneficiary? People, Worker, Children Companies and Businesses
Need? Work, study, relax, social Regular, fast, comfortable, reasonable price
Operand Element? Commuters Office and sales workers
Value Attribute? Quality of Life Punctual on time, comfortable
Process? Travelling Moving from home to CBD building
Process Attribute? Mobility Speed, Regular
Concept? People Mover Fast Transport, Slow Transport
Form? Public, Private Transport Public: Train, Bus, Taxi
Private: Car, Bicycle, Legs

17
© LGChan
 Functional Analysis

Functional analysis is the systematic process of identifying, describing, and

relating the functions a system must perform in order to be successful

Functional Analysis Tools

o Functional Analysis System Technique (FAST)
o Visual layout (Tree Diagram) of a Product Functions
o Starts with the Basic Function, and builds to the right with supporting or
Secondary Functions
o Functional Flow Block Diagrams (FFBDs)
o Use to show the sequence of all functions to be accomplished by a system

18
© LGChan
Construct FAST Diagram Left to Right, and Check it Right to Left

Ask How? Secondary Function

Secondary Function

Basic Function
Secondary Function
Secondary Function
OR logic
AND logic
Secondary Function Ask Why?

Process of FAST Construction:

o Identify what you think is the Basic Function
o Ask the question: “How is this Function actually accomplished?”
Place Secondary Functions to the right of the Basic Function
o Check the FAST diagram by starting at the right and working left
Ask the question: “Why must this Function be performed?”

19
© LGChan
 Example : FAST Diagram for a Pencil

Display
Information

Improve

The System
Ask How?
Appearance

Record Produce Deposit Apply Support Protect

Information Marks Medium Pressure Lead Wood

Keep Maintain Secure Transmit Accommodate

Records Information Eraser Force Grip

Correct Remove Absorb Apply

Objective Information Marks Medium Pressure

Rub Ask Why?

Eraser

20
© LGChan
 Example: Functional Analysis of a Mouse Trap

Ask Why?

Attract Bait Trap

Mouse

Objective
Set Trigger

The System
Kill Strike Release Trip Arm
Mouse Mouse Striker Trigger Trap

Position
Ask How? Striker

Release Store Compress

Energy Energy Spring

21
© LGChan
 Functional Allocation
Functional Allocation
o Assignment or matching of functions in functional architecture to components (physical or
process) in physical architecture to enable the transformation of input to output
o Mapping of functional architecture with physical architecture is made possible with technical
architecture (based on technical specifications)

Mapping Functional Architecture with Physical Architecture

o Identify Relationships of properties of components with functions
o Match of interfaces based on relationships between functional architecture and physical
architecture
o Use specifications and standards with well documented interface properties
Function 1 System 1

Function 2 Subsystem 2
Functional A Physical Ar
Architecture rchitecture
Component 3
Function 3

Component 4 22
© LGChan
 Decomposition, Allocation, and Integration

Complex
Systems

Subsystems Subsystems Subsystems

1 2 3

Functional Allocation Systems Design and

Integration

Functional Physical
Architecture Architecture

Functional Functional Functional Physical Physical Physical

Architecture 1 Architecture 2 Architecture 3 Architecture 1 Architecture 2 Architecture 3

Allocation of Function with Interface

Physical Forms Mapping with Physical Forms

23
© LGChan
AN EXAMPLE
CREATING A CAR SYSTEM ARCHITECTURE

24
© LGChan
Elicitation: A car manufacture wants to design a car for field engineers
User Needs: Going to Office and Site to Meet Clients
Expectations: Safe, Comfortable, Punctual

Factors Brief
Viewpoint? Executive Engineer
Beneficiary? Employee, Employer, Clients
Need? Safe, Comfortable, Punctual
Operand Element? Transport Vehicle
Value Attribute? Convenience
Process? Travelling Moving from home to Office and Client Office
Process Attribute? Available 24-7
Concept? Private transport
Form? Car

Problem Statement: To [travel to office and site] by [driving] using [own car]
25
© LGChan
 office

Concept of Operations home

comfort = inside car

control = turning

construction site

safety = stop/go

26
© LGChan
 Example of Automobile Architecture
Functional Requirements
o Main Function: drive car (driving + car)
o Sub Function 1: motion (moving + car)
(abstract meaning for comfortable journey)
o Sub Function 2: safety (protecting + driver)
(abstract meaning for stop/go action)
o Sub Function 3: control (turning + car)
(abstract meaning for turn left, right, or go straight so as
to arrive on time using shortest route)

Main Function
Functional Architecture Drive Car

Sub Function 1 Sub Function 2 Sub Function 3

Motion Safety Control
(move) (protect) (turn) (Processes)

27
© LGChan
Functional Allocation
3 Sub Functions are allocated to Subsystems:
o Propulsion Subsystem
o Stop/Go Subsystem
o Steering Subsystem

Sub Systems Analysis

Functions of Subsystems can also be assigned to Physical Forms or Components
which enable these functions

28
© LGChan
 Mapping Functions to Forms

Sub Function 1 Sub Form 1

Motion Propulsion Subsystem Engine
Main Function
Drive Car

Integrate

Main Form
Sub Function 2 Sub Form 2

Car
Safety Stop/Go Subsystem Brakes

Sub Function 3 Sub Form 3

Control Steering Subsystem Steering

Functional Architecture Technical Specifications/ Physical Architecture

Architectural Framework

29
© LGChan
Systems Interactions
Engine Brakes Steering
Motion X
Safety Engine Brake? X
Control (Turn) No Stunt? X

Propulsion Subsystem

Car Systems Interfaces

System

Steering Subsystem Stop/Go Subsystem

30
© LGChan
OPERATIONAL ARCHITECTURE

31
© LGChan
 Operational Architecture
Operational Architecture is a high level description of the technical implementation of the tasks
and activities of the operational elements and quantity and quality of information flows required
to support the operation of the systems

How to Use?

How it Works?

Why it Works?

Who are the Users?

DoDAF Operational Architecture of Enterprise

32
(Source: Wikipedia http://en.wikipedia.org/wiki/Operational_View ) © LGChan
 Operational Feasibility

Systems will perform in operation as intended in an

effective and efficient manner in response to the
stakeholders requirements and usage

Requirements for feasibility are expressed in a number of

“ilities” that often showed up after a system has been put
to its initial use

33
(Ref: de Weck 2011 Engineering Systems-Meeting Human Needs in a Complex Technological World Cambridge MA MIT Press) © LGChan
 Operational Feasibility of Systems Architecture
“ilities” Requirements Example:
Bread Machine
Quality systems is well made and able to achieve its function and Make good to eat bread
performance
Reliability ability of systems to perform under a variety of circumstances, Portable machine can be
including the ability to deliver desired functions under various taken anyway, and operating
environment, uses, or internal variations temperature

Safety free from accidents or unacceptable losses No electrical shock

No burn bread
Flexibility systems capable of undergoing different types of changes with Can bake many types of
relative ease bread
Usability how effectively end users can operate, learn, or control the Easy 3 button control menu
system
Adaptability ability of systems to change internally to fit changes in its Easy to replace parts
environment, usually by self-modification to the system itself
Scalability ability of a system to maintain its performance and function Able to bake many bread
retain its desired properties when its scale is increased without sizes
causing a corresponding increase in systems complexity

34
Ref: de Weck 2011 Engineering Systems-Meeting Human Needs in a Complex Technological World Cambridge MA MIT Press © LGChan
 Good Operational Architecture 1

Loose Coupling between Systems

o Systems can be altered without the changes necessarily affecting other functions
Example: plug and play, where systems are so independent that they can be changed without
affecting the overall system behaviour
o Optimal coupling reduces the interfaces of modules and the resulting complexity of the
system

Tight Cohesion within Modules

o A module with high degree of cohesion is preferred because it has simple interfaces and less
complex architecture structure
o It is easier to isolate problems and make maintenance simple
Example: a module that performs a single function (one-to-one functions) has a high cohesion,
whereas a low cohesion module (one-to-many functions) which perform multiple tasks makes
repair more difficult because of interactions between sub-systems

35
© LGChan
 Good Operational Architecture 2

Modularity of components
o Systems boundaries are aligned to generic functionality, commercial standards and market-
leading component systems wherever possible
o Makes individual systems easier to build and maintain, encourages interoperability and eases
the difficulty of modifying parts
Example: using a common Technical Reference Model for design

Partitioning (Decomposition)
o Separate architecture between more volatile fast-moving system elements (uncertain) and
more stable and long-lasting ones (typically infrastructure)
Example of IT: procuring communications and common support as a service, while allowing
more agile and hands-on approaches at the applications levels
Example of Physical Systems such as aircraft and cars: design physical platform in such a way
as to allow incorporation of multiple generations of electronic and computing subsystems
over system or product lifetime. This allows adaption to later changes in context of use.
36
© LGChan
 Good Operational Architecture 3

Composability Design
o Allowing systems to be put together in the most number of operational configurations, largely
as a response to future uncertainty
Example: planning for flexibility in performance of systems in a number of possible missions
and technical configurations at design stage

Interfaces
o These must be identified and agreed – technically and contractually – and rigorously tested

Documentation
o Record systems architecture and re-use successful design patterns for future designs

37
© LGChan
END OF LECTURE 3.1
CREATING SYSTEMS ARCHITECTURE

38
© LGChan
SDM 5001 SYSTEMS ARCHITECTURE

LECTURE 3.2
SYSTEMS ARCHITECTING

© LGChan
 Two Primary Methods of Systems Architecting
Structured Analysis Design Technique
oGraphical Representation of System Requirements
o Blocks/Boxes and Arrows
o Functional/Process Flows
o IDEF (Integrated Definition for Function Modeling)

Object-Oriented Analysis (OOA), Unified Modeling Language(UML), SysML

oStructure Diagrams o
Behaviour Diagrams o
Interaction Diagrams
o Model Based Systems Engineering
SDM 5010

2
(Ref: http://yourdon.com/strucanalysis/wiki/, http://en.wikipedia.org/wiki/Structured_analysis )
© LGChan
SYSTEMS ARCHITECTING PROCESS

3
© LGChan
 System Architecting Process Model
Systems Architecture View
Scoping and Planning

Functional Analysis Elicitation

Parallel
Development of Problem Solution
Problem and Structuring Structuring Synthesis
Solution

Core Architecture
Harmonization Analysis

Selection-Integration Decision Making

Architecture Description

Can you see the difference

between System Architecting
Supporting Analysis
and System Engineering?

Parallel Development of Problem and Solution

Core architecting is repeated for various problems and viewpoints with the same or
different models to create a set of architecture descriptions of the project

4
(Adapted from Reichtin Maier (2009) The Art of Systems Architecting 3 rded Chapter 9 Boca Raton: CRC Press)
© LGChan
EXAMPLE
SYSTEMS ARCHITECTING PROCESS OF A PRODUCT
NEW PRODUCT CREATION

5
© LGChan
 Product Design Process

Elicitation CONOPS Functional Architecting Integration TPM Document

Requirements views Allocation

Why What How/ How Well Verify / Select

6
(Source: Muller , Gerrit (2011) Systems Architecting: A Business Perspective CRC Press, Ulrich, K.; Eppinger,S. (1995) Product Design and Development. NY McGraw Hill) © LGChan
 Product Architecture Process
Architecting details

Synthesis
Requirements/ Design, Select
Specifications Analyze, Production
Integrate
Verify
Design

(Source: Muller , Gerrit (2011) Systems Architecting: A Business Perspective CRC Press) 7
Ulrich, K.; Eppinger,S. (1995) Product Design and Development. New York McGraw Hill) © LGChan
EXAMPLE
SYSTEMS ARCHITECTING PROCESS IN AN ORGANIZATION

8
© LGChan
 Systems Architecting an Organization
Business model representation as a system is decomposed to four components
Problem + Solution + Program + Organization
Components Scope
Problem What are organization requirements?
How to add values in organization?
How do we get there in future?
Solution What is the proposed system in future?
What components are required?
How to measure the success?
Program Who are implementers?
What technology and processes are used?
Organization What are its goals and mission?
What is its business strategy?

9
(Ref: Maier, M. W., & Rechtin, E. (2009). The Art of Systems Architecting, Third Edition 3ed. Boca Raton: CRC Press. Chapter 12
© LGChan
 Systems Architecting Process in an Organization
Organization Executive Domain
Architecting of Organization

Program Extended Concerns

of Architecting

Organizational
Strategic Identity and
Management

Solution Problem Core Concerns of

Systems Architecting

Problem and solution components are core activities in system architecting

It is an iterative process in finding the best system to satisfy the requirements of the organizational plans
Both problem and solution activities are running simultaneously and provide feedback for better problem solving

Output of problem-solution is a program of system architecture for development of the organization

Program is to implement the system architecture in the organization using the solutions obtained previously

The Organization sets the goals, values, and future direction 10

© LGChan
 System Architecting Process in 3G SAF
1. Establish Objectives for Systems
Share Architecting and Measure of
Establish SA Objectives & MOE
experience Effectiveness (Technical Performance
and Design Inputs

knowledge Design Inputs Measurement)

Create Framework

Experience of
Build the Big Picture
2. Create the Framework:
experts,
builders, and Key Decision
identify the enablers and constraints
practitioners- Makers and
Identify Capability Gaps – Red Team
Operations Stakeholders
Technology
3. Build the Big Picture:
Leverage
construct solution with building blocks
Plug the Gaps
Dialogue/ and components
Engagement
Synthesis of SA
Consistent & 4. Identify Credibility Gaps:
Acceptance
Monitor, Test, Review
weaknesses and omissions
Demonstrable & Buy In

5. Plug the Gaps:

adjustment or refinement to close gaps
DSTA 7-Step Process of System Architecting
What is the purpose of this 6. Synthesis of System Architecture:
System Architecture? documentation of solution

7. Monitor, Test, Review

11
© LGChan
 Summary
Systems Architecture
o An architecture defines structure and behaviour of the system
o An architecture is concerned with elements, processes, and interactions
o An architecture meets stakeholder needs and is influenced by its environment
o An architecture conforms to an architectural style based on systems view/modelling
o An architecture influences organizational structure
o An architecture embodies decisions based on rationale systems thinking

Scope of Architecting
o Uses a combination of rational and heuristic processes
o Design Rules are used in technical design

Architecting Process Revolves Around Views / Models

o Composed of elicitation, requirements, partitioning, views, allocation mapping,
aggregation/ integration, certification
o Iterative process

Uncertainty
o Inherent in complex systems design
o Use tools and heuristics to reduce uncertainty (eg real options, flexibility) 12
© LGChan
END OF LECTURE 3.2
SYSTEMS ARCHITECTING

13
© LGChan
 SDM 5001 SYSTEMS ARCHITECTURE

LECTURE 3.3
SYSTEMS ARCHITECTING METHODOLOGIES

© LGChan
 Systems Architecting Tools
Systems engineering tools are used for different activities of systems architecting

what activities are performed

Process Standards EIA 632 ISO 15288 IEEE 1220 CMMI

describes the architecture

Architecture Frameworks FEAF DOAF MODAF Zachman FW

how activities are performed

Modeling Methods Hatley OOSE SADT Others
Pirbhai
functional /executable models Modelica Simulation
MathML
and Analysis HLA
Modeling & Simulation Standards IDEF0 SysML UPDM

System Modeling
how info is exchanged between models
Interchange & Metamodeling Standards MOF QVT XMI STEP/AP233

This lecture:
o ANSI/GEIA EIA-632 Processes for Engineering a System
o Hartley Pribadi (HP)
o SysML (ver 1.3 2012)
o Department of Defence Architectural Framework (DoDAF Version 2 )
2
© LGChan
PROCESS STANDARDS

3
© LGChan
 Systems Engineering Process Standard EIA 632

EIA 632
Describes the Activities
in Systems Engineering

Example:
INCOSE 2000 Framework for the Application of
ANSI/EIA-632 Systems Engineering in the Commercial Aircraft Design
INCOSE HANDBOOK
4
© LGChan
 Integrated Architecting Methodologies
Integrated Architecting Methodology
A systems architecting method which incorporates and integrates the multi architectural views to
achieve consistency and integrity in the system architecture
o Example:
Boeing 767 aircraft requires more passengers seats and longer flying distance
However, a larger aircraft consumes more fuel and reduces distance travelled
To reconcile these two conflicting views, an integrated architecting method is used to
manage a trade off between a more fuel economy jet engine or a powerful jet engine

Advantages of using Integrated Architecting Methodology

o Reduces redundant system models by specifying relevant models to be used in system design
o Minimizes errors in systems architecting (through omissions)
o Provides more robust and holistic systems architecture

5
© LGChan
INTEGRATED MODELING METHODS

6
© LGChan
 Hatley-Pirbhai (H/P) Method
H/P integrated modelling method is a tool for creating systems architecture
It can link both hardware and software systems in the systems architecting
It is used in a real time, reactive system which senses and reacts to events in the physical world
Applications: automobile, military avionics, manufacturing robots, vending machines

H/P method defines a system through two primary models:

o behavioral model (Requirements Model)
o model of form (Architecture Model)

Ref: Hatley D, Pirbhai, I (1988) Strategies for Real Time System Specification. Dorset House, New York 7
Ref: Hatley D, Hruschka, Pirbhai (2000) Process for System Architecture and Requirements Engineering. Dorset House, New York © LGChan
 Hatley-Pirbhai Architecture Model
o 6-block functional architecture of a generic system or high level function
o Requirements Model is embedded, and part, of the Architecture Model

User Interface Processing

Requirements
Model
Input Output
Processing Process Processing
Model

Control
Flow Model

Schematic
Diagram of Maintenance,
H/P Model Self Test,
Redundancy

8
© LGChan
 Hatley-Pirbhai Process Control Model
Decision
Table List of
Internal
Input Processed Output Signals
Process
Model List of
Internal Event Logic 1
Signals

Process Data
Activators Conditions
Event Logic 2
List of List of
Events Events

List of State
Control Flow
Input Transition
Model
Signals Diagram

Control Control
Outputs Inputs List of Actions
Action Logic

Requirements Model List of State Machine in Control

Input Flow Model
Signals

9
© LGChan
 Hatley-Pirbhai Component Blocks in Model
User Interface Processing
o Requesting/obtaining user input
o Provide user interface and feedback
o Provide outputs
o Respond to queries
Inputs Processing
o Formats and Receive inputs from sources external to function (non-human)
o Process inputs into a form usable by the function
Process Model
o Transformation of the data info inputs to functional outputs
Control Flow Model
o Control activation or order of sub-processes
Output Processing
o Process output to form usable by external interfaces
o Format Outputs and Provide output to the interfaces
Maintenance, Self Test, Redundancy
o Support the primary functionality of the system or function

10
© LGChan
 Hatley-Pirbhai Method Example 1
Architecture Diagram for Coin Operated Drink Machines
User Interface Processing
Display Panel

Function and Control Processing

Coins Select Drink
Insert - Count Coins
Input
Processing - Display Coins
Output - Reject Coins
Process Model Processing
Coins - Return Coins
Coin Coin - Drink Number
Exchange
Counter Counter Coins - Dispense Bottle
Control
Drink Flow Model
Selection
Drink Dispense
Drink Bottle
Number Bottle
No Bottles
Reports
Maintenance, Self Test,
Redundancy

11
Ref: Hatley D, Pirbhai, I (1988) Strategies for Real Time System Specification pg 202, 69 Dorset House, New York © LGChan
 Hatley-Pirbhai Method Example 2
o Architecture Diagram for Automobile Management Systems
o Similar diagrams can be constructed for various viewpoints (data flow and interfaces)

User Interface Processing

(Driver Car Panel)

Function and
Status Driver
Display Feedback
Control Processing
Input
Processing
Output
Process Model Processing
(Engine)
Engine
Status
(Brake) Throttle
(Adjust Fuel
Brake Control Drive
Injection)
Status Flow Model
(Power)
Gear
Status Faults
Reports
Maintenance, Self Test,
Redundancy

12
Ref: Hatley D, Pirbhai, I (1988) Strategies for Real Time System Specification pg 202, 69 Dorset House, New York
© LGChan
SYSTEMS MODELING

13
© LGChan
 SysML
Systems Modeling Language (SysML) is a general-purpose modeling standard for Model Based
Systems Engineering (MBSE) (http://www.sysml.org)

Systems Engineering activities supported includes specification, requirements, functional analysis

and allocation, design, verification and validation of a broad range of systems and systems-of-
systems

What is SysML:
1. Modeling Language
a) Diagramming (not a programming language) – SysML is an extension of UML
2. Modeling Method
a) Capability to create static and dynamic models of systems architecture
b) Enables software/hardware design systems and facilitates top-down approach of traditional systems
engineering
3. Modeling Tool
a) Facilitates management of system engineering

14
Optional Online Video : Introduction to Systems Modeling Language (SysML) Part 1 © LGChan
 SYSML Basic Diagrams
SysML are grouped in four functional areas
o 4 Pillars (most commonly used diagrams in SysML):
Requirements, Structure, Parametric Models, Allocation
o Each group (pillar) is implemented using SysML diagrams
o Groups also interact with each other to provide a cohesive
architectural model

SysML
Diagram

Behavior Requirement Structure

Diagram Diagram Diagram

Activity Sequence State Use Case Block Def Internal Parametric Package
Diagram Diagram Machine Diagram Diagram Block Diag Diagram Diagram

15
© LGChan
 SysML Software

Plug In: Free Online: Free Open Source: Propertiary:

Microsoft Visio draw.io Modelio Enterprise Architect
Papyrus-Eclipse Magic Draw 16
© LGChan
ARCHITECTURAL FRAMEWORK

17
© LGChan
 Architectural Framework
Architecture Framework
o set of standards that prescribes a structured approach, products, and principles for developing a
system architecture
o reference model to organize the various elements of the architecture of a system into
complementary and consistent predefined views allowing to cover all the scope of Systems
Architecture (SEBOK Part 3)
o established common practice for creating, interpreting, analyzing and using architecture
descriptions within a particular domain of application or stakeholder community (ISO/IEC/IEEE
42010 Conceptual Model of Architecture Description)
o skeletal structure that defines suggested architectural artifacts, describes how those artefacts are
related to each other, and provides generic definitions for what those artefacts might look like

Examples of Common Architectural Frameworks

o Defence Framework: US DoD Architecture Framework (DoDAF), United Kingdom’s Ministry of
Defence Architecture Framework (MODAF)
o Non-Defence Framework: The Open Group Architecture Framework (TOGAF), Zachman
Framework

18
© LGChan
 DoDAF Architecture Framework

Department of Defence Architecture Framework

o industry-standard Enterprise Architecture Framework for defence and
aerospace applications
o organize the specification of enterprise architectures for US
Department of Defence (DoD) applications
o well suited to large systems and systems-of-systems (SoS) with
complex integration and interoperability issues
o can be used in commercial systems and military defence framework,
and service-oriented architectures

Reference:
DoDAF Version 2.02 http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf
Optional Online Video : Demystifying DoDAF 2.02 - What Is An Architecture Framework? 19
© LGChan
 DoDAF Viewpoints
The DoDAF framework is divided into 3 groups of viewpoints:
o First group (blue) consists of four viewpoints that describe the overall system and its environment:
capability, operational, services, and systems
o Second group (beige) consists of the underlying principles, infrastructure, and standards: all data
and information and standards
o Third group (green) is a single viewpoint focusing on the system development project
o Within each viewpoint, additional set of views or models is defined
A total of 52 views or models are organized within the 8 (eight) viewpoints
For each view, a variety of methods and techniques are available to represent the view
T b D
O e
cA Capability Viewpoint
v A cs c e
e
e rt D hr articulates the capability requirements, delivery p
i
g p n aac
nt i a r
r i
s cuat
a c ci timing, and deployed capability ab i
b
i mi b ie
r
c rulaa a ut
h.
i.
n tc et t an
l a, l t l ls
g u c na eo d S at Operational Viewpoint it p t i
a e e dr h p Ian y
s s dI n n e rl ey th
re eA s tp Articulate operational scenarios, processes, m
p l n ai n d l m
n n qu r P
a e
lcl tf a ru c d i activities & requirements a eti alo re
at ta o in s aard Sgdetr i
etsV err h
trl tb
oi e sye y e . m n ect oj
t f ew alm Services Viewpoint s m
, Articulate performers, activities, and the exchanges t Des
o p , e eenh
ra Oa providing for, or supporting, DoD functions mn
a o V t
ct at t
a
n p
Systems Viewpoint t a is p V is
io
r n n b ew i
l p asl a
r Articulate legacy systems, or independent systems,
o
c dd d
their composition, interconnectivity, and context ee t
l dc i e
lvchp o teso
in ih e ew
o , rf y a providing for, or supporting, DoD functions D t w
ei t ei i cin rs ph
wcn tp e ip t ss e e e e o p
t f
n
. e sn e raontn i
d e v
u
tt
u r a V n caanoo enop 20
e a
r sd A ceui ei © LGChan
n
 DoDAF Viewpoints
The DoDAF framework is divided into 3 groups of viewpoints:
o First group (blue) consists of four viewpoints that describe the overall system and its environment:
capability, operational, services, and systems
o Second group (beige) consists of the underlying principles, infrastructure, and standards: all data
and information and standards
o Third group (green) is a single viewpoint focusing on the system development project
o Within each viewpoint, additional set of views or models is defined
A total of 52 views or models are organized within the 8 (eight) viewpoints
For each view, a variety of methods and techniques are available to represent the view
Capability Viewpoint

Describes the relationships between operational and

being implemented. Details dependencies between
Technical, and Industry policy, standard, guidance,
articulates the capability requirements, delivery

capability management and Defense Acquisition

capability requirements and the various projects

Overarching aspects of architecture context that

Articulate the data relationship and alignment

Articulate applicable, Operational, Business,

Data and Information Viewpoint
timing, and deployed capability
structures in the architecture content

Operational Viewpoint

Standard Viewpoint
constraints, and forecasts
Articulate operational scenarios, processes,

Project Viewpoint
activities & requirements
All Viewpoint

System process.
relate to all view

Services Viewpoint
Articulate performers, activities, and the exchanges
providing for, or supporting, DoD functions

Systems Viewpoint
Articulate legacy systems, or independent systems,
their composition, interconnectivity, and context
providing for, or supporting, DoD functions

21
© LGChan
DoDAF 6-Step Systems Architecting Process

Iteration 22
© LGChan
 Architectural Description
Definition
Architecture Description refers to artifacts (things) used to express and
document the reasoning, procurement, development, construction, and
operation of architectures
An architectural description can be a physical model, written report, data flow
block diagram, or set of procedures

23
(Source: HP -Sections of an architecture document) © LGChan
 Summary of Systems Architecting Methodology
Process Standard (EIA 632)
o describes what activities are required for systems engineering
Integrated Modeling Method (Hatley Prihai)
o method and tool for creating systems architecture
Standard Modeling (SysML)
o standard and visual format of models representing the systems
Architectural Framework (DoDAF)
o standard procedures and template (cookie cutter) for systems architecting and
architectural description
what activities are performed
Process Standards EIA 632 ISO 15288 IEEE 1220 CMMI
describes the architecture
Architecture Frameworks FEAF DOAF MODAF Zachman FW

how activities are performed

Modeling Methods H Pirbhai OOSE SADT Others

functional /executable models System Modeling Modelica Simulation

MathML
and Analysis HLA
Modeling & Simulation Standards IDEFO SysML UPDM

how info is exchanged between models

Interchange & Metamodeling Standards MOF QVT XMI STEP/AP233
24
© LGChan
END OF LECTURE 3.3
SYSTEMS ARCHITECTING METHODOLOGIES

25
© LGChan
Military Aircraft Systems Architectures
International Space Station Systems
Stokman Boyle Bacon 2010_International Space Station Systems
Engineering Case Study
http://www.lboro.ac.uk/media/wwwlboroacuk/content/systems-
net/downloads/pdfs/International%20Space%20Station%20Systems%20Engineering%20Case%20Study.pdf

Global Hawk Unmanned Air Vehicle (UAV) Systems

Kinzig MacAulay-Brown 2010_Global Hawk Systems Engineering
Case Study
http://www.lboro.ac.uk/media/wwwlboroacuk/content/systems-net/downloads/pdfs/GLOBAL HAWK
SYSTEMS ENGINEERING CASE STUDY.pdf

A-10 Thunderbolt II (Warthog) Systems

Jacques Strouble 2010_A-10 Thunderbolt II (Warthog) Systems
Engineering Case Study
http://www.lboro.ac.uk/media/wwwlboroacuk/content/systems-net/downloads/pdfs/A-10
Thunderbolt II (Warthog) SYSTEMS ENGINEERING CASE STUDY.pdf

B 2 Bomber Systems
Griffin Kinnu Colombi 2007_B 2 Bomber Systems Engineering
Case Study
http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA464771

26
© LGChan