Report with the Requirements of Multi-Agent Architecture...

inteGration of pRocess and quAlity Control using multi-agEnt technology

Project founded by the European Commission under the “Seventh Framework Programme” (2007-2013)

Contract n° NMP2-SL-2010-246203

Project Ref. Number : 246203

Project Start Date : 01/07/2010

Project Duration : 36 months

Website : www.grace-project.org

Document type : Deliverable

Document version : Draft

Document Preparation Date : 05/11/2010

Classification : Public

Author(s) : IPB

File Name : Deliverable-GRACE-1-1-v8.pdf

Work Package 1

Multi-Agent Architecture

Deliverable D1.1

Report with the Requirements of Multi-Agent Architecture for Line-production Systems and

Production on Demand

2

Deliverable D1.1 Requirements of Multi-Agent Architecture for Line Production System and Production

Rev. Content Resp. Partner Date 0.1 Preliminary List of Requirements IPB 15/09/2010

0.2 Integration of new requirements from all the partners

IPB 05/10/2010

0.3 New classification and integration of requirements

IPB 05/11/2010

3


Table of Contents

1. Introduction ........................................................................................................................ 4

2. Contextualization and Definitions ...................................................................................... 5

2.1. Concept of Distributed Manufacturing Systems .................................................... 5

2.2. Concept of Manufacturing Control ........................................................................ 7

2.3. Concept of Multi-agent Systems .......................................................................... 11

3. Requirements and Characteristics for a Distributed Production Control System ........... 14

3.1. Functional Requirements ..................................................................................... 15

3.1.1. General Low-level Functional Requirements ....................................................................... 15

3.1.1. General Functional Requirements ....................................................................................... 17

3.1.1. Functional Requirements on Quality Control Processes ..................................................... 22

3.2. Non-Functional Requirements ............................................................................. 24

3.2.1. General Non-Functional Requirements ............................................................................... 24

3.2.2. Non-Functional Requirements on Integration of Production and Quality Control ............. 29

3.2.3. Non-Functional Requirements on Design, Configuration and Maintenance ....................... 30

3.2.4. Non-Functional Requirements on IT environment .............................................................. 32

4


1. Introduction

This deliverable contains the outcome of Task 1.1, entitled “Analysis of characteristics

and requirements of multi-agent architecture for line-production systems and production

on-demand”, which has two main objectives:

Definition of the needs and requirements for the Distributed Manufacturing System

(DMS) and the desirable features it will provide.

Description of the production process for the washing machines that will be used in

the specification of the multi-agent system architecture.

The document is divided into 4 chapters. After this brief introduction, chapter 2 will

provide a contextualization of the problem addressed in this document and some definitions

to clarify some important concepts used during the project. This guarantees an easy reading

and understanding of the different contributions coming from the different partners and

representing different domains.

Chapter 3 is dedicated to the specification of the requirements for DMS, with particular

attention to the line-production systems. The requirements are numbered and specified by

using a common approach, which facilitates its understanding and the posterior analysis. The

discussion of these requirements will lead to their classification into different categories,

according to their dependencies and similarities.

This document will be revised every six months and will be improved with the generated

knowledge during the project execution.

5


2. Contextualization and Definitions

The main objective of the GRACE project is to conceive, study, develop, implement and

validate a collaborative multi-agent system (MAS) which operates at all stages of a

production line, integrating the process control with quality control at local and global levels.

This approach is in line with the current trend to build modular, intelligent and distributed

manufacturing control systems.

The next sections try to contextualize the focus of the GRACE production control system

and to clarify some concepts used in this project, namely distributed manufacturing systems,

manufacturing control and multi-agent systems.

2.1. Concept of Distributed Manufacturing Systems

Nowadays, manufacturing industry is characterized by dynamic enterprises operating in

a global scale, each one being made up of a number of autonomous production units or

facilities cooperating among themselves. A distributed manufacturing system (DMS) can be

defined as a production system that is geographically distributed, dispersed within a widely

area (the equipments, operators, products and information), acting in a cooperative way in

order to work as a whole.

The several types of distributed manufacturing systems present structures and features

that can be modelled and related through a layered approach, which exhibits a fractal

structure (Leitão and Restivo, 1999), as illustrated in Figure 1. This model represents fractal

layers with similar interaction models, but different actors and requirements. The lower the

layer, the higher are the temporal restrictions and the complexity of integration with

physical resources. On the other hand, the higher the level, the higher are the inter-

operability problems.

The highest layer, the inter-enterprise layer, represents the interaction between

distributed enterprises acting together in order to achieve a common objective. Supply chain

is a well known example of distributed manufacturing, dealing with the management of

materials, information and financial flows in a network comprising suppliers, manufacturers,

6


distributors and customers. Worldwide market competition implies that manufacturing

enterprises can no longer be seen as acting stand-alone or within rigid supply chains and

forces them to reconsider how they are organized. The concept of Virtual Enterprise appears

to represent a temporary alliance of enterprises that come together to share skills and

resources in order to better respond to business opportunities and whose co-operation is

supported by computer networks (Camarinha-Matos and Afsarmanesh, 1999). Nowadays,

namely in automobile industry, other forms of enterprise organisation have emerged, such

as the Extended Enterprise, e-Alliances or Smart Organisation (Leitão, 2004).

A similar scenario is found within each manufacturing enterprise. When zooming into an

enterprise another distributed manufacturing layer can be seen, the enterprise layer, where

it is possible to find the co-operation between geographically distributed entities, such as

sales offices and production sites, in a multi-site environment.

By zooming down a production site it is possible to reach the factory layer, where the

distributed manufacturing control within the site can be found. In this layer, the entities are

distributed through shop floor areas, working together and in co-operation, in order to

accomplish all the orders allocated to the production site. By zooming down a shop floor

area it is possible to see the shop floor layer, where the co-operation between different cells,

such as manufacturing, assembly and transport, all organized in a flexible manufacturing

system, can be found. Finally, a similar environment is found in the cell layer, with the

interaction between equipments and humans belonging to a cell.

7


Figure 1 The layer approach to distributed manufacturing (Leitão and Restivo, 1999)

2.2. Concept of Manufacturing Control

Control is a key factor in automated production systems. It is required at two different

stages: at low and at high level. At the low-level, the automation devices, such as industrial

robots and numerical control machines, require control techniques that regulate their

behaviour according to a specific objective. The control techniques may be simple or

advanced, depending on the process to be controlled and the time scale, as illustrated in

Shop Floor Level

Factory Level

Enterprise Level

Inter-Enterprise Level

Sales

shop

floor

shop

floor

Cell Level

cellcell

cell cell

shop

floor

shop

floorshop

floor

8


Figure 2. Simple control functions are typically handled by standard controllers i.e. PID

(proportional, integral and derivative) and are often delivered by the equipment suppliers.

More advanced control functions are required in case of process disturbance, non-linear

processes and robustness requirements.

Figure 2 Time scales in the various automation levels

The high-level control is concerned to coordinate the manufacturing resources activities

aiming to produce the desired products, such as in the case of flexible manufacturing control

systems. Algorithms at this level are used to decide what to produce, how much to produce,

when production is to be finished, how and when to use the resources or make them

available, when to release jobs into the factory, which jobs to release, job routing, and

job/operation sequencing (Baker, 1998).

The shop floor control, also referred as Manufacturing Execution Systems (MES), is

concerned with the problem of monitoring and controlling the physical activities (processing,

assembling, transportation and inspection) in the factory aiming to execute the

manufacturing plans. It includes the scheduling (resource allocation), dispatching,

monitoring and reaction to disturbances activities. The manufacturing control concept

extends the shop floor control by considering also the short-term process plan activities. The

9


production control encompasses manufacturing control of one or several plants, purchasing,

material requirements planning, design, medium and long-term process planning, and other

production activities. The production control is also referred as the production planning and

control (PPC) systems.

Figure 3 illustrates the pyramid related to the IT-enterprise for manufacturing.

Figure 3 Modern IT-enterprise for manufacturing

The Enterprise Resource Planning (ERP) systems are integrated enterprise wide systems

which automate core corporate activities such as manufacturing, human resources, finance

and supply chain management. The ERP systems normally include all office planning,

scheduling, sales, supportive logistics and services systems, interacting with the MES systems

by providing the production plans. In the lower level of the pyramid is the distributed control

system (DCS) which is related to control of the automation devices, e.g. by using a network

of Programmable Logic Controllers (PLC).

The GRACE system will act at the MES level, so a deep analysis of this system is

important at this stage. MES provides effective integration between production processes

and enterprise business systems while allowing a detailed control of the actual production

processes. According to the MES standard ANSI/ISA-95 the main functionalities provided are

illustrated in Figure 4. This generic activity model is then applied to production, quality and

maintenance domains. The following functionalities can directly and/or indirectly contribute

10


to an optimization of the production management process and therefore special care must

be paid. For a in depth study the referred standard should be consulted.

Figure 4 Generic activity model of manufacturing operations management (ANSI/ISA-95.00.03)

Taking into consideration the production management, the main functionalities are:

Detailed production scheduling, that provides sequencing for the production based

on a set of criteria, such as priorities, attributes, characteristics, production rules; it

can be either very simple or very complex depending upon the process defined to

level the production.

Production resource management, that manages the resource utilization, occupation

and correct utilization; coordination with maintenance resource and quality resource

can also be taken into consideration.

Production tracking, that provides reports on status of production executed and in

execution, allowing forward and backward traceability;

Production dispatching, that manages the flow of production in the form of orders,

batches, lots and pitches by dispatching production information and/or signals to

specific equipment and workstations; this may involve work orders to workstations

11


and/or to manual operations, and also information from quality operations that may

affect the scheduled events.

Production definition management, that manages the information required for the

product manufacturing including the production rules; it contains the necessary

information to instruct a manufacturing operation to produce a product.

Production execution management, that is responsible for allocating the right

resources to the right sequence of production, informing the other activities about

timing, labour and materials used; a feedback may arise from the quality control to

ensure the quality standards.

Product data collection, that ensures all data due related to the manufactured

product are collected and stored (it may involve, besides others, sensor reading,

equipment states, operations actions and operator-entered data); all previous data

collection is gathered with a time or event based form.

Production performance analysis, that is responsible of calculating and analysing

some performance parameters of the gathered data collection, such as equipment

utilization, equipment performance and procedure efficiencies; these parameters can

be used to optimize production and the resource utilization.

The above functionalities comprise the collection of information exchanged between

them in order to obtain production optimization.

2.3. Concept of Multi-agent Systems

The traditional method used to deal with these large systems was to decompose the

system into smaller, more manageable subsystems and machines, program the control for

each one separately, and then write custom “glue” code to knit the smaller components into

the complete system (Hall, 2007).

Traditional centralized, rigid approaches do not have the capabilities of responsiveness,

flexibility, robustness and re-configurability. Multi-agent systems (MAS) are a suitable

12


approach to support this challenge by providing an alternative way to design control systems,

based on the decentralization and parallel execution of activities based on autonomous

entities, the agents, which are able to respond promptly and correctly to change, due to

their inherent capabilities to adapt to emergence without external intervention (Leitão,

2009). The most important properties of an agent are autonomy and cooperation. In this

case, autonomy is defined as the ability to perform a process or a system adjustment

through the system itself without human intervention during the process; autonomy enables

systems to perform in dynamic environments. The level of autonomy can be assessed by

defining the necessary degree of human intervention, i.e. semi-autonomous. Cooperation is

the ability to interact with each other, acting together to achieve a global system goal, or

shared goals. Additionally, agents can exhibit other characteristics, such as intelligence and

adaptation.

A multi-agent system is a society of agents that represent the objects of a system,

capable of interacting, in order to achieve their individual goals, when they have not enough

knowledge and/or skills to achieve their objectives individually. The global system behaviour

is achieved through the complex interaction among the individual agents, each one having

its own objectives and behaviours, and possessing its own perceptive and cognitive

capabilities.

In the GRACE project, the focus will be in studying and designing distributed

manufacturing control systems for production lines producing home appliances and

particularly washing machines, using the multi-agent principles, which guarantee the

achievement of flexibility, responsiveness and reconfigurability. A particular requirement to

be considered is the integration of the production control with the quality control

information. For this purpose, the manufacturing and assembly systems, and the quality

control stations of a home appliance production line will be treated as intelligent agents, and

the whole production process will be supervised and controlled through the networked

collaboration of individual agents. In order to integrate process and quality control new

13


feedback loops are needed and advanced control techniques as i.e. adaptive control loops

may be designed.

14


3. Requirements and Characteristics for a Distributed Production Control System

This section intends to identify the needs and requirements for DMS in general and for

washing machines process lines in particular, and the desirable features that the multi-agent

system will provide.

Aiming at a clear understanding of the identified requirements, they will be represented

using a descriptive form formatted according to the tuple {id, title, description, scope, case

study, date, author}, where:

– The id parameter refers to a unique identifier of the requirement.

– The title parameter refers to a title that states clearly the requirement. A concise

description of the requirement should be provided, containing a priority classification

differentiating between:

o MUST: which means that the definition is an absolute requirement of the

specification.

o SHOULD (or the adjective “RECOMMENDED”): which means that there may

exist valid reasons in particular circumstances to ignore a particular item, but

the full implications must be understood and carefully weighed before

choosing a different course.

– The description parameter is concerned to a detailed description of the purpose and

objective of the requirement.

– The scope parameter defines whether the requirement applies for particular

scenarios or generic scenarios.

– The case study parameter indicates if the requirement is presented in the washing

machine process case study.

– The date parameter provides the date when the requirement was issued.

15


– The author parameter indicates the name of the originator of the requirement.

The identified requirements will be presented in the following sections, grouped

according to their similarities, e.g. considering the functional, non-functional and other more

specific views. A catalogue of requirements is provided at the end of this chapter to provide

an overview and an easy approach to find and understand these requirements.

3.1. Functional Requirements

Functional requirements are driven and traced from business and they define what a

system is supposed to accomplish with. They generally describe what a “system should do”

(system design), defining functions of a system or its components, while these functions can

be described as a set of inputs, the visible behaviour and outputs.

Therefore functional requirements are supported by non-functional requirements which

describe what a “system should be” (system architecture).

3.1.1. General Low-level Functional Requirements

Requirement ID: LLFR-1

Title: The system MUST execute and control well defined production processes

Description:

A production control system must execute and control the production processes to produce (parts of) a

product (in the case of this project for a washing machine).

Scope: Generic Author: SIEMENS Case study: Yes

Requirement ID: LLFR-2

Title: The system MUST execute and control parallel production processes

Description:

A production control system must execute and control several production processes in parallel.

16



Requirement ID: LLFR -3

Title: The system MUST execute and control the production related quality assurance

processes

Description:

A production control system must execute and control the quality assurance processes for a product (or

parts of it).



Title: The system MUST facilitate product and process variation as far as required

Description:

A production control system must support a required variability and process redundancy in production

of (parts of) a product (in the case of this project for a washing machine).



Title: The system MUST execute and control production (semi-)automatically and manually

Description:

A production control system must facilitate the automatic, semi-automatic and manual execution and

control of production processes for (parts of) a product (in the case of this project for a washing

machine).


17



Title: The system MUST facilitate reproducibility of product and of product quality

Description:

The production control system needs to facilitate the production of a product (parts) with a given

process and quality, even after producing other parts or with another process.



Title: The system SHOULD document production

Description:

A production control system should facilitate the technical and commercial documentation of the

production of instances of (parts of) a product (in the case of this project for a washing machine).


3.1.1. General Functional Requirements

Requirement ID: FR- 1

Title: The system MUST implement time-constrained manufacturing functions

Description:

The system must implement and supervise the required sequences of operations as well as detect and

diagnose malfunctions within predetermined time windows. Control and quality functions must operate

in the same time frame as the machine in order to guarantee the production flow. This is especially

important when feedback loops (e.g. quality control) are introduced in the system and instability may

occur due to sampling and control action delays. Furthermore this relates to the time-constraints

related to communication algorithms and structure.

Scope: Generic Author: AEA and UNIVPM Case study: Yes

18



Title: The system MUST be able to take autonomous decisions to a specific (predefined)

degree

Description:

The system operation based on the coordination of individual entities happens with a certain level of

predefined autonomy, i.e. without intervention from the outside or the assistance of an operator. The

system should be acting autonomously, but different entities may show a different degree of autonomy.

The objective of each entity is to fulfil the respective task, performing its behaviour and role.

Examples of process or production control functionality where autonomy can be present are:

i) the system can change production parameters in a predefined range, like configurations of single production steps and sequence of production or testing steps,

ii) the system can change resource (machine, etc.) utilization in a predefined range.

Scope: Generic Author: IPB and AEA and UNIVPM Case study: Yes


Title: The system MUST be able to adjust with respect to the production needs

Description:

Flexibility is intended as the ability of the system to manage different models of products (within a

certain predefined range): the system must be able to perform its functionalities and to reconfigure

itself depending on production needs (e.g. product fluctuation, change in the production equipments

due to breakdowns). Complete customization can be seen as a limit case where all the products are

different from each other.

Scope: Generic Author: AEA Case study: Yes


Title: The system MUST handle association, change and removal of entities on the fly

Description:

The addition, removal and modification of the system’s entities can be performed on the fly, i.e. without

the need to stop, re-program and re-initialize the other entities (this also includes the substitution and

19


the insertion of new technologies and functionalities in order reply to new requirements following the

technology development).

Particularly, each part of the whole system should be upgradable and quickly replaceable (or their

functions should be performed by another entity which can provide similar results).

Scope: Generic Author: IPB and UNIVPM and AEA Case study: Yes


Title: The system MUST handle processes exceptions properly

Description:

In industrial environment, robustness and fault tolerance are key issues. A production control system

needs to automatically handle well defined production process exceptions arising during the production

process. Particularly, the system has to decide whether to keep on running by using different entities or

if the failures (e.g. physical devices or software entities malfunctioning) may require the system to run

in a safe mode or to stop in a safety position.



Title: The system MUST interact with legacy systems and physical devices

Description:

Industrial systems comprise physical devices and running applications that must be integrated with the

developed applications. For this purpose, the success of the integration of a new application requires

the interface with legacy systems (e.g. existing hardware, software and computer infrastructure) and

physical devices (e.g. production automation equipment and testing equipments). Note that this also

includes the information provided/received to different users (e.g. operators, manufacturing engineers

and managers) during the execution of their tasks.

Scope: Generic Author: IPB and AEA Case study: Yes

20



Title: The system SHOULD provide concise but meaningful output

Description:

The output of the system should be concise, providing few data with high “density” of useful

information. The system should provide the most relevant information to the other entities, and the

remaining should be stored in a database for future use.

Scope: Generic Author: UNIVPM Case study: Yes


Title: The system SHOULD aggregate information

Description:

Information and data from different entities should be aggregated in order to be easily understandable

for a human operator and more valuable for other entities of the system.



Title: Information SHOULD provide an access right system

Description:

The system should ensure the availability of the data, resources and services required by authorized

entities. However, the system information can only be read by a legitimate entity and also modified in

an authorized manner.


21



Title: The system SHOULD permit to validate critical functions

Description:

Human operator should be able to validate or modify critical functions in order to influence the overall

behaviour of the system and prevent from anomalous operating conditions.



Title: The system SHOULD warn abnormal situations

Description:

Because it is not possible in distributed environment to follow each single problem and at the same time

have an overview of the effects of any deviation etc. on other groups/units or tasks, a warning system

should point to abnormal situations before they create big problems. Therefore, in case of failures,

schedule deviations or other events that endanger the delivery date the system must warn

automatically the user. Warning messages have to be displayed when a user logs on in the system as

well as when the event occurs. The warning system should provide different warning levels, assigned to

different users (for decentralised units). It must be possible to print lists of warning messages.

The system must provide the notification of service and/or device downtime or failure.

Scope: Generic Author: IPB Case study: Yes


Title: The system SHOULD provide an interaction with other DMSs

Description:

The inter-DMS communication permits the interaction with other DMSs (e.g. suppliers, customers and

partners DMSs).

Scope: Generic Author: AEA Case study: No

22



Title: The system SHOULD leverage standards as much as possible

Description:

The use of standards is a contribution to support the integration of legacy systems and heterogeneous

devices/systems.

Scope: Generic Author: IPB Case study: No


Title: The system MUST provide virtual commissioning

Description:

A production control system needs to provide facilities to test the production processes with and

without production equipment.

Scope: Generic Author: SIEMENS Case study: No

3.1.1. Functional Requirements on Quality Control Processes

Requirement ID: QCR-1

Title: The quality control system SHOULD manage measurement results

Description:

The quality assurance part of a production control system is expected to measure the production

process quality, to manage production the process quality, to manage the production result quality and

to manage the production history.

Scope: Particular Author: SIEMENS Case study: Yes

23



Title: The system SHOULD not require action to be performed on the product

Description:

The measuring system should avoid actions performed on the product, requiring the installation of

some kind of sensor on the product, in preference using non-contact techniques.

Scope: Particular Author: UNIVPM Case study: Yes


Title: The measurement systems SHOULD be accurate

Description:

The measurement systems should provide accurate results, matching the desired level of uncertainty

(low uncertainty)



Title: The measurement system SHOULD be stable

Description:

The measurement instrumentation should provide stable signals in order to have meaningful results.

The signals must remain of high quality when the conditions of the environment or of the measured part

change, i.e. robust measurements.



Title: The data collected by the measurement system MUST be traceable

Description:

The data collected by the measurement system must be related to standard references through an

unbroken chain of comparisons.

24




Title: The system SHOULD execute manual/automatic quality analysis and reporting

Description:

The systems should execute interactive/manual and/or automatic production quality analysis and

reporting.

Scope: Particular Author: SIEMENS Case study: Yes

3.2. Non-Functional Requirements

Non-functional requirements are driven from functional requirements, but are related to

mode internal behaviour (e.g., performance or quality) or constraints of the service provided

(e.g., standard compliance).

3.2.1. General Non-Functional Requirements

Requirement ID: NFR- 1

Title: The system MUST be based on a set of distributed entities

Description:

Traditional control systems often operate in a centralized manner, upon rigid control and

communication structures. In opposition to the traditional centralized structures, the new approach

must be based on a decentralized control structure built upon a set of distributed entities, each one is

independent and autonomous, with proper objectives, knowledge and skills. An entity could be a

production machine, a quality control station, the product itself or part of the information system.

This means that the high level functionalities (e.g. control, scheduling and monitoring) are

distributed.


25



Title: Entities of the system MUST interact/cooperate with each other

Description:

In distributed systems based on a community of individuals, entities must share their knowledge and

skills/functions throughout cooperation, in order to accomplish their own functions (when they cannot

perform them alone due to insufficient knowledge or skills). Therefore an interaction between the

individuals is needed, so that every entity can send /receive which functions it is able to offer and which

are needed.



Title: Interoperability MUST be supported between heterogeneous control entities

Description:

Today’s industrial applications are composed of several heterogeneous components, i.e. different

devices, pallets and products. Interoperability is a property of a system, whose interfaces are completely

understood, to work with other systems, present or future, without any restricted access or

implementation.

For this purpose, a special attention to attain the interoperability issues is needed when designing

interaction mechanisms to achieve cooperation

Scope: Generic Author: IPB and UNIVPM Case study: Yes


Title: The system SHOULD be scalable to allow large scale networks without significant

performance loss

Description:

The scalability of the system should be possible without the loss of performance.


26



Title: The system SHOULD have an user-friendly interface

Description:

The system provides information to the users (e.g. operators, manufacturing engineers and managers)

throughout user-friendly interfaces. Particularly, the system should provide facilities to visually monitor

the production processes and/or use external monitoring using software such as SCADA.

Scope: Generic Author: AEA and SIEMENS Case study: Yes


Title: The system MUST support production performance monitoring

Description:

The system must support monitoring of production using performance indicators such as energy

consumption, costs, efficiency and productivity.



Title: The system SHOULD work correctly/not be influenced by changing condition over

time.

Description:

The performance of the system should not be degraded over time. The system should maintain its full

capabilities in different condition (i.e. a machine vision measuring entity should operate in the same way

during the day and the night).


27



Title: The system SHOULD provide the self-organizing functionality

Description:

In order to support flexibility and re-configurability, the system should provide the capacity to self-

organize according to the current environmental conditions.



Title: The system SHOULD provide the self-optimization functionality

Description:

The system should exhibit self-optimization in order to improve its performance, performing self-

diagnosis and self-tuning its control parameters.

Scope: Generic Author: IPB and UNIVPM Case study: Yes


Title: The system MUST provide the self-adaptation functionality

Description:

The system should dynamically adapt its behaviour to a given physical production process state or in

response to disturbances from both internal and external manufacturing environments. This

functionality is related to the hardware and software reconfiguration.



Title: The system entities SHOULD provide the learning functionality

Description:

Aiming to improve the performance of the system (e.g. productivity, products optimization), the

28


system’s entities should be able to learn from past experience.

Scope: Generic Author: AEA Case study: No


Title: The system functionalities SHOULD be reusable

Description:

The implementation of the same functionality should not be duplicated; different instances of the same

functionalities should be used if needed. Reusable modules and classes reduce implementation time,

reduce the possibility of bugs because they have been already tested, and facilitate code modifications.

Reusability implies some explicit management of building, packaging, distribution, installation,

configuration, deployment, maintenance and upgrade issues.



Title: The system SHOULD support traceability

Description:

The system should support the traceability of the production process, i.e. the completeness of the

information about every step in the production process sequence (production history from components

to final products).

Scope: Generic Author: AEA and IPB Case study: Yes


Title: The system MUST operate at planned production capacity and speed

Description:

The computational resources of a production control system must support maximum planned

production capacity and execution and control requirements of the fastest processing.


29


3.2.2. Non-Functional Requirements on Integration of Production and Quality

Control

Requirement ID: IPQR- 1

Title: The system MUST support the integration of production and quality control

Description:

Quality control data and functionalities (acquisition, processing, classification, visualization and

collection) must be considered in the production control system by introducing feed-forward production

actions and the generation of new feedback loops (provide/receive quality measurements in the

production context and change the production process automatically based on quality measurements).

Scope: Generic Author: IPB and AEA Case study: Yes


Title: The system SHOULD be able to customize the measurements of quality control

stations

Description:

Quality control should be customized for each product basing on data coming from previous stages in

the production line and information from the environment and the production process.

Scope: Particular Author: WHI Case study: Yes


Title: The system SHOULD be able to optimize the operations of production machines

Description:

Production machines operations should be optimized basing on data coming from quality control

stations and information from the environment and the production process.


30



Title: The system SHOULD manage the statistical quality test areas

Description:

The percentage and the type of products chosen for the statistical test should be managed by the

system depending on the information collected during the production process.



Title: The system SHOULD be able to customize the product

Description:

The product should be customized, i.e. the setting of EEPROM parameters of the appliance control

board, basing on data and information coming from the production process and market surveys in order

to satisfy quality standard requirements and market needs.


3.2.3. Non-Functional Requirements on Design, Configuration and Maintenance

Requirement ID: DCMR- 1

Title: The system SHOULD enable the adaptability of the implementation

Description:

Enable the adaptability of the implementation, in terms of controlled production processes and used

production resources, to different use cases or different types of production processes.


31



Title: The system SHOULD provide interfaces to interact with

Description:

The production control system needs to provide facilities to interact with (e.g. receive input from) a

process planning and validation environment for line production systems, and in particular for washing

machine production (Basic Process, Assembly Process and Testing Process).



Title: The system SHOULD be configurable by input information

Description:

The production control system needs to be configurable by input of the following information:

Specifications of the production process flow, consisting of process segments and single steps (like basic step, assembly step, transport step, testing step) and their physical and logical order (according to the Whirlpool concepts of “Process Product Structure” and “Functional Product Structure”);

Specifications of variants and dependencies of production process, process segments, single steps and their operational parameters (e.g. sequence, parallelism, parameters, optional steps);

Specifications of production related activities that are needed in the production process (e.g. material supply steps, tooling exchange steps);

Definitions of production parameter ranges and other process specific production rules restricting operational flexibility;

Specifications of dependencies of parameters of production and those of testing steps (e.g. cause-effect relations of parameters, parameter sets or parameter ranges);

Specifications of functionalities (and behaviours) of resources (machines, equipment etc.) in the plant for the performance of a production step;

Definitions of equipment parameter ranges and other equipment specific production rules restricting operational flexibility;

Detailed static production scheduling information.


32



Title: The system SHOULD be maintainable

Description:

The system should be easily maintainable by someone who does not know the implementation details

in order to correct defects, meet new requirements, make future maintenance easier, or cope with a

changed environment.



Title: The design and implementation SHOULD be cost effective

Description:

The design of the production control system should be maintained at a minimum cost without

compromising performance.


3.2.4. Non-Functional Requirements on IT environment

Requirement ID: ITR- 1

Title: The system software MUST run on standard computational equipments

Description:

The software production control system must run on standard computational equipment using different

operating systems and connected by a network using a standard communication protocol.


33



Title: The system MUST have the ability to work in a network based environment

Description:

The system must have the ability to work in a network-based environment and to communicate with

each part of the system itself and with other (external) systems that are present in the same network

(e.g. LAN, VPN, Internet and Profibus).



Title: The system MUST use secure cross enterprise and/or location processing

Description:

The cross enterprise process interfaces of a production control system have to be secured, and the

shared information has to be IP (Intellectual Property) protected on each side.

Scope: Generic Author: SIEMENS Case study: No

34


References

Baker, A. (1998), “A Survey of Factory Control Algorithms which Can be Implemented in a Multi-

Agent Heterarchy: Dispatching, Scheduling and Pull”, Journal of Manufacturing Systems, vol. 17, n. 4,

pp. 297-320.

Camarinha-Matos, L.M. and Afsarmanesh, H. (1999), “Infrastructures for Virtual Enterprises: a

Summary of Achievements”, Proceedings of the PRO-VE’99 - IFIP International Conference on

Infrastructures for Virtual Enterprises, Camarinha-Matos, L. and Afsarmanesh, H. (eds), pp. 483-490,

Kluwer Academic Publishers.

Hall, K., Staron, R. and Zoitl, A. (2007), “Challenges to Industry Adoption of the IEC 61499

Standard on Event-based Function Blocks”, Proceedings of the 5th IEEE International Conference on

Industrial Informatics, Vienna, vol. 2, pp. 823-828.

ANSI/ISA-95.00.03 (2005), “Enterprise-Control System Integration Part 3: Activity Models of

Manufacturing Operations Management”, ISA - The Instrumentation, Systems, and Automation

Society.

Leitão, P. (2004), “An Agile and Adaptive Holonic Architecture for Manufacturing Control“, PhD

Thesis, University of Porto.

Leitão, P. (2009), “Agent-based Distributed Manufacturing Control: A State-of-the-art Survey”,

International Journal of Engineering Applications of Artificial Intelligence, vol. 22, n. 7, pp. 979-991,

Elsevier.

Leitão, P. and Restivo, F. (1999), “A Layered Approach to Distributed Manufacturing”,

Proceedings of Advanced Summer Institute International Conference in Life Cycle Approaches to

Production Systems: Management, Control and Supervision, Leuven, Belgium.

Report with the Requirements of Multi-Agent Architecture...

Documents

Transcript of Report with the Requirements of Multi-Agent Architecture...