diploma thesis performance evaluation of a decentral ... · control through distributed data...

Tobias Mayer | Passau, 11.12.2008

Performance Evaluation of a Decentral Material FlowControl through Distributed Data Acquisition

Diploma Thesis


Agenda

IntroductionThe Way to Performance EvaluationMaterial Flow Control Packet RoyaleTheoretical PreparationMonitoring-System Monitor RoyaleResults


Vision in Logistics: Internet of Things

Current situationGoods in logistics are „stupid“ (no intelligence), only identificationComplex control system needed

Internet of thingsMain features of goods

Have all information needed for transportIntelligent, selfcontrollingCommunicate/cooperate with others

Complexity fully distributedComplex overall control system not needed anymoreOnly for serving local control demands of

Flexible as the network infrastructure of the internet

[http://www.internet-of-things.net]

4 of 35


Material Flow System at the Chair

5 of 35


Material Flow System at the Chair

[ Diploma ThesisM. Heinemann ]

6 of 35


Common Control Systems (centralized)

Good performance (e.g. conveyor speed up to 10 meter per second)Specialized hardware expensiveHierarchically structured

If one system fail, the subsystems as well

Most control software lack of modularitycustom-builts

Installation and tuning is expensiveNot flexible, changing control softwareonly with great effort

7 of 35


Control Systems in Research (decentralized)

Many possible architectures, still no standardizationCharacteristics

Modular/reusable designFlat hierarchy collaborationFlexibilityPlug‘n‘Play

Flexibility needs more communicationloss of speed

Becoming more popular in logistics: agent-based systems

8 of 35


Agenda



Our Way to Logistics

Projectgroup 475Part of study12 studentsDuration: 2 semester

ResultsDecentral material flow controlRoasted KitOnly standard-technologies

Ethernet, Web ServicesPCs with x86-architecture

10 of 35


Cooperative Diploma Theses

S. Feldhorst Development of the decentral material flow controlPacket Royale using mobile agents

J. Konieczny Emulation of the processes of a material flow systemM. Heinemann Visualisation of a distributed technical system exam-

plary at Packet RoyaleM. Fiedler Safeguarding AutoID devices in a service-based

material flow control (still in progress)

This work Performance evaluation and analysis of the material flow control Packet Royale

S. Liekenbrock Technical support (some seminar paper)

11 of 35


Goals of This Work

Similar achievementsExtensive investigation – no performance information could be foundfor distributed control systems

Technical system not availableDevelopment of a (decentral) control system expensiveLack of standards for development

Goals1. An analysis to reveal general problems and performance values2. Supplying measured data for use in further analytical models

in particular Realtime-Logistics-Model (Libert and ten Hompel, 2007)

12 of 35


Structured Procedure of Evaluation (Jain, 1991)

1. Define goals and system boundings2. List funktionalities3. List performance metrics4. List performance affecting parameters5. Determine parameters to be varied (factors)6. Choose evaluation method7. Define workload8. Design und perform experiment9. Analysis und interpretation of gathered data10.Presentation of results

13 of 35


Agenda



Material Flow Control Packet Royale

Conveying system (passive) offers control services through IPCsSoftwareagents (active) uses control servicesWhole communication with web servicesConfigDevice provides conveyor descriptionsComputationDevice (CD) as runtime environment for agents

started as independet processFlexible architecture

Centralised structur (all agents in one CD)Completely decentral (one agent per CD)

Cycle-oriented operation of AgentsCheck sensor statesCalculate decisionPerform decision by using control services

15 of 35


Control Topology of Packet Royale

Logically equal assignmentOne control service on each IPC for controlling connectedconveyorsOne ComputationDevice per IPC

Contains agents for thoseconveyors that are connected to the dedicated IPCOne agent for each conveyor

All ComputationDevices on onecomputer

Only for ease of use while testingTo achive physically distributedsystem, start it distributed

16 of 35


Agenda



Metrics of Performance Evaluation

General Load Information CPUMemoryNetwork

Indicator of Performance:local reaction time (lrt)

Time used to recognize the needof a control decision, calculateand perform it without technicalimplementationslrt = agent cycle time

18 of 35


Closer Look to Local Reaction Time

19 of 35


Design of Experiment:Data Acquisition of General Load Information

20 of 35


Design of Experiment:Data Acquisition of Local Reaction Time

Data acquisition by extending control software Packet Royale

21 of 35


Places of Data Acquisition

General load informationOn all computers (IPCs, agent computer)

Local Reaction Times On all computers

Analysis only for conveyor U1Other values for possible further analysisAgents of conveyor U1 (and U8) have mostwork upper bound of lrt

22 of 35


An Overview to Workload Scenarios

Two types of scenariosChanging count of activecontrol instances(agents, services)

Changing workload(count of packets)

Szenario 0: Monitor Royale load values

Szenario 1: System in idle state

Szenario 2: Conveyor count increase

Szenario 3: Conveyor count decrease

Szenario 4: Switch conveyor

Szenario 5: Merging conveyor

Szenario 6: Scalability

23 of 35

OR


Workload Scenario Details

Scenario 1Whole control system started

All control services activeAll agents instantiated

No packet transport

Scenario 6Whole control system started

All control services activeAll agents instantiated

Simultaneously transport of 12 packetsTime of monitoring: 300 sec.

24 of 35


Choose Evaluation Method

Possible evaluation methodslAnalyticSimulativeMeasurement of real system(monitoring)

hardware monitorsoftware monitor

Requirements for monitoring systemAcquisition of load information

SystemEach active process

Low footprint (cpu, memory)Availability of measured data throughnetwork or datafileInterface for individual informationUsabilitydevelopment own piece of software

25 of 35


Agenda

IntroductionThe Way to Performance EvaluationMaterial Flow Control Packet RoyaleTheoretical PreparationMonitoring-System Monitor RoyaleResults and Conclusion


Own Development: Software-Monitor Monitor Royale

Written in C++ (Linux-/Unix)Two components

MonitoringAgent – Data AcquisitionEvaluationStation – Postprocessing and visualization

Communication over ethernet (xmlrpc)Loose coupling (m-n-relation)Generic applicabilityUsage of text files(configuration and data)Easy to useOpenSource (Sourceforge)http://monitorroyale.sf.net

27 of 35


Examples of usability of MonitoringAgentColorized log

Readability comparison of configuration filesKey-Value structure usedby Monitor Royale (left)XML (right)

28 of 35


Agenda



Szenario 1 (Idle State)CPU- / Memory Load of Agent Computer

Performance of Agentcomputer: Pentium-M 1866 MHz, 1024MB RAM

30 of 35


Szenario 6 (12 Packets)CPU- / Memory Load of Agent Computer

Performance of Agentcomputer: Pentium-M 1866 MHz, 1024MB RAM

31 of 35


Szenario 6 (12 Pakete)Network Load of Agent Computer

32 of 35


Szenario 6: Local Reaction Times for Conveyor U1

minimum 61 msmaximum 522 msaverage 173 ms

33 of 35


Conclusion

Packet Royale scales goodDepends on sensor events (ws calls)„low cpu load“ (despite usage of java) - total distribution possible

Local Reaction TimePrototype performance acceptableProcess near operation optimizes lrt

Web ServicesBad performance (de-/marshalling generates cpuload)Modularizing of control system itself

Note: Results only hints for performance of distr. controls of similar architectureDifferent controls may have different performance

34 von 35


Thank you for listening.Any questions?

diploma thesis performance evaluation of a decentral ... · control through distributed data...

Documents