Classification of Systems

Physical or AbstractSystem

 Physical systems are tangible entities that we can feel and touch. These may be static or dynamic in nature. For

example, take a computer center. Desks and chairs are the static parts, which assist in the working of the center.

Static parts don't change. The dynamic systems are constantly changing. Computer systems are dynamic

system. Programs, data, and applications can change according to the user's needs.

 Abstract systems are conceptual. These are not physical entities. They may be formulas, representation or

model of a real system.

Openor ClosedSystem

 Systems interact with their environment to achieve their targets. Things that are not part of the system are
environmental elements for the system. Depending upon the interaction with the environment, systems can be
divided into two categories, open and closed.

 Open systems: Systems that interact with their environment. Practically most of the systems are open systems.
An open system has many interfaces with its environment. It can also adapt to changing environmental
conditions. It can receive inputs from, and delivers output to the outside of system. An information system is an
example of this category.

 Closed systems: Systems that don't interact with their environment. Closed systems exist in concept only.
Man made Information System

 The main purpose of information systems is to manage data for a particular organization. Maintaining files,
producing information and reports are few functions. An information system produces customized information
depending upon the needs of the organization. These are usually formal, informal, and computer based.

 Formal Information Systems: It deals with the flow of information from top management to lower management.
Information flows in the form of memos, instructions, etc. But feedback can be given from lower authorities to
top management.

 Informal Information systems: Informal systems are employee based. These are made to solve the day to day
work related problems. Computer-Based Information Systems: This class of systems depends on the use of
computer for managing business applications. These systems are discussed in detail in the next section.
 http://www.freetutes.com/systemanalysis/classifications-of-system.html
Types of Models

 There are many different types of models expressed in a diverse array of modeling languages and tool sets.

This article offers a taxonomy of model types and highlights how different models must work together to support

broader engineering efforts.
Model Classification

 There are many different types of models and associated modeling languages to address different aspects of a

system and different types of systems. Since different models serve different purposes, a classification of

models can be useful for selecting the right type of model for the intended purpose and scope.
Formal versus Informal Models
 Since a system model is a representation of a system, many different expressions that vary in degrees of formalism could be
considered models. In particular, one could draw a picture of a system and consider it a model. Similarly, one could write a
description of a system in text, and refer to that as a model. Both examples are representations of a system. However, unless
there is some agreement on the meaning of the terms, there is a potential lack of precision and the possibility of ambiguity in
the representation.
 The primary focus of system modeling is to use models supported by a well-defined modeling language. While less formal
representations can be useful, a model must meet certain expectations for it to be considered within the scope of 
model-based systems engineering (MBSE). In particular, the initial classification distinguishes between informal and formal
models as supported by a modeling language with a defined syntax and the semantics for the relevant domain of interest.
Physical Models versus Abstract Models

 The United States “Department of Defense Modeling and Simulation (M&S) Glossary” asserts that “a
model can be [a] physical, mathematical, or otherwise logical representation of a system” (1998). This
definition provides a starting point for a high level model classification. A physical model is a
concrete representation that is distinguished from the mathematical and logical models, both of which
are more abstract representations of the system. The abstract model can be further classified as
descriptive (similar to logical) or analytical (similar to mathematical). Some example models are
shown in Figure 1.
 Descriptive Models

 A descriptive model describes logical relationships, such as the system's whole-part relationship that defines its parts tree, the
interconnection between its parts, the functions that its components perform, or the test cases that are used to verify the system 
requirements. Typical descriptive models may include those that describe the functional or physical architecture of a system, or the three
dimensional geometric representation of a system.

 Analytical Models

 An analytical model describes mathematical relationships, such as differential equations that support quantifiable analysis about the system
parameters. Analytical models can be further classified into dynamic and static models. Dynamic models describe the time-varying state of a
system, whereas static models perform computations that do not represent the time-varying state of a system. A dynamic model may
represent the performance of a system, such as the aircraft position, velocity, acceleration, and fuel consumption over time. A static model
may represent the mass properties estimate or reliability prediction of a system or component.

 Hybrid Descriptive and Analytical Models

 A particular model may include descriptive and analytical aspects as described above, but models may favor one aspect or the other. The
logical relationships of a descriptive model can also be analyzed, and inferences can be made to reason about the system. Nevertheless,
logical analysis provides different insights than a quantitative analysis of system parameters.
 Domain-specific Models

 Both descriptive and analytical models can be further classified according to the domain that they represent. The following classifications are
partially derived from the presentation on OWL, Ontologies andSysMLProfiles: Knowledge Representation and Modeling (Web Ontology
Language (OWL) & Systems Modeling Language (SysML)) (Jenkins 2010):

 properties of the system, such as performance, reliability, mass properties, power, structural, or thermal models;

 design and technology implementations, such as electrical, mechanical, and software design models;

 subsystems and products, such as communications, fault management, or power distribution models; and

 system applications, such as information systems, automotive systems, aerospace systems, or medical device models.

 The model classification, terminology and approach is often adapted to a particular application domain. For example, when modeling 
organization or business,thebehavioral model may be referred to as workflow or process model, and the performance modeling may refer
to the cost and schedule performance associated with the organization or business process.

 A single model may include multiple domain categories from the above list. For example, a reliability, thermal, and/or power model may be
defined for an electrical design of a communications subsystem for an aerospace system, such as an aircraft or satellite.
System Models

 System models can be hybrid models that are both descriptive and analytical. They often span several modeling
domains that must be integrated to ensure a consistent and cohesive system representation. As such, the
system model must provide both general-purpose system constructs and domain-specific constructs that are
shared across modeling domains. A system model may comprise multiple views to support planning,
requirements, design, analysis, and verification.

 Wayne Wymore is credited with one of the early efforts to formally define a system model using a mathematical
framework in A Mathematical Theory of Systems Engineering: The Elements (Wymore 1967). Wymore
established a rigorous mathematical framework for designing systems in a model-based context. A summary of
his work can be found in A Survey of Model-Based Systems Engineering (MBSE) Methodologies.
Simulation versus Model

 The term simulation, or more specifically computer simulation, refers to a method for implementing a model
over time (DoD1998). The computer simulation includes the analytical model which is represented in executable
code, the input conditions and other input data, and the computing infrastructure. The computing infrastructure
includes the computational engine needed to execute the model, as well as input and output devices. The great
variety of approaches to computer simulation is apparent from the choices that the designer of computer
simulation must make, which include

 stochastic or deterministic;

 steady-state or dynamic;

 continuous or discrete; and

 local or distributed.
 http://sebokwiki.org/wiki/Types_of_Models
 Heterogeneous Modeling and Design in

Ptolemy II

Johan Eker

UC Berkeley

with material courtesy of Edward Lee and the Ptolemy group

ECE Seminar Series, Carnegie Mellon, November 29, 2001

Ptolemy II

A Software Laboratory

Ptolemy II
– Java based

– Graphical modeling and simulation

environment

– Multiple “models of computation”

– Hierarchical & heterogeneous models

– Code generator

– Actor language
Outline

 Introduction

 Ptolemy II basics

 A motivating example

 Research Issues

 Summary
Embedded Systems

 Computers not thought of as computers

 Increasingly complex designs

 networked, fail safe, etc

 Development speed

 time to market

 Bugs, bugs, bugs

 hard to correct a released product

 don’t want to reboot your toaster

What is So Different With Embedded Software?

 Interaction with physical processes

sensors, actuators, processes
 Critical properties are not all functional
real-time, fault recovery, power, security, robustness
 Heterogeneous
hardware/software, mixed architectures
 Concurrent
interaction with multiple processes
 Reactive
operating at the speed of the environment
 Component Technology

 Examples: Java beans, VB-components, etc

 Rationale
 Encapsulation
 Reuse
 Divide complexity
 Successful in many areas
 Problems with concurrent components
 Threads are not components
 Priorities are global parameters
 Difficult to design embedded systems component with state-of-the art
technology
 Multipurpose tools

 Express almost anything, guarantee almost nothing

 You only need to knowoneprogramming language
 Quick starts, but sometimes slower endings
 Programmers+language, a lifelong marriage
 Examples:
 Java
 C/C++ with RTOS, ADA, Modula-2
 RMA & EDF scheduling
Sharpen your tools

 Use problem specific tools

 Constrain the solutions

 Choice of tools, a major design decision

 Combine several tools

Hierarchical, Heterogeneous Modeling and Design

leader follower

sensors
controller actuators

Br Acc

Ba S

bang-bang PID
Steps In Simulation and 25

Model Building

Introduction
1. Define an achievable goal

2. Put together a complete mix of skills on the team

3. Involve the end-user

4. Choose the appropriate simulation tools

5. Model the appropriate level(s) of detail

6. Start early to collect the necessary input data

Steps In Simulation and 26

Model Building(cont’d)

Introduction
7. Provide adequate and on-going documentation
8. Develop a plan for adequate model verification
(Did we get the “right answers ?”)
9. Develop a plan for model validation
(Did we ask the “right questions ?”)
10. Develop a plan for statistical output analysis
Define An Achievable Goal 27

Introduction
“To model the…” is NOT a goal!
“To model the…in order to select/determine feasibility/…
is a goal.

Goal selection is not cast in concrete

Goals change with increasing insight

Put together a complete 28

mix of skills on the team

Introduction
We Need:

-Knowledge of the system under investigation

-System analyst skills (model formulation)

-Model building skills (model Programming)

-Data collection skills

-Statistical skills (input data representation)

Put together a complete 29

mix of skills on the team(continued)

Introduction
We Need:

-More statistical skills (output data analysis)

-Even more statistical skills (design of experiments)

-Management skills (to get everyone pulling in the same direction)

INVOLVE THE END USER 30

Introduction
-Modeling is a selling job!

-Does anyone believe the results?

-Will anyone put the results into action?

-The End-user (your customer) can (and must) do all of the above BUT, first he must be convinced!

-He must believe it is HIS Model!

Choose The Appropriate Simulation Tools 31

Introduction
Assuming Simulation is the appropriate means, three alternatives exist:
1. Build Model in a General Purpose Language

2. Build Model in a General Simulation Language

3. Use a Special Purpose Simulation Package

MODELLING W/ GENERAL PURPOSE LANGUAGES 32

Introduction
 Advantages:
 Little or no additional software cost
 Universally available (portable)
 No additional training(Everybody knows…(language X) ! )
 Disadvantages:
 Every model starts from scratch
 Very little reusable code
 Long development cycle for each model
 Difficult verification phase
GEN. PURPOSE LANGUAGES USED FOR 33

SIMULATION

Introduction
FORTRAN
 Probably more models than any other language.
PASCAL
 Not as universal as FORTRAN
MODULA
 Many improvements over PASCAL
ADA
 Department of Defense attempt at standardization
C, C++
 Object-oriented programming language
MODELING W/ GENERAL 34

SIMULATION LANGUAGES

Introduction
 Advantages:
 Standardized features often needed in modeling
 Shorter development cycle for each model
 Much assistance in model verification
 Very readable code
 Disadvantages:
 Higher software cost (up-front)
 Additional training required
 Limited portability
GENERAL PURPOSE SIMULATION LANGUAGES 35

Introduction
 GPSS
 Block-structured Language
 Interpretive Execution
 FORTRAN-based (Help blocks)
 World-view:Transactions/Facilities
 SIMSCRIPT II.5
 English-like Problem Description Language
 Compiled Programs
 Complete language (no other underlying language)
 World-view:Processes/ Resources/ Continuous
GEN. PURPOSE SIMULATION LANGUAGES (continued) 36

Introduction
 MODSIM III
 Modern Object-Oriented Language
 Modularity Compiled Programs
 Based on Modula2 (but compiles into C)
 World-view:Processes
 SIMULA
 ALGOL-based Problem Description Language
 Compiled Programs
 World-view:Processes
GEN. PURPOSE SIMULATION LANGUAGES (continued) 37

Introduction
 SLAM
 Block-structured Language
 Interpretive Execution
 FORTRAN-based (and extended)
 World-view:Network / event / continuous
 CSIM
 process-oriented language
 C-based(C++ based)
 World-view:Processes
MODELING W/ SPECIAL-PURPOSE SIMUL. PACKAGES 38

Introduction
 Advantages
 Very quick development of complex models
 Short learning cycle
 No programming--minimal errors in usage
 Disadvantages
 High cost of software
 Limited scope of applicability
 Limited flexibility (may not fit your specific application)
SPECIAL PURPOSE PACKAGES USED FOR SIMUL. 39

Introduction
 NETWORK II.5
 Simulator for computer systems
 OPNET
 Simulator for communication networks, including wireless networks

 COMNET III
 Simulator for communications networks
 SIMFACTORY
 Simulator for manufacturing operations
Parallel Processing

 Parallel processing is a method of simultaneously breaking up and running program tasks on multiple

microprocessors, thereby reducing processing time. Parallel processing may be accomplished via a computer

with two or more processors or via a computer network.

 Parallel processing is also called parallel computing.

Models of Queuing Systems

 Discrete Simulation Models

 ModelTime

 Simulation Experiment Control

Queueingtheory

 Queueingtheory is the mathematical study of waiting lines, or queues. Aqueueingmodel is constructed so that

queue lengths and waiting time can bepredicted.Queueingtheory is generally considered a branch of 

operations research because the results are often used when making business decisions about the resources

needed to provide a service.

https://en.wikipedia.org/wiki/Queueing_theory
Basic

First in firstout

This principle states that customers are served one at a time and that the customer that has been waiting the

longest is servedfirst

Last in firstout

This principle also serves customers one at a time, but the customer with the shortest waiting time will be served
[18]
first.  Also known as a stack.

Processorsharing

Service capacity is shared equally between customers.

Priority

[18]
Customers with high priority are served first.  Priority queues can be of two types, non-preemptive (where a job in

service cannot be interrupted) and preemptive (where a job in service can be interrupted by a higher-priority job). No

work is lost in either model.

Shortest jobfirst

The next job to be served is the one with the smallestsize

Preemptive shortest jobfirst

The next job to be served is the one with the original smallest size
Discrete and Continuous Simulation
Marcio Carvalho

Luis Luna

PAD 824 – Advanced Topics in System Dynamics

Fall 2002
What is it all about?

 Numerical simulation approach

 Level of Aggregation

 Policies versus Decisions

 Aggregate versus Individuals

 Aggregate Dynamics versus Problem solving

 Difficulty of the formulation

 Nature of the system/problem

 Nature of the question

 Nature of preferred lenses

Basic concepts

1. Static or dynamic models

2. Stochastic, deterministic or chaotic models

3. Discrete or continuous change/models

4. Aggregates or Individuals
1. Static or Dynamic models

 Dynamic: State variables change over time (System Dynamics, Discrete Event, Agent-Based, Econometrics?)

 Static: Snapshot at a single point in time (Monte Carlo simulation, optimization models, etc.)
2. Deterministic, Stochastic or Chaotic

 Deterministic modelis one whose behavior is entire predictable. The system is

perfectly understood, then it is possible to predict precisely what will happen.

 Stochastic modelis one whose behavior cannot be entirely predicted.

 Chaotic modelis a deterministic model with a behavior that cannot be entirely

predicted
3. Discrete or Continuous models

 Discrete model: the state variables change only at a countable number of points in time. These points in time

are the ones at which the event occurs/change in state.

 Continuous: the state variables change in a continuous way, and not abruptly from one state to another

(infinite number of states).

3. Discrete or Continuous models

 Continuous model: Bank account

Principal
Interest

Observed
Interest Rate
Simulated
Noise Principal
Sim Interest

Average
Noise Seed
Interest Rate

Estimated
Interest Rate
Continuous and Stochastic

Continuous and Deterministic

3. Discrete and Continuous models

 Discrete model: Bank Account

Averaging
Averaging time
time 0
Average
Average Principal
Principal 0

Simulated Simulated
Principal 1 0 Principal 1
Sim Interest 1 0 Sim Interest 1
<TIME
STEP>
<TIME
Observed STEP>
Observed Interest Rate
Interest Rate 0 <Time>
<Time>

<Average
<Average <Noise> Interest Rate>
Interest Rate>

Discrete and Deterministic Discrete and Stochastic

4. Aggregate and Individual models

 Aggregate model: we look for a more distant position. Modeler is more distant. Policy model. This view tends

to be more deterministic.

 Individual model: modeler is taking a closer look of the individual decisions. This view tends to be more

stochastic.
The “Soup” of models

 Waiting in line

 Waiting in line 1B

 Busy clerk

 Waiting in line (Stella version)

 Mortgages (ARENA model)

Time handling

2 approaches:

 Time-slicing: move forward in our models in equal time intervals.

 Next-event technique: the model is only examined and updated when it is known that a state (or behavior)

changes. Time moves from event to event.

Alternative views of Discreteness

 Culberston’s feedback view

Yt at  ( g  g ' )Yt  1  ( d  d ' )(Yt  1  Yt  2 )

 TOTE model

(Miller, Galanter and Pribram, 1960)

Peoples thoughts

“The system contains a mixture of discrete events, discrete and different magnitudes, and continuous processes.

Such mixed processes have generally been difficult to represent in continuous simulation models, and the common

recourse has been a very high level of aggregation which has exposed the model to serious inaccuracy”

(Coyle, 1982)
Peoples thoughts

“Only from a more distant perspective in which events and decisions are deliberately blurred into patterns of

behavior and policy structure will the notion that ‘behavior is a consequence of feedback structure’ arise and be

perceived to yield powerful insights.”

(Richardson, 1991)
So, is it all about these?

 Numerical simulation approach

 Level of Aggregation

 Policies versus Decisions

 Aggregate versus Individuals

 Problem solving versus Aggregate Dynamics

 Difficulty of the formulation

 Nature of the system/problem

 Nature of the question

 Nature of preferred lenses