Lecture 3.pptx

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

Form

Architecture Form

ysisArchitecture of Systems (Reverse Engineering)

Functons

Creaton of Systems Architecture Requirements (Forward Engineering)

Anal Functons

Processes

Viewpoints Operands/ Elements

rs

Stakeholde

3 © LGChan

Stakeholders needs

Requirements satisfies

Elements

comprise s

interac t

Form

maps

Processes

perform

Systems Architecture

decides

values

Economics

Functons

Engineering Design

4 © LGChan

Creaton of Systems Architecture is an Iterative Process

Element s

comprise s

interac t

maps

Processes

Feedback Loop in Design of Form

For m

perform

Systems Architecture

Functon s Engineering Design

5 © LGChan

Feedback Loop Creaton of Systems Stakeholders needs

Requirements

Economics Feedback Loop

satisfies

decides

values

Economics

Systems Architecture 6 © LGChan

OVERVIEW OF CREATION PROCESS 7 © LGChan

Scope of Activites in Creatng Systems Architecture 1.

2.

3. 4. 5. 6. 7.

Elicitation from Stakeholders Define the architecture purpose, value, constraints, and decisions it will support Needs and Requirements Obtain system requirements in order to define and identify architectural viewpoints CONOPS Create the Concept of Operations Viewpoints Identify upstream and downstream views of stakeholders Functional Analysis Logical sequencing/interaction of functions or logical elements Partitioning Determine functions and decompose/layer into models and subsystems 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. 9.

10.

11. 12.

13.

Architecture Creation Analyze and Evaluate the Architecture Iteration Refine, update and evaluate alternative design solutions in an iterative way throughout various viewpoints Integration Integrate the selected architectural solutions (architecture descriptions) into an architecture framework Architecture Description Document and Maintain the Architecture Technical Performance Measures Ensure system integrity and consistently during implementation and quality of the system to be delivered 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 Needs Requirements

CONCOPS

Analysis

Functional Architecture

SA View 3 SA View 2

Operational Architecture

Systems Architectural Views

Parttion

Physical Architecture

Architecture Description

Architecture Framework

Testng Validation Integrate

Architecture

Systems 10 © LGChan

IN THE BEGINNING …

11 © LGChan

What I want the systems to do ? What results/ performance to obtain?

Stakeholders need to artculate what they want from the system

Need/Requirements to Functions Results/Performance to Goals

System Architect role is to interpret and satsfy the stakeholders by 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 oMust Have o Should Have o Could Have o Would Not Have

How to translate requirements to functions?

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 Systems Analysis 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: Problem Expected Results: Factors

People need to travel everyday - go to work, school, shopping, leisure Good Service - Transport, Regular, Fast, Comfortable, Reasonable Price 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

Record Information

Keep Records

Objectve

Produce Marks

Deposit Medium

Maintain Information

Apply Pressure

Secure Eraser

Correct Information

Remove Marks

Absorb Medium

Rub Eraser

Support Lead

Protect Wood

Transmi t Force

Accommodate

The System

Improve Appearanc e

Ask How?

Grip

Apply Pressure

Ask Why?

20 © LGChan

Example: Functional Analysis of a Mouse Trap Ask Why? Attract Mouse

Objectve

Set Trigger Strike Mouse

Release Striker

Trip Trigger

Arm Trap Position Striker

Ask How? Release Energy

Store Energy

The System

Kill Mouse

Bait Trap

Compress 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 Function with 1 well documented System interface 1 propertes Functonal

Function 2

PPhhyyssii

AArrcchhiitte eccttuurree

Subsystem 2 Component 3

Function 3 Component 4

ccaall AArrcchhiitte

22 © LGChan

Decomposition, Allocation, and Integration Complex Systems

Subsystem s1

Subsystem s3 Systems Design and Integraton

Functonal Allocaton

Functonal Architecture

Functonal Architecture 1

Subsystem s2

Functonal Architecture 2

Physical Architectur e

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

23 © LGChan

AN EXAMPLE CREATING A CAR SYSTEM ARCHITECTURE 24 © LGChan

Elicitaton: User Needs: Expectatons:

A car manufacture wants to design a car for field engineers Going to Office and Site to Meet Clients 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: o Sub Function 1: o Sub Functon 2: o Sub Functon 3:

drive car (driving + car) moton (moving + car) (abstract meaning for comfortable journey) safety (protectng + driver) (abstract meaning for stop/go acton) control (turning + car) (abstract meaning for turn lef, right, or go straight so as to arrive on tme using shortest route)

Functonal Architecture Sub Functon 1 (move) Moton

Main Function Drive Car

Sub Functon 2 (protect) Safety

Sub Functon 3 (turn) Control

(Processes)

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

Sub Functon 2 Safety Sub Function 3 Control

Functonal Architecture

Propulsion Subsystem

Sub Form 1 Engine

Stop/Go Subsystem

Sub Form 2 Brakes

Steering Subsystem

Sub Form 3 Steering

Technical Specifcatons/ Architectural Framework

Main Form Car

Main Functon Drive Car

Sub Functon 1 Motion

Integrate

Mapping Functions to Forms

Physical Architecture

29 © LGChan

Systems Interactions

Engine

Brakes

Motion

X

Safety

Engine Brake?

X

Control (Turn)

No

Stunt?

Steering

X

Propulsion Subsystem

Car System

Steering Subsystem

Systems Interfaces

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?

(Source: Wikipedia

DoDAF Operational Architecture of Enterprise http://en.wikipedia.org/wiki/Operatonal_View

32 © 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

(Ref: de Weck 2011 Engineering Systems-Meeting Human Needs in a Complex Technological World Cambridge MA MIT

33 © LGChan

Operational Feasibility of Systems Architecture “ilities” Quality Reliability

Safety Flexibility Usability Adaptability Scalability

Requirements

Example: Bread Machine

systems is well made and able to achieve its function and performance ability of systems to perform under a variety of circumstances, including the ability to deliver desired functions under various environment, uses, or internal variations

Make good to eat bread

free from accidents or unacceptable losses

No electrical shock No burn bread Can bake many types of bread Easy 3 button control menu

systems capable of undergoing different types of changes with relative ease how effectively end users can operate, learn, or control the system ability of systems to change internally to fit changes in its environment, usually by self-modification to the system itself ability of a system to maintain its performance and function retain its desired properties when its scale is increased without causing a corresponding increase in systems complexity

Portable machine can be taken anyway, and operating temperature

Easy to replace parts Able to bake many bread sizes

Ref: de Weck 2011 Engineering Systems-Meeting Human Needs in a Complex Technological World Cambridge MA MIT

34 © 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

(Ref: http://yourdon.com/strucanalysis/wiki/, http://en.wikipedia.org/wiki/Structured_analysis

2 © LGChan

SYSTEMS ARCHITECTING PROCESS 3 © LGChan

System Architecting Process Model Systems Architecture View

Functional Analysis

Parallel Development of Problem and Soluton Core Architecture

Problem Structuring

Solution Structuring

Harmonization

Selection-Integration

Scoping and Planning

Elicitaton

Synthesis

Analysis Decision Making

Architecture Description

Supporting Analysis

Can you see the difference between System Architecting 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 (Adapted from Reichtin Maier (2009) The Art of Systems Architecting 3 rd ed Chapter 9 Boca Raton: CRC Press)

4 © LGChan

EXAMPLE SYSTEMS ARCHITECTING PROCESS OF A PRODUCT NEW PRODUCT CREATION 5 © LGChan

Product Design Process

Elicitation Requirements

Why

CONOPS views

What

Functional Allocation

Architecting Integration

How/ How Well

TPM

Document

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/ Specifications

Design, Analyze, Integrate

(Source: Muller , Gerrit (2011) Systems Architecting: A Business Perspective CRC Press) Ulrich, K.; Eppinger,S. (1995) Product Design and Development. New York McGraw Hill)

Select Production Verify Design

7 © 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 Problem Solution Program Organization

Scope What are organization requirements? How to add values in organization? How do we get there in future? What is the proposed system in future? What components are required? How to measure the success? Who are implementers? What technology and processes are used? 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 The Organizaton sets the goals, values, and future directon

10 © LGChan

System Architecting Process in 3G SAF Share experience and knowledge Experience of experts, builders, and practitionersOperations Technology

Establish SA Objectives & MOE Design Inputs

Design Inputs

Create Framework Build the Big Picture

Key Decision Makers and Stakeholders

Identify Capability Gaps – Red Team Leverage Plug the Gaps Synthesis of SA

Monitor, Test, Review

DSTA 7-Step Process of System Architecting What is the purpose of this System Architecture?

Dialogue/ Engagement Consistent & Acceptance Demonstrable & Buy In

1. Establish Objectives for Systems Architectng and Measure of Effectveness (Technical Performance Measurement) 2. Create the Framework: identfy the enablers and constraints 3. Build the Big Picture: construct soluton with building blocks and components 4.

Identfy Credibility Gaps: weaknesses and omissions

5. Plug the Gaps: adjustment or refnement to close gaps 6. Synthesis of System Architecture: documentaton of soluton 7. Monitor, Test, Review

11 © LGChan

Systems Architecture

Summary

o o o o

An architecture defines structure and behaviour of the system An architecture is concerned with elements, processes, and interactions An architecture meets stakeholder needs and is influenced by its environment 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 o

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 activites of systems architecting what activities are performed Process Standards

describes the architecture

Architecture Frameworks

EIA 632

ISO 15288

IEEE 1220

FEAF

DOAF

MODAF

Hatley Pirbhai

OOSE

SADT

IDEF0

SysML

UPDM

how activities are performed

Modeling Methods

functional /executable models

Modeling & Simulation Standards

CMMI Zachman FW

Others Modelica Simulation and MathML Analysis

HLA

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

ANSI/EIA-632 INCOSE HANDBOOK

Example: INCOSE 2000 Framework for the Applicaton of Systems Engineering in the Commercial Aircraft 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 Ref: Hatley D, Hruschka, Pirbhai (2000) Process for System Architecture and Requirements Engineering. Dorset House, New

7 © 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

Input Processing

Process Model

Output Processing

Requirements Model

Control Flow Model Schematc Diagram of H/P Model

Maintenance, Self Test, Redundancy

8 © LGChan

Hatley-Pirbhai Process Control Model Decision Table Input

Processed Output

Process Model

Process Activators

List of Internal Signals Data Conditions

Control Flow Model Control Outputs

List of Internal Signals

Control Inputs

Requirements Model

Event Logic 2

Event Logic 1

List of Events

List of Events

State Transitio n Diagram

List of Input Signals

Action Logic

List of Input Signals

List of Actions

State Machine in Control Flow Model 9 © LGChan

Hatley-Pirbhai Component Blocks in Model User Interface Processing o o o o

Requesting/obtaining user input Provide user interface and feedback Provide outputs Respond to queries

Inputs Processing o Formats and Receive inputs from sources external to function (nonhuman) 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

Coins Select Drink Insert Input Processing Coins

Drink Selecton

Output Processing

Process Model Coin Counter

Coin Counter

Exchange Coins

Control Flow Model

Function and Control Processing - Count Coins - Display Coins - Reject Coins - Return Coins - Drink Number - Dispense Bottle

Dispense Drink Bottle Bottle

Drink Number 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)

Status Display Feedback

Input Processing (Engine)

(Brake) (Power)

Function and Control Processing

Driver Output Processing

Process Model Engine Status Brake Status Gear Status

Control Flow Model

Throttle Drive

(Adjust Fuel Injecton)

Faults Reports Maintenance, Self Test, Redundancy

Ref: Hatley D, Pirbhai, I (1988) Strategies for Real Time System Specification pg 202, 69 Dorset House, New

12 © 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

Optional Online Video : Introduction to Systems Modeling Language (SysML) Part 1

14 © 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 Diagram

Actvity Diagram

Sequence Diagram

State Machine

Requirement Diagram

Use Case Diagram

Block Def Diagram

Structure Diagram

Internal Block Diag

Parametric Diagram

Package Diagram

15 © LGChan

SysML Software

Plug In: Microsof Visio

Free Online: draw.io

Free Open Source: Modelio Papyrus-Eclipse

Propertary: Enter prise Architect Magic Draw

16 © LGChan

ARCHITECTURAL FRAMEWORK

17 © LGChan

Architectural Framework Architecture Framework

like

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

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 k?

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 T D Capability Viewpoint b ForOeach view, a variety of methods and techniques are available to represent the view e cec articulates the capability requirements, delivery timing, and deployed capability e

e

Operational Viewpoint

A

v

Articulate operational scenarios, processes, activities & requirements

cA hr t nt

rD

r

i

Services Viewpoint

i

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

a

at

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

i

s anac pgpr a i iab bmbe i

i l ipls

i t

t

y cc r

u

aut

i

e

lyt

20

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 Dataa and Project Viewpoint Capability Viewpoint ForAll each view, varietyStandard of methods and techniques are available to represent the view Describes the articulates the capability requirements, Viewpoint Information Viewpoint Overarching Viewpoint Articulate aspects of architecture context that relate to all view

Articul ate the data relatio nship and align ment struct ures in the archit ecture conte nt

applicable , Operation al, Business, Technical, and Industry policy, standard, guidance, constraint s, and forecasts

delivery timing, and deployed capability

Operational Viewpoint Articulate operational scenarios, processes, activities & requirements

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

relationships between operational and capability requirements and the various projects being implemented. Details dependencies between capability management and Defense Acquisition System process.

21 © LGChan

DoDAF 6-Step Systems Architecting Process

Iteraton

22 © 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 descripton what activities are performed Process Standards

describes the architecture

Architecture Frameworks

how activities are performed

Modeling Methods

functional /executable models

Modeling & Simulation Standards

EIA 632

ISO 15288

IEEE 1220

FEAF

DOAF

MODAF

H Pirbhai

OOSE

SADT

IDEFO

System Modeling SysML

UPDM

MOF

QVT

XMI

CMMI Zachman FW

Others Modelica Simulation and MathML Analysis

HLA

how info is exchanged between models Interchange & Metamodeling Standards

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/A10 Thunderbolt II (Warthog) SYSTEMS ENGINEERING CASE STUDY.pdf

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

26 © LGChan