Systems Engineering for Intelligent Industrial Processes

discontinuities within the bandwidth. Therefore the ambiguity in the phase unwrapping is avoided. To experimentally test the method experiments were p...

0 downloads 133 Views 6MB Size
Systems Engineering for Intelligent Industrial Processes Jan van Deventer Thursday, January 28, 2016

Outline •

Definitions,



Systems Engineering standards & documentation,



System lifecycle management,



Model Based Systems Engineering,



SOA Framework to promote “Intelligence”.

my Background Why System Engineering?

IIP



Processes,



Industrial Processes,



Intelligent Industrial Processes.

Ultrasonic measurements and modelling of attenuation and phase velocity in pulp suspensions

Paper Production Process Jan Niemi∗ , Yvonne Aitom¨aki and Torbj¨orn L¨ofqvist Department of Computer Science and Electrical Engineering Lulea University of Technology, Sweden ∗ Email: [email protected]

When determining the phase velocity from pulse-echo measurements, one encounters the problem of performing a correct phase unwrapping. The problem is well known and has been addressed in earlier investigations, for instance [2]. The problem arises when the phase velocity is calculated from the phase spectra of a the Fourier transform of each of the two echoes. In this study, we propose a method, termed Minimum Phase Angle (MPA), that determines an optimal number of circular shifts to the windowed signal which results in a continuous phase spectrum and minimizes the likelihood of discontinuities within the bandwidth. Therefore the ambiguity in the phase unwrapping is avoided. To experimentally test the method experiments were performed in pulp fibre suspensions, which are weakly dispersive. The experiments were carried out using the pulse-echo technique in a custom designed test cell. A schematical view of the measurement cell used in this study is shown in Fig. 1.

p1

p2 Time

Transducer

In the manufacturing process of paper the mass fraction and material properties of the fibres in the pulp suspension are important for the quality of the finished product. When using recycled paper, fibres with unknown and varying material properties enter the process. Therefore, there is an increasing demand for methods of on-line characterisation of the pulp suspension as well as the fibres in suspension. This study presents two different methods of pulp characterisation. The first is based on phase velocity, which we use to investigate the composition of the pulp. The second is based on attenuation and is used to characterise the wood fibres. In the first method, we investigate how the phase velocity changes with different mass fractions of fibres and fines. To determine the phase velocity, a method is proposed based on a method by [1], where the an echo is circularly shifted an optimal number of samples.

A. Theory and experiments

Sample Bufferspace rod

I. I NTRODUCTION

II. P HASE V ELOCITY

Steel reflector

Abstract— In the manufacturing process of paper the mass fraction and material properties of the fibres in the pulp suspension are important for the quality of the finished product. This study presents two different methods of pulp characterisation. The first is based on phase velocity, which we use to investigate the composition of the pulp. Here a method is presented where the optimal number of circular shifts within the sampling window of the signal is determined which gives, in a weakly dispersive medium, a continuous phase spectrum and minimizes the likelihood of discontinuities within the bandwidth. Hence, the ambiguity in phase unwrapping is avoided. The results from phase velocity measurements show that the phase velocity weakly increases with increasing amount of fines in the suspension. The dispersion is caused by the fibres and it correlates with fibre mass fraction. The second method is based on attenuation and is used to characterise the wood fibres. The results of the attenuation experiments show that it is possible to inversely calculate wood fibre properties by fitting the model to the experimental data, if the fibre diameter distribution is known. However, the accuracy of these calculation is difficult to determined and more work in this area is required.

Fig. 1. study

d1

1

2 d2 3

Lattice diagram of the pulse-echo measurement system used this

Steel Pellet Production Processes

Zooming in: Flotation Process

District Heating Process

Increasing the complexity to improve “things”

What “Intelligence” are we seeking? •

When things go wrong (or could be improved) and •



there is potential information pointing to the symptoms. •

Information that is available



Information that could be available

have an intelligent system that saves or improves the situation.

The fundamental question is: “How do we make Intelligence happen?” •

How do we connect sensors, controllers, actuators together?



How do we develop “intelligent” controllers?



How do we describe the processes and their improvements?



How much will it cost? How long will it take? How do we introduce the new solutions in an existing infrastructure? How do we maintain the systems? How do we retire the systems?

A System •

A combination of interacting elements organized to achieve one or more stated purposes, an integrated set of elements, subsystems, or assemblies that accomplish a defined objective.



These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements

International Council on Systems Engineering. Systems Engineering Handbook v.3.2.2 , 2011.

Systems Engineering •

Systems Engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems.



It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal.



SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs International Council on Systems Engineering. Systems Engineering Handbook v.3.2.2 , 2011.

Home HomeGallery GalleryCreate Create Shop Shop About About

ted on 2015-06-02 created on 2015-06-02

Stakeholders’ views

ur cartoon's URLURL is : ishttp://projectcartoon.com/cartoon/362266 Your cartoon's : http://projectcartoon.com/cartoon/362266

t Cartoon:

Project Cartoon:

02/06/15 08:47 Project Cartoon:

Project Cartoon:

02/06/15 08:47

02/06/15 08:47

Project Cartoon:

Gartner Magic Quadrant

Clarizen Named a Leader in 2015 Gartner MQ. Get

Home

Gallery

Cre

created on 2015-06-02

Your cartoon's URL is : http://projectcartoon.com/car

Howthe the researchers Howthe thecustomer fund application Howthe theproject project was What really explained How theleader researchers What customer the customer really HowHow the customer explained HowHow the project leader designed it described it documented besides How the customer explained How the project leader needed it it understood it it it designed needed understood publications what they wanted. understood the concept.02/06/15 08:47 Project Cartoon:

How researchers How thethe fund application designed it How thedescribed funding application it described the product.

How the fund How was How theapplication researchers Howthe theproject fund application How the project was described it documented besides How the designer implemented designed it described it documented besides publications the system. publications

How ititwas supported after Howthe really performed How system was the project supported after the project.

What the performed customer really How it really How was supported after Whatitthe customer really needed needed.the project

roduction Planning Production Planning

hieve new levels of efficiency with Quintiq planning software Achieve new levels of efficiency with Quintiq planning software

projectcartoon.com/cartoon/362266/new http://projectcartoon.com/cartoon/362266/new

How it was after Howsupported the researchers the project designed it

Page 1Page of 2 1 of 2

HowHow it really performed the fund application How the demonstration described it system was built.

How the project was it was supported after HowHow the system was documdocumented besides thepublications. project -ented beyond publications

How customer explained Howthe it really performed it

Production Planning

‫אין כל חדש תחת השמש‬ •

There is nothing new under the sun.



System Engineering is not new •



Common example is the Apollo missions although the term can be found in the 1940’s at Bell Labs.

LTU has no education or research in Systems Engineering.

ion

Introduction

Systems Engineering Fundamentals

TABLE OF DOD’s SE Fundamentals CONTENTS Systems Engineering Fundamentals

PREFACE ............................................................................................................................................. iv PART 1. INTRODUCTION

SYSTEMS ENGINEERING FUNDAMENTALS

Chapter 1.

Introduction to Systems Engineering Management ............................................. 3

Chapter 2.

Systems Engineering Management in DoD Acquisition .................................... 11

PART 2. THE SYSTEMS ENGINEERING PROCESS Chapter 3.

Systems Engineering Process Overview ............................................................ 31

Chapter 4.

Requirements Analysis ....................................................................................... 35

Chapter 5.

Functional Analysis and Allocation .................................................................... 45

Chapter 6.

Design Synthesis ................................................................................................ 57

Chapter 7.

Verification ......................................................................................................... 65

Chapter 8.

Systems Engineering Process Outputs ............................................................... 73

PART 3. SYSTEM ANALYSIS AND CONTROL Chapter 9.

Work Breakdown Structure ................................................................................ 85

Chapter 10. Configuration Management ................................................................................ 91 Chapter 11. Technical Reviews and Audits ............................................................................ 99 Chapter 12. Trade Studies .................................................................................................... 111 Chapter 13. Modeling and Simulation ................................................................................. 117 Chapter 14. Metrics .............................................................................................................. 125 Chapter 15. Risk Management ............................................................................................. 133 PART 4. PLANNING, ORGANIZING, AND MANAGING Chapter 16. Systems Engineering Planning ......................................................................... 147 Chapter 17. Product Improvement Strategies ...................................................................... 157

January 2001

Chapter 18. Organizing and Integrating System Development ............................................ 171 Chapter 19. Contractual Considerations .............................................................................. 185 Chapter 20. Management Considerations and Summary ..................................................... 201

SUPPLEMENTARY TEXT PREPARED BY THE DEFENSE ACQUISITION UNIVERSITY PRESS

GLOSSARY ..................................................................................................................................... 209

Chapter 6

Design Synthesis

A Successful System SUPPLEMENT 6-A

CONCEPT DESCRIPTION SHEET

The Concept Description Sheet describes (in textual or graphical form) the technical approach or the design concept, and shows how the system will

be integrated to meet the performance and functional requirements. It is generally used in early concept design to show system concepts.

Target Missile

Missile Tracking Radar

Steering Commands

Target Tracking Radar

Radio

Computer

External Command Guidance System

Figure 6-3. Concept Description Sheet Example

61

from DOD’s SYSTEMS ENGINEERING FUNDAMENTALS

SYSTEMS ENGINEERING PROCESS OVERVIEW

System Engineering Process 3.1 THE PROCESS

definition with each level of development. As shown by Figure 3-1, the process includes: inputs and outputs; requirements analysis; functional analysis and allocation; requirements loop; synthesis; design loop; verification; and system analysis and control.

The Systems Engineering Process (SEP) is a comprehensive, iterative and recursive problem solving process, applied sequentially top-down by integrated teams. It transforms needs and requirements into a set of system product and process descriptions, generate information for decision makers, and provides input for the next level of development. The process is applied sequentially, one level at a time, adding additional detail and

Systems Engineering Process Inputs Inputs consist primarily of the customer’s needs, objectives, requirements and project constraints.

Process Input • Customer Needs/Objectives/ Requirements – Missions – Measures of Effectiveness – Environments – Constraints • Technology Base • Output Requirements from Prior Development Effort • Program Decision Requirements • Requirements Applied Through Specifications and Standards

System Analysis and Control (Balance)

Requirements Analysis • Analyze Missions and Environments • Identify Functional Requirements • Define/Refine Performance and Design Constraint Requirements

Requirements Loop

Functional Analysis/Allocation • Decompose to Lower-Level Functions • Allocate Performance and Other Limiting Requirements to All Functional Levels • Define/Refine Functional Interfaces (Internal/External) • Define/Refine/Integrate Functional Architecture

• • • • • • •

Trade-Off Studies Effectiveness Analyses Risk Management Configuration Management Interface Management Data Management Perfromance Measurement – SEMS – TPM – Technical Reviews

Design Loop

Synthesis

Verification

• Transform Architectures (Functional to Physical) • Define Alternative System Concepts, Configuration Items and System Elements • Select Preferred Product and Process Solutions • Define/Refine Physical Interfaces (Internal/External)

Related Terms:

Process Output

Customer = Organizations responsible for Primary Functions Primary Functions = Development, Production/Construction, Verification, Deployment, Operations, Support, Training, Disposal Systems Elements = Hardware, Software, Personnel, Facilities, Data, Material, Services, Techniques

• Development Level Dependent – Decision Database – System/Configuration Item Architecture – Specifications and Baselines

Figure 3-1. The Systems Engineering Process

31

from DOD’s SYSTEMS ENGINEERING FUNDAMENTALS

Lots of stakeholders Systems Engineering Fundamentals

Disposal

Chapter 1

Training

Verification

Operation

Support

8 Primary Life Cycle Functions

Development Deployment

Manufacturing/Production/ Construction

Figure 1-4. Primary Life Cycle Functions Operation is the user function and includes activities necessary to satisfy defined operational objectives and tasks in peacetime and wartime environments. Support includes the activities necessary to provide operations support, maintenance, logistics, and material management. Disposal includes the activities necessary to ensure that the disposal of decommissioned, destroyed,

Systems Engineering Considerations Systems engineering is a standardized, disciplined management process for development of system solutions that provides a constant approach to system development in an environment of change and uncertainty. It also provides for simultaneous product and process development, as well as a common basis for communication.

DOD’s SYSTEMS ENGINEERING FUNDAMENTALS Systems engineering ensures that thefrom correct

Systems Lifecycle Management •

ISO/IEC 15288 Systems and software engineering — System life cycle processes (IEEE Std 15288-2008)



This International Standard establishes a common process framework for describing the life cycle of man-made systems. It defines a set of processes and associated terminology for the full life cycle, including conception, development, production, utilization, support and retirement. This standard also supports the definition, control, assessment, and improvement of these processes. These processes can be applied concurrently, iteratively, and recursively to a system and its elements throughout the life cycle of a system.

Costs Planning & Follow up Systems Engineering Fundamentals

Chapter 14

Total Allocated Budget

Over Budget

EAC

Management Reserve P R O J E C T E D

PMB

$

Schedule Variancec

Cost Variance c

BCWSc ACWPc BCWPc

Time Now

S L I P P A G E

Completion Date

Figure 14-1. Earned Value Concept from DOD’s SYSTEMS ENGINEERING FUNDAMENTALS

Model Based System Engineering



Model-based systems engineering (MBSE) is a systems engineering methodology that focuses on creating and exploiting domain models as the primary means of information exchange between engineers, rather than on document-based information exchange.

A Modeling Tool 2.3 SysML Diagram Overview

15

Figure 2.1 SysML diagram taxonomy

with the hollow, triangular arrowheads mean. They’re called generalizaSysML of Distilled: Brief Guide to the Systems Modeling Language tions. You read them as “is a type of” in the direction theAarrowhead.

Self Awareness •

For the sake of the discussion afterwards, please be aware of your current understanding of the list below (before the rest of the talk) •

District Heating



The Arrowhead Framework



Model Based System Engineering

District Heating Structure bdd [Package] Structure [ System Context ]

«block» District Heating

management

consumption

«block» Management

system Coordination

data management

simulation

«block» Academic Version for Teaching Only Data management Commercial Development is strictly Prohibited «block» System Coordination

«block» Sim ulation

«block» Consumption

commercial buildings

production

apartment buildings family houses hing Only for Teac demic Version single Aca «block» «block»ibited tly Proh lopment is stricSingle cialentDeve Commer Apartm buildings fam ily houses

«block» Com mercial buildings

«block» Production

parts

parts

district Heating Substation : District Heating Substation [0..1] electricity : Electricity radiators : Radiators [0..*]

fuel : Fuel burnner : Burnner heat exchanger : Heat exchanger pumps : Pumps distribution «block» Distribution parts

insulated pipes : Insulated pipes communication : Communication pressure sensor : Pressure sensor flow meter : Flow meter temperature : Temperature: C valve : Valve pumps : Pumps

Distribution System bdd [Package] Structure [ Distribution ]

«block» Distribution

insulated pipes «block» Insulated pipes

ching Only Academic Version for Tea «block» «block» d «block» ProhibiteLeakage is strictly Commercial Development Pipes Insulation detection pipes

insulation

leakage detection

pressure sensor

flow meter

«block» Pressure sensor

temperature

«block» Flow meter

g Only for Teachin ic Versionpumps Academ valve communication tly Prohibited ent is stric ial Developm Commerc«block» «block» «block» «block» Tem perature: C values

temperature : C Sampling frequency : Hz

Valve

Pum ps

Com m unication

Single Family house bdd [Package] Structure [ House ] «block» Single fam ily houses

district Heating Substation 0..1 «block» District Heating Substation electricity

values

radiators 0..*

«block» Electricity

Loc : Location

«block» Radiators

Academic Version for Teaching Only al Development is strictly Prohibited domestic hot w ater merci Com heatmeter

Academic Version for Teaching Only hydronic heating Commercial Development is strictly Prohibited «block»

«block» Dom estic hot w ater

Hydronic heating

Outdoor temperature «block» Tem perature: C

controller

values

«block» Controller

temperature : C Sampling frequency : Hz Radiator supply temperature

pump

valve «block» Pum p

valve

mechanical controller

«block» Valve

«block» Mechanical controller

heat exchanger

«block» Tem perature: C values

temperature : C Sampling frequency : Hz

«block» Heat exchanger

Domestic hot w ater pressure «block» Pressure sensor

«block» Valve

«block» Heatm eter heat exchanger

Primary return

Primary flow

«block» Tem perature: C

«block» Heat exchanger

values

Primary supply «block» Tem perature: C values

temperature : C Sampling frequency : Hz

temperature : C Sampling frequency : Hz

«block» Flow m eter

communication «block» Comm unication

Component Interactions ibd [Block] District heating substation [ District heating substation ]

Primary supply temperature

pst

Primary return temperature

prt

Primary flow meter

: Heatm eter energy

Commnucation

Primary flow meter

Academic Commerc

Academic Version for Teaching Only Commercial Development is strictly Prohibited : Controller Outdoor temperature Radiator supply temperature

Outdoor temperature Radiator supply temperature

Valve position

Valve position

Arrowhead Framework to the Rescue

Service Oriented District Heating Components Outdoor temperature service provider

Valve service provider

Flow service provider

Heat meter service provider

SOA in District Heating sd [Interaction] vfsd [ vfsd ]

«block» Outdoor tem perature : Tem perature: C

«block» Radiator supply tem perature : Tem perature: C

«block» valve : Valve

Service Registry

Authorization system

Orchestration System

«block» controller : Controller

1: Register outdoors temperature

2: Register radiator supply temperature

Academic Version for Teaching Only Commercial Development is strictly Prohibited

Academic Version for Teaching Only Commercial Development is strictly Prohibited 3: Register Valve

4: Ask for outdoor temp 5: Ask for outdoor temp 6: Propose outdoor temp 7: Authorize outdoors temp? 8: Yes 9: Outdoors temp address

10: Ask for radiator supply temp 11: Ask for radiator supply temp 12: Propose radiator supply temp 13: Authorize radiator supply temp?

Academic Version for Teaching Only Yes opment is strictly Prohibited Devel Commercial 14:

Academic Version for Teaching Only Commercial Development is strictly Prohibited

15: Radiator supply temp address

17: ask for control valve

16: Ask for control valve

18: Propose control valve 19: Authorize control valve? 20: Yes 21: Control valve address loop []

22: Request outdoors temperature 23: Provide temperature 24: Request radiator supply temperature 25: Provide radiator supply temperature

Academic Version for Teaching Only Commercial Development is strictly Prohibited

Academic Version for Teaching Only 26: Request valve position Commercial Development is strictly Prohibited 27: Confirm valve position

Indoors tem perature

Gatekeeper

Orchestration out of problems (or Intelligence) •

The outdoor sensor is offline (e.g., out of battery),



You could use the neighbor’s outside sensor via the Gate Keeper, •



but the Internet is dead!

You could use an indoor temperature sensor to control the indoor temperature….

Orchestration System Conversations

More can be done in this configuration… •

Estimation of thermal insulation and thermal capacitance of the building in real time,



Better control control of heating control strategy in Demand Response applications,



System Prognostic and and Diagnostics, e.g., damaged pipe insulation,



Tamper proof, information to stakeholders,



System phase in and out, Scalability.

System Engineering in IIP •

Increase stakeholder communication to understand their paradigms or views on the same issue,



Manage the lifecycle of the systems and subsystems,



With MBSE, zoom in and out within the systems,



Develop “Intelligence” through Use Cases.

Do we know what we really want?





The technology is here.



The Arrowhead Framework is here.

How does one make an Industrial Process Intelligent?

Which is the right problem?



Successful problem solving requires finding the right solution to the right problem. We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem. Russell L. Ackoff, Redesigning the future, 1974, p. 8.