DOCSLIB.ORG

Chapter 3 AXIS 207W Network Camera

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Chapter 3 AXIS 207W Network Camera Master of Science Thesis Department of Computer Science Lund Institute of Technology Implementing the PalCom protocol in an Axis network camera Brice Jaglin <[email protected]> Boel Mattsson <[email protected]> January 2007 Master of Science in Computer Science Engineering Supervisors: David Svensson, Lund Institute of Technology Daniel Elvin, Axis Communications, Lund Examiner: Boris Magnusson, Lund Institute of Technology Abstract The thesis goal was to implement the PalCom protocol in a network camera, in order to offer the camera’s existing features via the PalCom architecture. A pro- totype has been successfully developed in C, showing that it is possible to port the PalCom communication model into an embedded device. PalCom is a research project with the goal to integrate computation in our day- to-day life. It aims at improving the user experience by easing communication between electronic devices. A way to achieve this is to develop a flexible archi- tecture that can facilitate interaction and communication between independent systems. A communication model is being designed within the PalCom project, and several PalCom-compliant emulated devices have already been developed within a Java implementation. The AXIS 207W network camera is a commercial product used mainly for video surveillance. Thanks to its fully-documented API and its Linux embedded sys- tem, it is an open system, very suitable for developers to extend. Keywords: PalCom, Palpable Computing, Axis, Implementation, C, Server. Acknowledgements First of all, we would like to thank the people involved in the PalCom project at LTH, Boris Magnusson and David Svensson for introducing us to the PalCom project and listening to our suggestions. Sven Gestegård Robertz answered our questions about thread design. We also wish to thank Axis Communications for lending the 207W network cam- era. Our supervisor at Axis, Daniel Elvin, introduced us to the workings of the camera and finally solved the mysterious four fragment problem. A special thank goes to Kristina Sten who though not appointed as supervisor answered our questions well and helped us forward when we were stuck. ii Contents 1 Introduction 1 1.1 Intended readers . 1 1.2 Internet resources . 2 1.3 Report outline . 2 2 PalCom 3 2.1 Overview . 3 2.1.1 A Scenario - major traffic accident . 4 2.1.2 Possible use of Axis camera in major traffic accident . 5 2.2 PalCom architecture . 5 2.2.1 Devices . 6 2.2.2 Discovery . 7 2.2.3 Services . 7 2.2.4 Connections . 8 2.2.5 Information exchanged . 9 2.2.6 The x-palcom-control MIME type . 9 2.2.7 Assemblies . 9 2.3 Communication model . 10 2.3.1 Network . 10 2.3.2 Message format . 11 3 AXIS 207W Network Camera 15 3.1 Overview . 15 3.2 Features . 15 3.2.1 Network camera . 15 3.2.2 Image features . 16 3.2.3 Web server user interface . 16 3.2.4 Triggers and services . 17 3.3 Technical aspects . 17 3.3.1 Hardware . 17 3.3.2 Software . 18 3.3.3 API . 18 4 A PalCom server prototype on the AXIS 207W 21 4.1 Services . 21 4.1.1 PingService . 22 4.1.2 PictureService . 23 4.1.3 TimeService . 24 4.1.4 MJpegService . 25 i Contents 4.1.5 TriggerService . 26 4.2 PalCom implementation . 27 4.2.1 Discovery . 27 4.2.2 Selectors . 27 4.2.3 Connections . 28 4.2.4 Timeouts . 28 4.3 Module architecture . 28 4.3.1 PalCom base modules . 28 4.3.2 Services modules . 32 4.3.3 VAPIX module . 33 4.4 Thread architecture . 33 4.4.1 Inter-process communication . 33 5 Development 35 5.1 Testing . 35 5.1.1 Debugging . 36 5.1.2 Valgrind . 36 5.2 Design choices . 36 5.2.1 Camera-specific features . 36 5.2.2 Video features . 37 5.3 Impact of the prototype development on the PalCom protocol . 38 5.3.1 Improvements . 38 5.3.2 Open issues . 39 5.4 Evaluation . 41 5.4.1 Developing a server for an AXIS Camera . 41 5.4.2 PalCom in a small device . 41 6 Conclusions 43 6.0.3 Evaluation of the prototype . 43 6.0.4 Comparison with the built-in HTTP server . 43 6.1 Future work . 44 6.1.1 Maintaining the prototype . 44 6.1.2 Alternative implementation based on PalVM . 44 6.1.3 Reusing the prototype’s PalCom modules . 44 6.1.4 Develop an MPEG4 service . 44 A User Manual 45 A.1 AXIS 207W Quick Guide . 45 A.1.1 Hardware Overview . 45 A.1.2 Network . 46 A.1.3 HTTP server and root password . 47 A.2 Install the PalCom server . 47 A.2.1 Requirements . 47 A.2.2 Step by step . 47 A.3 Using the services . 48 A.3.1 Ping Service . 48 A.3.2 Time Service . 49 A.3.3 Picture Service . 49 A.3.4 MJPEG Service . 52 A.3.5 Trigger Service . 53 A.4 Known limitations . 55 ii Contents B How to reuse our code for another PalCom server 57 B.1 Active and passive services . 57 B.1.1 Passive services . 57 B.1.2 Active services . 57 B.2 Check-list . 58 C How to develop on the camera and tools needed 59 C.1 Build the ARM cross compiler on your host . 59 C.2 Cross compilation . 59 C.3 Transfer a file to the camera . 60 C.4 Telnet . 60 D Tools used 61 D.1 Libraries used . 61 D.1.1 XML-parser: Expat . 61 D.1.2 Pthreads . 61 D.2 Software used . 62 D.2.1 Eclipse SDK . 62 D.2.2 Doxygen . 63 iii Chapter 1 Introduction The aim of this project is to see if it is possible to implement the PalCom protocol in a small device. From a PalCom perspective, this project was about showing if it is possible to port the PalCom communication model into an embedded de- vice. From another perspective, this project is about implementing an alternative way to set up and control the Axis camera as opposed to using the built-in web interface. PalCom is an ongoing European research project aiming at integrating computa- tion in our day-to-day life. This is achieved by developing a flexible architecture for interaction and communication between electronic devices. What makes Pal- Com special is that it focuses on unplanned connections. The protocol is designed so that devices not previously thought of to have a need to communicate should be able to do so when the need arises. A number of emulated devices have al- ready been developed and implemented in Java. The AXIS 207W network camera is developed by Axis Communications in Lund and is mainly used for surveillance. It is an open system with publicly docu- mented API, and has Linux as operating system. It is thus very suitable for non Axis people to develop and extend. 1.1 Intended readers The report is intended to have several categories of readers. This section describes what you should read depending on your background and/or your motivation. Computer Scientist, Student You have a Master of Computer Science or equiv- alent, and you are interested in new perspectives to facilitate connections between devices, and the way it could be implemented. You should read chapters 2, 3, 4, and 6. You can also be interested in Chapter 5 and Appendix D if you want to know more about the development. PalCom User You have already used other PalCom devices and want to use an AXIS 207W camera with them. You should read Appendix A. Chapter 3 is also relevant if you want to know more about the camera. 1 Chapter 1. Introduction AXIS 207W User You are familiar with the AXIS 207W network camera, and you want to explore the possibilities offered by the PalCom server. Start by read- ing Chapter 2 and Appendix A. PalCom Developer You are familiar with the PalCom communication model and you want to understand how the C implementation works. Please read Chapter 4, 5, 6. Appendix B will be also valuable if you want to port the implementation to another device. 1.2 Internet resources You can find this report, as well as the source code and other useful information at http://www.lucas.lth.se/axis-palcom/. 1.3 Report outline The report is structured as follows: Chapter 2, PalCom gives an overview of the PalCom protocol. Chapter 3, Axis 207W Network camera describes the Axis camera. Chapter 4, A PalCom server prototype on.
Load more

Recommended publications
  • Comparison of Contemporary Real Time Operating Systems
    ISSN (Online) 2278-1021 IJARCCE ISSN (Print) 2319 5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 4, Issue 11, November 2015 Comparison of Contemporary Real Time Operating Systems Mr. Sagar Jape1, Mr. Mihir Kulkarni2, Prof.Dipti Pawade3 Student, Bachelors of Engineering, Department of Information Technology, K J Somaiya College of Engineering, Mumbai1,2 Assistant Professor, Department of Information Technology, K J Somaiya College of Engineering, Mumbai3 Abstract: With the advancement in embedded area, importance of real time operating system (RTOS) has been increased to greater extent. Now days for every embedded application low latency, efficient memory utilization and effective scheduling techniques are the basic requirements. Thus in this paper we have attempted to compare some of the real time operating systems. The systems (viz. VxWorks, QNX, Ecos, RTLinux, Windows CE and FreeRTOS) have been selected according to the highest user base criterion. We enlist the peculiar features of the systems with respect to the parameters like scheduling policies, licensing, memory management techniques, etc. and further, compare the selected systems over these parameters. Our effort to formulate the often confused, complex and contradictory pieces of information on contemporary RTOSs into simple, analytical organized structure will provide decisive insights to the reader on the selection process of an RTOS as per his requirements. Keywords:RTOS, VxWorks, QNX, eCOS, RTLinux,Windows CE, FreeRTOS I. INTRODUCTION An operating system (OS) is a set of software that handles designed known as Real Time Operating System (RTOS). computer hardware. Basically it acts as an interface The motive behind RTOS development is to process data between user program and computer hardware.
    [Show full text]
  • Software De Sistemas Introduccion
    SOFTWARE DE SISTEMAS INTRODUCCION • EL CONCEPTO DE SOFTWARE VA MAS ALLA DE LOS PROGRAMAS DE COMPUTACION EN SUS DISTINTOS ESTADOS QUE ABARCA TODO LO INTANGIBLE RELACIONADO Algodesl.wordpress.com t i ¿QUE ES? p o s d e s o f t w a r e . c o m • Parte esencial para clasificar sistemas operativos • Conocido como software base • Conjunto de programas de software que permite interactuar con el hardware y operarlo junto con configuraciones y funciones de entrada y salida ¿Que hace? • Permite utilizar sistema operativo e informático, incluyendo herramientas de diagnostico • Su propósito es aislar un programa o hardware de aplicaciones tanto como sea posible proyectoova.webcindario.com Ejemplos de programas de software de sistema a d • Potenciales ejemplos: r ia n ▪ cargadores a l is s e ▪ Enlazadores t .b lo ▪ Utilidad de software g s p o ▪ Interfaz grafica t ▪ Celdas ▪ Bios ▪ Hipervisores ▪ Gestores de arranque losejemplos.com *si el software del sistema se almacena en memoria volátil se denomina firware Tipos • Como tal no existen varios tipos de software de sistema pero se pueden dividir en 3; O k • Sistema operativo h o s • t Controladores i n g • . Programas de utilería c o m Tipos; SISTEMA OPERATIVO • Parte que se encarga de administración de hardware como los componentes de computadora y encargado de que todos se unan para funcionar en 1 solo objetivo m i n d 4 2 . c o m SISTEMAS OPERATIVOS • MICROSOFT WINDOWS ▪ Núcleo: monolítico (versiones basadas en MS­DOS) e hibrido (versiones basadas en Windows NT) ▪ Plataformas: ARM, arquitectura Intel, MIPS, Alpha, Power PC SISTEMAS OPERATIVOS • MAC OS ▪ Núcleo: XNU basado en mach y BSD, es tipo hibrido ▪ Plataformas; power PC SISTEMAS OPERATIVOS • LINUX: ▪ Núcleo: núcleo Linux ▪ Plataformas; DEC Alpha, ARM, POWER PC, superH, SPARC, ETRAX CRIS, MIPS, MN103… etc.
    [Show full text]
  • Improving Performance of Virtual Machines by Virtio Bridge Bypass
    www.ijecs.in International Journal Of Engineering And Computer Science ISSN:2319-7242 Volume 6 Issue 4 April 2017, Page No. 20931-20937 Index Copernicus value (2015): 58.10 DOI: 10.18535/ijecs/v6i4.24 Improving performance of Virtual Machines by Virtio bridge Bypass for PCI devices 1Shirley Kotian, 2Kirti Menon, 3Kirti Menon, 4Utsav Mundada, 5Neeraj Vilas Auti 1234PICT, 5PICT [CS] ABSTRACT Inspired by the Virtio module of virtualization, we propose an alternate method to directly communicate with PCI devices such as NIC without the use of any kernel modules. This method uses a specialized module written by us which will avoid the mechanism of bridges like the ones used in Virtio that increase latency. This module will be present in the userspace of the guest OS and we are specifically targeting the e1000 device for this purpose and later plan to make it generic for all PCI devices. Our motivation is to avoid unnecessary communication with the kernel which slows down the system. For the first step. we do resource mapping to map the PCI device memory into userspace. Then, we expose PCI configuration space through a userspace module using ACPI cables. Thus, we create a userspace PCI driver which will decrease the latency in access time and increase speed of execution. The applications in the Guest OS that request communication with the PCI devices will be redirected to our application. This will take some load off the kernel and reduce its overhead. Finally, we boot a VM that actually talks to our PCI device emulator. GENERAL TERMS Virtio, UPCI, e1000, QEMU, virt-manager, UIO.
    [Show full text]
  • Virtualization for Embedded Software
    JETS VIRTUALIZATION FOR EMBEDDED SOFTWARE Seasoned aerospace organizations have already weathered the VIRTUALIZATION WITH JETS: change from bespoke systems and proprietary languages to COTS A KEY ENABLER OF DEVOPS TRANSFORMATION and open-source, as well as paradigm shifts from high-overhead FOR AEROSPACE AND DEFENSE waterfall and spiral development models to lightweight and agile methodologies and are considering moving to scalable agile Like all companies in the technology industry, aerospace and defense methods. As with previous seismic shifts in the industry, most suppliers are facing increased pressure to reduce cost and increase defense and aerospace firms will have to follow, especially as best-of- productivity, while meeting their market’s demand for higher breed tools, talent and processes are all refactored to take advantage overall quality and rapid adoption of new platforms, development of DevOps’ unique productivity and quality improvements. DevOps paradigms and user experiences. is a collective term for a range of modern development practices that combines loosely-coupled architectures and process automation In recent years, the rapid pace of innovation for consumer tech, with changes to the structure of development, IT and product teams. together with a new generation of ‘digital native’ users that demand Adoption of DevOps (See Figure 1). more capability than previous generations, has left many in the industry playing constant catch-up. Adoption of DevOps includes a shift from long, structured release cycles to continuous delivery, and relies on heavy use of automation to improve productivity and quality. This can be complicated by The commercial software world is shifting again, several factors common to the defense and aerospace industry.
    [Show full text]
  • Essential Abstractions in GCC
    Essential Abstractions in GCC Uday Khedker (www.cse.iitb.ac.in/˜uday) GCC Resource Center, Department of Computer Science and Engineering, Indian Institute of Technology, Bombay 13 June 2014 EAGCC-PLDI-14 EAGCC: Outline 1/1 Outline • Compilation Models • GCC: The Great Compiler Challenge • Meeting the GCC Challenge: CS 715 The course plan Uday Khedker GRC, IIT Bombay Part 1 Compilation Models EAGCC-PLDI-14 EAGCC: Compilation Models 2/1 Compilation Models Aho Ullman Davidson Fraser Model Model Uday Khedker GRC, IIT Bombay EAGCC-PLDI-14 EAGCC: Compilation Models 2/1 Compilation Models Aho Ullman Davidson Fraser Model Model Front End Input Source Program AST Uday Khedker GRC, IIT Bombay EAGCC-PLDI-14 EAGCC: Compilation Models 2/1 Compilation Models Aho Ullman Davidson Fraser Model Model Front End Input Source Program AST Optimizer Target Indep. IR Uday Khedker GRC, IIT Bombay EAGCC-PLDI-14 EAGCC: Compilation Models 2/1 Compilation Models Aho Ullman Davidson Fraser Model Model Front End Input Source Program AST Optimizer Target Indep. IR Code Generator Target Program Uday Khedker GRC, IIT Bombay EAGCC-PLDI-14 EAGCC: Compilation Models 2/1 Compilation Models Aho Ullman Davidson Fraser Model Model Front End Input Source Program Front End AST AST Optimizer Target Indep. IR Code Generator Target Program Uday Khedker GRC, IIT Bombay EAGCC-PLDI-14 EAGCC: Compilation Models 2/1 Compilation Models Aho Ullman Davidson Fraser Model Model Front End Input Source Program Front End AST AST Expander Optimizer Register Transfers Target Indep. IR Code Generator Target Program Uday Khedker GRC, IIT Bombay EAGCC-PLDI-14 EAGCC: Compilation Models 2/1 Compilation Models Aho Ullman Davidson Fraser Model Model Front End Input Source Program Front End AST AST Expander Optimizer Register Transfers Target Indep.
    [Show full text]
  • GCC Plugins and MELT Extensions
    GCC plugins and MELT extensions Basile STARYNKEVITCH [email protected] (or [email protected]) June 16th 2011 – ARCHI’11 summer school (Mont Louis, France) These slides are under a Creative Commons Attribution-ShareAlike 3.0 Unported License creativecommons.org/licenses/by-sa/3.0 and downloadable from gcc-melt.org th Basile STARYNKEVITCH GCC plugins and MELT extensions June 16 2011 ARCHI’11 ? 1 / 134 Table of Contents 1 Introduction about you and me about GCC and MELT building GCC 2 GCC Internals complexity of GCC overview inside GCC (cc1) memory management inside GCC optimization passes plugins 3 MELT why MELT? handling GCC internal data with MELT matching GCC data with MELT future work on MELT th Basile STARYNKEVITCH GCC plugins and MELT extensions June 16 2011 ARCHI’11 ? 2 / 134 Introduction Contents 1 Introduction about you and me about GCC and MELT building GCC 2 GCC Internals complexity of GCC overview inside GCC (cc1) memory management inside GCC optimization passes plugins 3 MELT why MELT? handling GCC internal data with MELT matching GCC data with MELT future work on MELT th Basile STARYNKEVITCH GCC plugins and MELT extensions June 16 2011 ARCHI’11 ? 3 / 134 Introduction about you and me opinions are mine only Opinions expressed here are only mine! not of my employer (CEA, LIST) not of the Gcc community not of funding agencies (e.g. DGCIS)1 I don’t understand or know all of Gcc ; there are many parts of Gcc I know nothing about. Beware that I have some strong technical opinions which are not the view of the majority of contributors to Gcc.
    [Show full text]
  • Design and Implementation of a Hypervisor-Based Platform for Dynamic Information Flow Tracking in a Distributed Environment by A
    Design and Implementation of a Hypervisor-Based Platform for Dynamic Information Flow Tracking in a Distributed Environment by Andrey Ermolinskiy A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the GRADUATE DIVISION of the UNIVERSITY OF CALIFORNIA, BERKELEY Committee in charge: Professor Scott Shenker, Chair Professor Ion Stoica Professor Deirdre Mulligan Spring 2011 Design and Implementation of a Hypervisor-Based Platform for Dynamic Information Flow Tracking in a Distributed Environment Copyright c 2011 by Andrey Ermolinskiy Abstract Design and Implementation of a Hypervisor-Based Platform for Dynamic Information Flow Tracking in a Distributed Environment by Andrey Ermolinskiy Doctor of Philosophy in Computer Science University of California, Berkeley Professor Scott Shenker, Chair One of the central security concerns in managing an organization is protecting the flow of sensitive information, by which we mean either maintaining an audit trail or ensuring that sensitive documents are disseminated only to the authorized parties. A promising approach to securing sensitive data involves designing mechanisms that interpose at the software-hardware boundary and track the flow of information with high precision — at the level of bytes and machine instructions. Fine-grained information flow tracking (IFT) is conceptually simple: memory and registers containing sensitive data are tagged with taint labels and these labels are propagated in accordance with the computation. However, previous efforts have demonstrated that full-system IFT faces two major practi- cal limitations — enormous performance overhead and taint explosion. These challenges render existing IFT implementations impractical for deployment outside of a laboratory setting. This dissertation describes our progress in addressing these challenges.
    [Show full text]
  • Challenges in Firmware Re-Hosting, Emulation, and Analysis
    Challenges in Firmware Re-Hosting, Emulation, and Analysis CHRISTOPHER WRIGHT, Purdue University WILLIAM A. MOEGLEIN, Sandia National Laboratories SAURABH BAGCHI, Purdue University MILIND KULKARNI, Purdue University ABRAHAM A. CLEMENTS, Sandia National Laboratories System emulation and firmware re-hosting have become popular techniques to answer various security and performance related questions, such as, does a firmware contain security vulnerabilities or meet timing requirements when run on a specific hardware platform. While this motivation for emulation and binary analysis has previously been explored and reported, starting to either work or research in the field is difficult. To this end, we provide a comprehensive guide for the practitioner or system emulation researcher. We layout common challenges faced during firmware re-hosting, explaining successive steps and surveying common tools used to overcome these challenges. We provide classification techniques on five different axes, including emulator methods, system type, fidelity, emulator purpose, and control. These classifications and comparison criteria enable the practitioner to determine the appropriate tool for emulation. We use our classifications to categorize popular works in the field and present 28 common challenges faced when creating, emulating and analyzing a system, from obtaining firmwares to post emulation analysis. CCS Concepts: • Computer systems organization → Embedded and cyber-physical systems; Firmware; Embedded hardware; Embedded software; Real-time systems; • Hardware → Simulation and emulation. Additional Key Words and Phrases: Firmware re-hosting, system emulation, embedded systems, emulation fidelity, emulator classification, binary analysis, reverse engineering, emulation challenges ACM Reference Format: Christopher Wright, William A. Moeglein, Saurabh Bagchi, Milind Kulkarni, and Abraham A. Clements. 2020. Challenges in Firmware Re-Hosting, Emulation, and Analysis.
    [Show full text]
  • The Design and Implementation of Gnu Compiler Generation Framework
    The Design and Implementation of Gnu Compiler Generation Framework Uday Khedker GCC Resource Center, Department of Computer Science and Engineering, Indian Institute of Technology, Bombay January 2010 CS 715 GCC CGF: Outline 1/52 Outline • GCC: The Great Compiler Challenge • Meeting the GCC Challenge: CS 715 • Configuration and Building Uday Khedker GRC, IIT Bombay Part 1 GCC ≡ The Great Compiler Challenge CS 715 GCC CGF: GCC ≡ The Great Compiler Challenge 2/52 The Gnu Tool Chain Source Program gcc Target Program Uday Khedker GRC, IIT Bombay CS 715 GCC CGF: GCC ≡ The Great Compiler Challenge 2/52 The Gnu Tool Chain Source Program cc1 cpp gcc Target Program Uday Khedker GRC, IIT Bombay CS 715 GCC CGF: GCC ≡ The Great Compiler Challenge 2/52 The Gnu Tool Chain Source Program cc1 cpp gcc Target Program Uday Khedker GRC, IIT Bombay CS 715 GCC CGF: GCC ≡ The Great Compiler Challenge 2/52 The Gnu Tool Chain Source Program cc1 cpp gcc as Target Program Uday Khedker GRC, IIT Bombay CS 715 GCC CGF: GCC ≡ The Great Compiler Challenge 2/52 The Gnu Tool Chain Source Program cc1 cpp gcc as ld Target Program Uday Khedker GRC, IIT Bombay CS 715 GCC CGF: GCC ≡ The Great Compiler Challenge 2/52 The Gnu Tool Chain Source Program cc1 cpp gcc as glibc/newlib ld Target Program Uday Khedker GRC, IIT Bombay CS 715 GCC CGF: GCC ≡ The Great Compiler Challenge 2/52 The Gnu Tool Chain Source Program cc1 cpp gcc as GCC glibc/newlib ld Target Program Uday Khedker GRC, IIT Bombay CS 715 GCC CGF: GCC ≡ The Great Compiler Challenge 3/52 Why is Understanding GCC Difficult? Some of the obvious reasons: • Comprehensiveness GCC is a production quality framework in terms of completeness and practical usefulness • Open development model Could lead to heterogeneity.
    [Show full text]
  • Comparative Study of Virtual Machine Software Packages with Real Operating System
    Master Thesis Electrical Engineering June 2012 Comparative Study of Virtual Machine Software Packages with Real Operating System Arunkumar Jayaraman Pavankumar Rayapudi School of Computing Blekinge Institute of Technology 371 79 Karlskrona Sweden This thesis is submitted to the School of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering. The thesis is equivalent to 20 weeks of full time studies. Contact Information: Author: Arunkumar Jayaraman E-mail: [email protected] Author: Pavankumar Rayapudi E-mail: [email protected] University Advisor: Prof. Lars Lundberg School of Computing Blekinge Institute of Technology Email: [email protected] University Examiner: Dr. Patrik Arlos School of Computing Blekinge Institute of Technology Email: [email protected] School of Computing Internet : www.bth.se/com Blekinge Institute of Technology Phone : +46 455 38 50 00 371 79 Karlskrona Fax : +46 455 38 50 57 Sweden i i ABSTRACT Virtualization allows computer users to utilize their resources more efficiently and effectively. Operating system that runs on top of the Virtual Machine or Hypervisor is called guest OS. The Virtual Machine is an abstraction of the real physical machine. The main aim of this thesis work was to analyze different kinds of virtualization software packages and to investigate their advantages and disadvantages. In addition, we analyzed the performance of the virtual software packages with a real operating system in terms of web services. Web Servers play an important role on the Internet. The response time and throughput for a web server are different for different virtualization software packages and between a real host and a virtual host.
    [Show full text]
  • Raspberry Pi Based Hazardous Environment Monitoring Using Wireless Communication
    ITSI Transactions on Electrical and Electronics Engineering (ITSI-TEEE) _______________________________________________________________________________________________ Raspberry Pi Based Hazardous Environment Monitoring Using Wireless Communication 1Nivedha.S, 2Shambavi.P, 3Abhirami.N, 4Jyothi.A.P, 5Darwin Britto.R 1,2,3,4,5Dept of ECE, RRCE, Bangalore using RS232 and also the transmissions is on both Abstract-This paper presents a hazardous environment monitoring and control for monitoring information directions which mean the inverted logic is also handled concerning safety and security, using wireless sensor with the same. RS232 uses MARK (negative voltage) network (WSN) with Raspberry Pi technology and the and SPPACE (positive voltage) as two voltage states. So concept of implementation is described in the context of the the baud rate is identical to the maximum number of bits industrial safety monitoring scenario. The deployed transmitted per second including the control bits. The wireless sensor network is used to perform data acquisition transmission rate of the device is 9600 baud with the with focus on several parameters like current, voltage, duration of start bit and each subsequent bit is about temperature, fire, poisonous gas leakage and water level. 0.104ms. The complete character frame of 11 bits is The advanced system for process management via a credit transmitted in 1.146ms. MAX 232 IC mountedon the card sized single board computer called Raspberry Pi based multi parameter monitoring hardware system master board converts the 0’s and 1’s to TTL logic. designed using RS232 and microcontroller that measures ZigBee frequency range is 2.4 GHz, These devices can and controls various hazardous parameters. The system transmit data over long distances by passing data comprises of a single master and single slave with wireless through a mesh network of intermediate devices to reach mode of communication and a Raspberry Pi system that can operate on Linux operating system.
    [Show full text]
  • DMA Processor
    2001:275 MASTER'S THESIS DMA processor Axel Meijer Civilingenjörsprogrammet Datateknik Institutionen för Systemteknik Avdelningen för Datorteknik 2001:275 • ISSN: 1402-1617 • ISRN: LTU-EX--01/275--SE MASTER'S THESIS DMA processor Axel Meijer [email protected] Department of Computer Science and Electrical Engineering Luleå University of Technology, Sweden September 2001 Examiner: Per Lindgren Department of Computer Science and Electrical Engineering Luleå University of Technology Supervisor: Jan Bengtsson Axis Communcations Lund, Sweden Abstract The DMA (Direct Memory Access) controller, is often a non-programmable hard- ware. As new peripheral interfaces are introduced there is often a need to change the DMA operation and therefore the design of the DMA controller. Changing the design of the DMA controller is often expensive and time-consuming. Instead, a fully programmable DMA processor can alter the behaviour by simply changing a control program. This paper describes an approach for a programmable DMA processor for a future ETRAX processor developed by Axis Communications. To reach the design solu- tion, different instruction set architectures were simulated and investigated. The result is a fully programmable DMA processor with one RISC core and several burst controllers that handles the data transfers. It can transfer data in parallel with up to 16 channels. The DMA processor is able to work with 1 Gbit/s full duplex Ethernet when the DMA processor is running at 100 MHz. The program that con- trols the DMA operations is stored in a local instruction memory of the DMA proc- essor. When synthesized with 0.25 µm technology, the DMA controller has a 160 000 gate foot print without the instruction memory.
    [Show full text]