Operating System Concepts Assignment # 01 Submitted to: Sir Dr.

Adnan Ahmad Submitted by:

Usman Maqbool BCE-SP11-051 Abdul Rehman Zafar BCE-SP11-002 Shehzad Akram Bilal Javed Ali Raza BCE-SP11-042 BCE-SP11-029 BCE-SP11-059

1:What is the purpose of the paper? ANS:Following are the purposes of the paper:First researchers and developers introduced the new home technology that uses Pc like abstraction,and they advocate for a PC-like abstraction The research paper revolves around an operating system called HomeOS that runs on a dedicated PC to control all the devices in a home network. Secondly the researchers tried to explain the architecture and design of the HomeOS and the challenges faced by the Home technology like application development, incremental growth and management. finally they presented the results and user response who implemented this Home technology in their homes. 2:- What is the hypothesis that the authors are testing? Ans:- The hypothesis that the authors are testing is that they want to develop a system that can control all the devices of the home network with a single dedicated central pc so that they can make easy to maintain and controll the devices of the home. According to research paper of Microsoft, They did a lot of work on it and in this matter they done many experiments. Basically home operating system is an implementation of the architecture as a component-based operating system. Experimental set up contains modules, services, home store, management task and implementations. Q3:What is the experimental setup? Ans: To gather performance data about Home Operating System, we ran a simple benchmarking application using a virtual device on a quad-core Intel Xeon 2.67 GHz PC. Unless otherwise specified, there is one application and one driver running. The application generates load by creating ten continuous tasks that attempt to invoke an operation on the device at a fixed rate, but are scheduled by .NET Thread Pool which dynamically picks a number of threads to execute based on current performance. According to research paper of Microsoft, They did a lot of work on it and in this matter they done many experiments. Basically home operating system is an

implementation of the architecture as a component-based operating system. Experimental set up contains modules, services, home store, management task and implementations. All functionality that is not central to the platform is implemented by software components called modules. In operating system for home, modules that are in the application layer are applications, and those that in the Device Connectivity Layer and Device Functionality Layer are drivers. Modules are the basic unit of functionality in Home Operating System

and, whether applications or drivers, they implement the API described below. Start: Called to start a module; modules are garbage collected when it returns Stop: Called to request a module to stop; where state can be cleaned up before exit SvcRegistered: Called when a new service becomes active; used to listen for services of interest SvcDeregistered: Called when a service becomes in active; used to avoid using inactive services AsyncReturn: Called whenever a subscription generates an event or asynchronous call returns A module can be run, it should be installed. Module provides a unified interface to a number of operating system functions. Most of the functions in this module are implemented by platform specific modules. The operating system module automatically loads the right implementation module when it is first imported. Modules are also helpful in aspect to programming for operating system. Whenever a new device is discovered on the system, the driver module is installed on it. Applications are installed for the facilitation of the users. Modules are installed with the help of copying the binaries and accompanying data to a specific directory in the system. Installation is carried out only if the module is compatible to the devices in the home. This also deals with changes in the operating system. During installation it is up to user either user wants to start

on system restart or on request. If we want to update the module then this task will be done by operating system not by itself module. Running modules are isolated to prevent any interaction except via the APIs to the home operating system platform and the service interface. Device Connectivity Layer modules are the exception as some must use the network to control their associated devices. Even then, when possible we limit connectivity to only those devices. A modules file system access is limited to its own working directory where it can store its data and configuration. When a new device is discovered on the network, Device Connectivity Layer check either its protocol is available or not. If not, not then it passes to next working process which is management layer and its task is to manage the new device and install protocol according to its or users requirement. The Device functionality Layer module is granted access to the service that the Device Connectivity Layer module exports for this device. Services are the way in operating system that modules can interact with

each other. They do this task using standard APIs described below: InitSvcAndCapability: Creates a service and a capability to access it; returns the service handle back RegisterSvc: Registers the service as active advertising it to other modules DeregisterSvc: Marks a service as being inactive and notifies other modules GetAllSvcs: Returns a list of all active services GetCapbility: Requests a capability to access a given service IsMySvc: Returns whether a given service belongs to this module Invoke: Used to call an operation either synchronously or asynchronously Subscribe: Subscribe to notifications from an operation SpawnSafeThread: Create new thread which safely propagate its failures

Modules advertise the services they offer to Home Operating System which keeps a history of offered services to enable future compatibility testing. Modules inform Home Operating System about services of interest to them using role names and / or locations. When a module needs to invoke an operation on a service, it requests a capability from Home OS. As part of the request, the module passes the credentials of the user it is running on behalf of. Home Store to simplify the process of finding new applications and devices, inspired by smart phone app stores, Home OS is coupled with Home Store which hosts all Home OS applications and drivers. It indexes application manifests as well as drivers associated devices and exported services. It helps users find applications that are compatible with their homes, by matching manifests against services in their home. If an application is not compatible, it can recommend additional devices that meet the requirements. Management tasks explains that how to manage the different task in operating system for home. We use the task sequence to modify new or existing task sequences. Task sequence can be organized into groups of task sequence steps. The Task Sequence Editor displays the task sequence groups and steps in the tree view on the left side of the editor window. When you select a task sequence group or step, its properties are displayed next to the tree view with two or more tabs that you can select to configure settings for that task sequence group or step. Task sequence groups and steps can be nested within other task sequence groups. It includes following tasks: 1. Adding a new application 2. Adding a new device 3. Verifying access rules 4. Adding new users Implementation Operating system for home was implemented in C# language using .NET 4.0 frameworks. It is also useful for sub operating system

and individual modules. Each module runs inside a domain. Direct manipulation is not allowed across domains. However, it does not provide performance or memory pressure isolation; these are subjects of future work. They also used drivers for operating system. Each of the 18 applications is less than 300 lines of C# language code and took only a few hours to develop. Because applications are written against highlevel abstractions, most of the effort went toward application-specific logic. As we report below, other developers also found application development in Home Operating System to be easy. The research tam extended the operating system in several directions. They wrote drivers for new devices including energy meters, different network cameras, appliance controllers and IM communication. They wrote new applications such as energy monitoring, remote surveillance, and reminders based on face recognition. One group extended Home OS to support the Kinect RGB-D camera and built an application which allowed users to control lights via gestures. Another group built an application that plays audio reminders based on who is recognized on cameras. This works with webcams, security cameras, and Kinect or IP cameras and with any device Home OS can play audio through. Commercial systems today support only a subset of devices related to their target scenario. Following tasks were also includes in the experimental set up. Layering and programmability Hardware-software coupling Media applications and decentralized data plane According to users view, the experimental set up contains following aspects: Organic growth Diagnostic support in interoperability protocols In addition to experience with real homes and developers, evaluation Home OS through controlled experiments, focusing on its Ease of programming Ease of managing System performance.

This gives us quantitative validation to confirm real-world experiences. They found different results from this experimental set up. Q4:What is good/bad about the experimental setup? Ans: According to the research paper, Home operating system is currently running in 12 real homes and 42 developers have written modules for it, these developers are students and have idea knowledge about automation and related parts. These field experiences validate key aspects of the Home operating system architecture. Research team also evaluated the utility of the PC-like abstraction for home technology as well as situations in which Home operating system was more or less able to preserve that abstraction. Generally, the experiences were positive even for people with no prior home automation experiences. However, the experiences did reveal some rough edges of our prototype and limitations of current interoperability protocols. They gave the Home OS proto type to ten academic research groups, for use as a platform for both teaching and the research on home applications. As part of this program, 42 undergraduate and graduate students developed tens of Home OS applications and the drivers. The good thing about the experimental set up was that developers designed different applications for the Home Operating System. This was helpful in quick and reasonable modules. The building application which works with the help of gestures was good result of this experimental set up. In view of Layering and programmability Developers who wrote applications found the protocol independence of the APIs appealing. Developers who wrote new drivers for devices with existing DCL modules liked that they did not have to concern themselves with the low-level connectivity details and could instead focus exclusively on device semantics. Developers who extended Home OS to devices without an existing DCL module started by building one module that spanned both the DCL and DFL. For them, the split was unnecessary overhead as only one device used the connectivity protocol. But a group had to support multiple devices with the same connectivity protocol based on IP to Z-Wave translation.

In Hardware-software coupling developers wand to add such type of feature that a third person cant access it any way. These points to an inherent advantage of vertically integrated softwarebeing able to better exploit device capabilitiesthat open systems like Home Operating System lack. In Media applications and decentralized data plane developers had difficulty in writing media applications. Home OS centralizes the control plane but not the data plane to avoid creating a performance bottleneck. If two devices use the same protocol, they assume that they can directly exchange data. Thus, they assume that a DLNA renderer can get data directly from a DLNA server once provided with a media URI. The DLNA protocol turns out to not guarantee this because of video encoding and/or resolution incompatibilities. While they currently use heuristics to provide compatible formats when transcending is available, they are not perfect. If we look to the user then 12 houses are using this system from -8 months. These homes are using a range of devices including network cameras, webcams, appliance and light controllers, motion sensors, door-window sensors and media servers and renderer. In view to Organic growth, a user does not know how to use this system or how to add devices in the system. Most attractive was being able to start small and then expand the system themselves as desired. Home OS let them start small and extend as needed. All users employed an organic growth strategy. They first installed 1 camera then they added devices to the network. In Diagnostic support in interoperability protocols at least two homes had problems diagnosing their deployments. This added the complexity of the network. In evaluation they find that developers can write realistic applications within 2 hours that users can use our management interfaces with similar success to other carefully designed systems and that system performance is good enough to easily support rich, interactive applications.

In Ease of programming they conduct a study of students and volunteer to check how it is easy to build an application for an operating system. Use of C# was helpful for the OS.

Q5:How well was the research carried out? What results are presented? Ans: Home OS currently runs in 12 real homes and 42 developers have written modules for it. These field experiences validate key aspects of the Home OS architecture. They also evaluate the utility of the PC-like abstraction for home technology as well as situations in which Home OS was more or less able to preserve that abstraction. Generally, the experiences were positive even for people with no prior home automation experiences. However, the experiences did reveal some rough edges of their prototype and limitations of current interoperability protocols. They describe the main findings below, based on informal surveys of our users and developers. The next section presents results from controlled experiments. The research team gave Home OS to ten academies and 42 graduates and undergraduates developed tens of application and drivers. This results in a group extended Home OS for different devices at different level. Other group work with webcams and security cameras and this underlines the power Home OS gives to application developers to easily span multiple types of devices (security, PC, phone etc). In Layering and programmability a group had to support multiple devices with the same connectivity protocol based on IP to Z-Wave translation. Different group worked on different aspects & groups found value in separating functionality across two layers indicating it was not just an artifact or our experience. In Hardware-software coupling points to an inherent advantage of vertically integrated softwarebeing able to better exploit device capabilitiesthat open systems like Home OS lack. This is unsurprising in retrospect as the closed nature of current solutions and devices is what Home OS attempts to combat.

In Media applications and decentralized data plane for reliable operation, they also plan to use Home OS as a transcoding relay, when data plane compatibility between nodes is not guaranteed. As high-quality open source transcoders exist, the main technical challenge is to generate profiles of what input and output formats devices support. This requires parsing device protocols like DLNA. Although this means violating Home OSs agnostic kernel, we believe that media applications are common and important enough to justify an exception. In view of users they limited our initial deployment to 12 homes. Ten of them had no prior experience with home automation. Beyond providing the software and documentation. In Evaluation they found that developers can write realistic applications within 2 hours that users can use our management interfaces with similar success to other carefully designed systems and that system performance is good enough to easily support rich, interactive applications. In ease of programming they check the level of difficulty and there were students and developers were on the other side and students have brief introduction about it. Each participant got a total of five-minutes of verbal instructions on the goal of the study and pointers to these resources. They left the participant and the testbed, with the Home OS server console running an IDE (Visual Studio) configured to use Home OS binaries. They provided little assistance beyond the initial training, though on three occasions the participants uncovered bugs in our system that we had to fix before they could proceed. They gave each participant the task of writing one of two applications for our testbed. Custom Lights per- User (CLU) will adjust the lights in any room based on its occupants preferences. This involves cameras in it. 2nd application was music flow the lights. This was according to the requirement of user. In the exit interview, almost all participants reported that Home OS was very programmable and the APIs were natural. However, they also expected more syntactic support in the IDE for invoking operations. They addressed this issue by defining a C# interface for each role.

In the exit interview, they asked the participants how easy Home Operating System was to use and learn, on a 7-pt. Likert scale from Strongly Disagree (1) to Strongly Agree (7). The participants found the system easy to learn (avg. 6.0), easy to use (avg. 6.0), and intuitive (avg. 5.5). 6: Do you believe the results? Why/Why not? ANS:Yes, we beleive in results, because of user satisfaction and ease of programming. The research team gave Home OS to ten academies and 42 graduates and undergraduates, they developed tens of application and drivers. This results in a group extended Home OS for different devices at different level. This means these graduates were succesfull to develope these applications and drivers only because of ease of programming. It is Cost effective and easy to manage, HomeOS let the users to start small (at low cost) and extend as needed. It thus provided a system that was much more approachable than commercial systems today that require thousands of dollars upfront. It was also more likely to satisfy users by allowing them to evolve it to meet their needs rather than requiring them to make all decisions during initial installation. 7:What things might you have done differently? ANS: Survey: I should have conducted a survey before the implementation of my ideas or developing home os. Connduction of that survey will help to know the preferences of local users or their intersests of using the home os. Most users will prefer a simple OS in nature, which can be used by any person even who has a little knowldge of smart devices. HomeOS may be accessed by Smart Phone: In general, there is a dedicated PC for the Home OS, we can sync a smart phone with that PC to make it more user friendly or effective in operation. By the help of a smart phone you can access each home appliance/device easily or remotely regardless of your position. Even, you can access all of these devices while you

are away from your home, you do not have to be at specific place as in case of single PC dedicated to Home OS. Q8:What lessons did you learn from reading this paper critically? ANS:- After reading this paper critically, I have learned a lot about technologies, use of these technologies in homes and in our daily common life. We can use new technologies and can create some more ideas and also can add some additional functionalities in the current technologies to make our daily life and work more easier. When you introduce any new technology then you have to test it not only with your point of views but with different users point of views also, I mean you should never say that it is done (because there will be always some things that must improve in the present technology) Because in this way you will try to improve the technology and it will be more useful for the common users And as this paper is about Home-OS, Now I know what an Home-OS is, HomeOS simplifies the task of managing and extending technology in the home by providing a PC-like abstraction for network devices to users and developers. Its design is based on management primitives that map to how users want to manage their homes, protocol-independent services that provide simple APIs to applications and a kernel that is agnostic of the functionality and protocols of specific devices. Experience with real users and developers, in addition to controlled experiments, help validate the usefulness of the abstraction and our design. More broadly, our hope is that this work spurs the research community to further explore the home as a future computing platform. Careful consideration is needed to determine which services a system like HomeOS should provide in all homes.