Classification Of A System.pdf

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





Development speed





networked, fail safe, etc

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,  Examples:

a lifelong marriage

 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

Br

Ba

bang-bang

Acc

S

PID

actuators

Steps In Simulation and 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

Introduction

Model Building

25

Steps In Simulation and

26

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

Introduction

Model Building(cont’d)

Define An Achievable 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

Introduction

“To model the…” is NOT a goal!

27

Put together a complete 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)

Introduction

mix of skills on the team

28

Put together a complete 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)

Introduction

mix of skills on the team(continued)

29

INVOLVE THE END USER

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

Introduction

-Modeling is a selling job!

30

Choose The Appropriate Simulation Tools

1.

Build Model in a General Purpose

Language

2.

Build Model in a General Simulation

Language

3.

Use a Special Purpose Simulation

Package

Introduction

Assuming Simulation is the appropriate means, three alternatives exist:

31

MODELLING W/ GENERAL PURPOSE LANGUAGES 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

Introduction



32

GEN. PURPOSE LANGUAGES USED FOR 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

Introduction

SIMULATION

33

MODELING W/ GENERAL 

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

Introduction

SIMULATION LANGUAGES

34

GENERAL PURPOSE SIMULATION LANGUAGES 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

Introduction



35

GEN. PURPOSE SIMULATION LANGUAGES (continued) 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

Introduction



36

GEN. PURPOSE SIMULATION LANGUAGES (continued) 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

Introduction



37

MODELING W/ SPECIAL-PURPOSE SIMUL. PACKAGES 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)

Introduction



38

SPECIAL PURPOSE PACKAGES USED FOR SIMUL.

Introduction



NETWORK II.5

 Simulator for computer systems



OPNET

 Simulator for communication



networks, including wireless networks

COMNET III

 Simulator for communications networks



39

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 Customers with high priority are served first.

[18]

 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 Principal

Noise

Noise Seed

Sim Interest Average Interest Rate

Continuous and Stochastic

Estimated Interest Rate Continuous and Deterministic

3. Discrete and Continuous models



Discrete model: Bank Account Averaging time

Averaging time 0

Average Principal

Average Principal 0

Simulated Principal 1 0 Sim Interest 1 0 Observed Interest Rate 0

Sim Interest 1 <TIME STEP>

<Time>

Discrete and Deterministic

Simulated Principal 1 <TIME STEP>

Observed Interest Rate

<Time>



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