Your SlideShare is downloading. ×
0
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
HPPS 2008 - Maesani Moro
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

HPPS 2008 - Maesani Moro

312

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
312
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ENHANCEMENTS PROPOSAL FOR AN AUTOMATED TEST-TUBES ANALYSIS SYSTEM High Performance Processors and Systems Project Presentation Andrea MAESANI Federico MORO Prof. Donatella SCIUTO Tutor: Prof. Marco Domenico SANTAMBROGIO June 19 th , 2008
  • 2. Inpeco
    • “ Inpeco is a leading player in the fast growing Clinical Laboratory Automation market and Life Sciences supply industry that specializes in the development, production, distribution and servicing of enabling solutions to improve the process and operations of the laboratory”
    • (source: www.inpeco.com)
  • 3. Inpeco system – description and limits
    • Typical problems of fully centralized systems:
      • Difficoult to face errors in one of the nodes or, even more serious, in the central server
      • Update, adding and removing of nodes complicated to be managed
  • 4. Proposed Architecture Local DB NODE
  • 5. Rationale
    • Aim
      • Improve system performance (aka maximize test-tubes throughput)
        • Identify limits and drawbacks of Inpeco’s architecture
    • Contributions
      • Propose a formal model for the network to:
        • Improve the network performance
        • Define the requirements for:
          • A runtime network controller
          • An offline network simultator to identify the best placement for each node
      • Design a novel architecture for the node to:
        • Speedup the updates in the node description to achieve future constraints/needs
        • Ennance future updates in the functionalities provided by the node
        • Support complex distributed systems to spread the computation and to distribute the network control over all the nodes
  • 6. What's next...
    • Network analysis
      • Problem description
      • New proposed system
      • Similar cases analysis
        • Mass Customization Manufacturing
        • Job Shop Scheduling Problem
        • Communication Systems
      • Proposed solution
        • Topology Definition
        • Scheduling Algorithm
    • Node case-study
    • Concluding remarks
  • 7. Network Description
    • Set of test-tubes divided into classes
    • Set of nodes , characterized by the operation they can perform (possibly more nodes performing the same operation), connected in a certain topology
    • Each test-tubes class requires to the system a well defined set of operations
  • 8. Similar Cases Analysis (1)
    • Mass Customization Manufacturing
      • Set of products
      • Each problem can be divided into fixed module
    • [1] Flexible Manufacturing System for Mass Customization Manufacturing – Guixiu Qiao, Roberto Lu, Charles McLean
    • Job Shop Scheduling Problem
      • Set of jobs divided into classes
      • Set of nodes , characterized by the operation they can perform (possibly more nodes performing the same operation), NOT connected in a certain topology
      • Each job class requires to the system a well defined set of operations
    • [2] Introduction to Job Shop Scheduling Problem – Qianjun Xu – 2001
    • [3] The Job Shop Scheduling Problem with setup times – Francis Sourd – 1998
    • [4] Heuristic Methods for Solving Job Shop Scheduling Problems – A. Garrido, M.A. Salido, F. Barber, M.A. Lopez
    • [5] Algorithms for the Job Shop Scheduling Problem – a comparison of different methods – J. Kaschel, T. Teich, G. Kobernik, B. Meier
  • 9. Similar Cases Analysis (2)
    • Communication Systems
      • Set of information unit divided into classes
      • Set of nodes , characterized by the operation they can perform (possibly more nodes performing the same operation), connected in a certain topology
    • [6] An Overview of the JMT Queueing Network Simulator – M. Bertoli, G. Casale, G. Serazzi
    • [7] Java Modelling Tools: an Open Source Suite for Queueing Network Modelling and Workload Analysis - M. Bertoli, G. Casale, G. Serazzi - 2006
  • 10. Similar Cases Analysis (3)
    • Mass Customization Manufacturing
      • Aim: formalization
    • Job Shop Scheduling Problem
      • No fixed network layout => explosion of possible states!
      • Their main problem consists in pruning possible paths in order to obtain a faster search
    • Communication Systems
      • Need to send information from a certain point to another through a network => no need to pass through some defined nodes
  • 11. Proposed Solution (1)
    • The topology of the network is defined offline basing:
    • on statistical data
    • on information collected during a training time
    • Online system performance analysis may then eventually suggest later updates
    TOPOLOGY DEFINITION
  • 12. Proposed Solution (2)
    • Define all possible paths from current node to final node (-> n paths) – main difference from JSS
    • Define which of these (n) satisfy the requirements of the current test-tube (-> m paths =< n) – main difference from communication systems
    • Define which of these (m) is the optimal path – to improve performances :
      • Shortest time until next required operation in performed
      • Shortest time until the test-tube exits the system
    SCHEDULING ALGORITHM
  • 13. Proposed Solutions (3)
    • How to define the time until the test-tube exits the system?
    • Where:
    • time to pass through the node
    • queue time
    • time to move from one node to another
  • 14. Addictional Remarks
    • The system descripted also garantees:
    • TOPOLOGY UPDATE : all the modules are aware of changes in the topology of the system; this way all the scheduling decisions taken from update on will base on the new topology
    • TRACKING and ERROR DETECTION : knowledge of topology and test-tube passage memorization permit to track the movements and eventually to identify the exact point where an error has occurred
  • 15. What's next...
    • Network analysis
    • Node case-study
      • Actual node architecture
      • Node problems
      • Proposed solution
      • Demonstrative architecture
        • Target devices
        • Linux over FPGA
        • Results
    • Conclusion
  • 16. Inpeco's system: Node Architecture
  • 17. Inpeco's system: Node Problems (1)
    • Single point of failure
      • A central server controls all the nodes
    • Development time and cost of nodes
      • Actually based on ASIC
        • Design
        • Simulation
        • Synthetize HW (external manufacturers)‏
        • Test
  • 18. Inpeco's system: Node Problems (2)
    • Expansions and upgrades
      • Module-based system
        • limited number of add-ons
      • ASIC
        • hard to adapt
      • Problem of standards
    • Faults detection and recovery
      • Faults
        • Manual procedures to find faults
        • Very time-consuming -> entire plant stopped for tests
      • On-site intervention needed
  • 19. Proposed Solution
    • An FPGA based device can solve many of these problems
    • Single Point of failure
      • Distributed System -> Linux on FPGA
    • Easy upgrades / expansions
      • Reconfiguration
      • Stackable Boards
    • Reduce development time and cost
      • FPGA design cycle
    • Fault tolerance and fault detection
      • TMR
      • Radiation hardened devices
      • Feedback of outputs
  • 20. Node generic architecture
    • Basic functionalities to achieve
      • Support for complex distributed systems
        • Linux
      • Network connection
        • Ethernet
      • Manipulation of local HW from remote
        • Simple client-server software to switch LEDs on/off
      • Internal reconfiguration
        • DRESD ICAP controller
  • 21. Target devices
    • Avnet VP7 Evaluation Board
      • PowerPC hard-processor ( PPC 405 @ 300 MHz )‏
      • μCLinux (2.4 kernel) + ELDK
      • Excellent support from Avnet (drivers...)‏
    • XUP VP30 Development Board
      • Xilinx soft-processor (Microblaze @ 100 MHz)‏
      • PetaLinux (2.6 kernel) + Petalogix
      • Lacks of drivers -> only used petalinux drivers
  • 22. Linux 2.6: PetaLogix Toolchain 1. Synthetize HW -> Bitstream 3. Build Libraries for PetaLinux 4. Configure kernel and compile -> image.bin (filesystem+kernel) 5. Download the Bitstream and the software image 2. Manual setup Kernel autoconfiguration (petalinux-autoconfig)‏ Import in PetaLinux (petalinux-new-platform)‏
  • 23. Results (Avnet)
    • Completely functional architecture on Avnet board
      • Httpd server
      • Sample client-server demonstrative software
        • Works!
      • Internal reconfiguration (smallbit)‏
        • Simply switches on/off LEDs
  • 24. Results (XUP)
    • Partially working node architecture (kernel 2.6)‏
      • Fully working Linux distribution on the board
      • Clock skew impact directly on Ethernet performances
        • Partially works ( 10% packet loss on the network )‏
      • Internal reconfiguration
        • Need Port the ICAP kernel module to 2.6 kernel
      • Sample client-server demonstrative software
        • Works! (sometimes does not -> remember the Ethernet problems)‏
  • 25. Results – area requirements Microblaze DDR Controller Ethernet EMAC controller OPB 2 PLB Bus UART Controller VP7 Device VP30 Device VP30 IP-Cores area occupation
  • 26. Conclusions
    • Inpeco has a starting point to decide if take into account FPGA devices for future development
      • FPGA devices can help to solve some of their problems
      • The proposed network design guarantees an improvement in performances, is much more flexible and error tolerant
      • Advantages of reconfigurable hardware
    • Demonstrative architecture
      • Complete Operating system with network support on a FPGA device
      • Software can greatly reduce development effort
      • Create very complex systems using a relatively simple node
  • 27. Questions?
    • Thank you!

×