You are on page 1of 77

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

Functons
Anal Creaton of
ysisArchitecture
of Systems Functons Systems
(Reverse Architecture
Engineering) Requirements (Forward
Engineering)
Processes
Viewpoints

Operands/
Elements Stakeholde
rs

3
© LGChan
Stakeholders

needs
Requirements

satisfies

Elements Form
comprise decides
s

values
Economics
interac maps
t
Processes Functons
perform

Systems Engineering
Architecture Design

4
© LGChan
Creaton of Systems Architecture is an Iterative Process

comprise
Element s For
s m
interac maps
t
perform
Processes Functon
s

Systems Engineering

Feedback Loop in Architecture Design

Design of Form

5
© LGChan
Feedback Loop Creaton of Systems
Stakeholders

needs
Economics
Requirements Feedback Loop

satisfies

decides

values
Economics

Systems
Architecture
6
© LGChan
OVERVIEW OF CREATION
PROCESS

7
© LGChan
Scope of Activites in Creatng 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 Activites in Creatng 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
Iteraton
Architectural View 3

Architectural View 2

Architectural View 1

Elicitaton Analysis Functional


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

Physical
Parttion Testng
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


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

Elicitaton is soliciting, collectng and exploring requirements from stakeholders


o Interviews, focus groups, Delphi techniques, questonnaires, user observaton,
workshops, brainstorming, use cases, role playing
o Early prototyping : realistc user interacton, discovery, and feedback, understanding of
requirements
o Quality Functon Deployment (QFD) – a design tool use to understand user requirements and
systems functonality
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

Classifcaton 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 functon} Using…
[a form]
Example: To [solve traffic congeston] by [limitng number of cars] using [COE pricing]
Problem
Statement and goals
The problem statement is revised several tmes to make requirements
Elicitaton
Requirements
clearer
Identfy
Requirements and
Goals
Requirements
Analysis Systems
Architecture 14
© LGChan
Concept of Operations
Concept of Operations (CONOPS) describes
o systems propertes of the system from a user's perspectve
o high level mapping of functon 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 functons to satsfy requirements
o What are internal processes to enable these functons

CONCOPS Diagram
conceptual descripton of the systems
(preliminary functonal block diagram or
operatonal architecture) which shows
top-level functions in the proposed
systems definiton of critcal, top-level,
performance requirements or
objectves US Customs CONOPS

15
© LGChan
Iridium Satellite Phone Concept of Operations

16
© LGChan
A Framework to Build Functions and Forms
Example: Urban Transportaton
System
Society Needs: People need to travel everyday - go to work, school, shopping, leisure
Problem
Expected Results: Good Service - Transport, Regular, Fast, Comfortable, Reasonable
Price
Factors General Problem Specific Problem
Viewpoint? Users of Transport Worker in CBD Locaton
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 tme, 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 systematc process of identfying, describing, and


relatng the functons 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 supportng
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 Lef

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 Identfy what you think is the Basic Functon
o Ask the queston: “How is this Functon actually
accomplished?”
Place Secondary Functions to the right of the Basic Function
o Check the FAST diagram by startng at the right and working
lef Ask the queston: “Why must this Functon be performed?”
19
© LGChan
Example : FAST Diagram for a Pencil

Display
Information

Ask How? Improve

The System
Appearanc
e

Record Produce Deposit Apply Support Protect


Information Marks Medium Pressure Lead Wood

Keep Maintain Secure Transmi Accommodate


Records Information Eraser t Force Grip

Correct Remove Absorb Apply


Objectve Information Marks Medium Pressure

Rub Ask Why?


Eraser

20
© LGChan
Example: Functional Analysis of a Mouse Trap

Ask
Why?

Attract Bait Trap


Mouse

Objectve
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
Functonal Allocaton
o Assignment or matching of functons in functonal architecture to components (physical
or process) in physical architecture to enable the transformaton of input to output
o Mapping of functional architecture with physical architecture is made possible with
technical
architecture (based on technical specificatons)

Mapping Functonal Architecture with Physical Architecture


o Identfy Relatonships of propertes of components with functons
o Match of interfaces based on relatonships between functional architecture and physical
architecture
o Use specificatons and standards with
Function 1 well documented interface
System 1 propertes

Function 2 Subsystem 2
Functonal
PPhhyyssii
AArrcchhiitte Component 3
ccaall
eccttuurree Function 3
AArrcchhiitte
Component 4 22
© LGChan
Decomposition, Allocation, and Integration

Complex
Systems

Subsystem Subsystem Subsystem


s1 s2 s3

Functonal Allocaton Systems Design and


Integraton

Functonal Physical
Architecture Architectur
e

Functonal Functonal Functonal Physical Physical Physical


Architecture Architecture Architecture Architecture 1 Architecture 2 Architecture 3
1 2 3
Allocaton of Functon Interface
with Physical Forms Mapping with Physical Forms

23
© LGChan
AN EXAMPLE
CREATING A CAR SYSTEM
ARCHITECTURE

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

Factors Brief
Viewpoint? Executve 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
ofice

Concept of Operatons 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: moton (moving + car)
(abstract meaning for comfortable journey)
o Sub Functon 2: safety (protectng + driver)
(abstract meaning for stop/go acton)
o Sub Functon 3: control (turning + car)
(abstract meaning for turn lef, right, or go straight so as
to arrive on tme using shortest route)

Main Function
Functonal Architecture Drive Car

Sub Functon 1 Sub Functon 2 Sub Functon 3 (Processes)


(move) (protect) (turn)
Moton Safety Control

27
© LGChan
Functional Allocaton
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 Functon 1 Sub Form 1


Motion Propulsion Subsystem Engine
Main Functon
Drive Car

Integrate

Main Form
Sub Functon 2 Sub Form 2

Car
Safety Stop/Go Subsystem Brakes

Sub Function 3 Sub Form 3


Control Steering Subsystem Steering

Functonal Architecture Technical Specifcatons/ Physical


Architectural Architecture
Framework

29
© LGChan
Systems
Engine Brakes Steering
Interactions
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
Operatonal Architecture is a high level description of the technical implementaton of the tasks
and actvities of the operatonal elements and quantty and quality of informaton flows
required to support the operaton of the systems

How to Use?

How it

Works? Why

it Works?

Who are the


Users?

DoDAF Operational Architecture of


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

Systems will perform in operation as intended in


an effective and effcient 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 © 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
environment, uses, or internal variations operating 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 © 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
affectng 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

Parttoning (Decompositon)
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

Documentaton
o Record systems architecture and re-use successful design paterns 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 Elicitaton


Parallel
Development Problem Solution
Structuring Structuring
of Problem and Synthesis
Soluton

Architecture
Harmonization Analysis

Core
Selection-Integration Decision Making

Architecture Description

Can you see the difference


between System Architecting
Supporting Analysis
and System Engineering?

Parallel Development of Problem and Soluton


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

4
(Adapted from Reichtin Maier (2009) The Art of Systems Architecting 3 rd ed 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 + Soluton + Program + Organizaton
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 soluton components are core activites in system architectng


It is an iteratve process in fnding the best system to satsfy the requirements of the organizatonal plans
Both problem and soluton activities are running simultaneously and provide feedback for better problem
solving

Output of problem-soluton is a program of system architecture for development of the organizaton


Program is to implement the system architecture in the organization using the solutons obtained previously
10
The Organizaton sets the goals, values, and future directon © LGChan
System Architecting Process in 3G SAF
1. Establish Objectives for Systems
Share Architectng and Measure of
Establish SA Objectives & MOE
experience Effectveness (Technical
and Design Inputs

knowledge Design Inputs Performance Measurement)


Create Framework

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

5. Plug the Gaps:


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

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

Architectng 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 12
o © 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 activites 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 and
MathML
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 Activites
in Systems Engineering

Example:
INCOSE 2000 Framework for the Applicaton of
ANSI/EIA-632 Systems Engineering in the Commercial Aircraft
INCOSE HANDBOOK Design
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 aircraf requires more passengers seats and longer flying distance
However, a larger aircraft consumes more fuel and reduces distance travelled
To reconcile these two conflictng views, an integrated architectng 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 architectng (through omissions)
o Provides more robust and holistc 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, reactve 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 © LGChan
Hatley-Pirbhai Architecture Model
o 6-block functonal architecture of a generic system or high level
functon
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

Schematc
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 Transitio
Model
Signals n
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


Coins Select Drink Insert
Processing
Input
Processing - Count Coins
Output - Display Coins
Process Model Processing
Coins - Reject Coins
Coin Coin - Return Coins
Exchange
Counter Counter - Drink Number
Coins
Control
- Dispense Bottle
Drink Flow Model
Selecton
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 © 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
Control Processing
Input
Processing Feedback
Output
Process Model Processing
(Engine)
Engine
Status
Throttle
(Brake) (Adjust Fuel
Brake Control Drive
Injecton)
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
© 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 activites 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 statc and dynamic models of systems architecture
b) Enables software/hardware design systems and facilitates top-down approach of traditonal 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 functonal 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

Actvity 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: Propertary: Enter


Microsof Visio draw.io Modelio prise 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 practce for creatng, interpretng, analyzing and using architecture
descriptions within a partcular domain of applicaton or stakeholder community
(ISO/IEC/IEEE 42010 Conceptual Model of Architecture Description)
o skeletal structure that defines suggested architectural artfacts, describes how those artefacts
are
related to each other, and provides generic definitons 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 applicatons
o organize the specificaton of enterprise architectures for US
Department of Defence (DoD) applicatons
o well suited to large systems and systems-of-systems (SoS) with
complex integraton 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 Framewor 19
k? © 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
T
are organized within the 8 (eight) viewpoints
Capability Viewpoint D
ForOeach view, a variety of methods and techniques are available
articulates the capability requirements,
to representb
cec
the
e
view
i
delivery timing, and deployed capability s anac
pgpr a
e

v A Operational Viewpoint i
Articulate operational scenarios,
cA iab
processes, activities & requirements
e rD hr t nt
bmbe
r i Services Viewpoint i
Articulate performers, activities, and the
exchanges providing for, or supporting, DoD
i functions i
Systems Viewpoint l
a sc
Articulate legacy systems, or independent ipls
at systems, their composition, interconnectivity, and i
context providing for, or supporting, DoD functions
t t
y
cc lyt
i 20
r u aut e h © 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
ForAll Dataa and
each view, varietyStandard
of methods and Capability Viewpoint
techniques Project Viewpoint
are available to represent the view
Viewpoint Information Viewpoint articulates the capability requirements, Describes the
Overarching Viewpoint Articulate delivery timing, and deployed capability relationships between
operational and
aspects of Articul applicable Operational Viewpoint capability
architecture ate , Articulate operational scenarios,
context that Operation requirements and the
the processes, activities & requirements
relate to all al, various projects
data Services Viewpoint being implemented.
view relatio Business,
Technical, Articulate performers, activities, and the Details dependencies
nship between capability
and exchanges providing for, or supporting, DoD
and management and
Industry functions
align Defense Acquisition
ment policy, Systems Viewpoint
standard, System process.
struct Articulate legacy systems, or independent
ures guidance, systems, their composition, interconnectivity, and
in the constraint context providing for, or supporting, DoD functions
archit s, and
ecture forecasts
conte
nt

21
© LGChan
DoDAF 6-Step Systems Architecting Process

22
Iteraton
© LGChan
Architectural Description
Definition
Architecture Description refers to artfacts (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 activites are required for systems engineering
Integrated Modeling Method (Hatley Prihai)
o method and tool for creatng systems architecture
Standard Modeling (SysML)
o standard and visual format of models representng the systems
Architectural Framework (DoDAF)
o standard procedures and template (cookie cuter) for systems architectng
and
architectural
what activities are performed descripton
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 and


MathML
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/Internatonal%20
Space%20Staton%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 HAW
K
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 Enginee
ring
Case Study 26
http://www.dtc.mil/cgi-bin/GetTRDoc?Locaton=U2&doc=GetTRDoc.pdf&AD=ADA464771
© LGChan